As far as I know there‘s no other language which focussed from the get-go on parallel, distributed deployment, has processes as first class primitives, supports hot code swapping etc.
Something simple like a message queue has many ways it can be implemented in a distributed system. In Erlang every actor has its own queue. Great. I highly doubt I could actually use them in a real distributed system but I’d love to see that I’m wrong.
Here's a trivial example from one of my recent jobs: We need to queue Slack messages from different producers into some kind of per-tenant outbox queue that ensures one consumer per tenant, and which consumes at a maximum rate (to stay below Slack rate limits). This queue also needs to be bounded and communicate back pressure to producers. What unique value does Erlang provide here? Usually this kind of thing is built using Go and AWS Lambdas and SQS or Kafka. Where does Erlang/BEAM help here?
And why does from the get-go on parallel matter? Wouldn't it be OK if the initial focus was something else and then there was a change of focus?
And processes as first class depends what you mean: https://live.exept.de/doc/online/english/overview/basicClass...
And hot code swapping: Smalltalk.
Retrofitting features into existing languages is rarely satisfying in my experience.
Sure, Python now has functional constructs, but variables are still mutable, so bizarre things can happen inside a map call.
In Erlang, immutability is baked into everything.
Message passing can be added as a library, but you don’t get the same impact as everything being a message. Does your random 3rd party library also use messages? Probably not.
Erlang is a very opinionated language and runtime with a small set of core concepts, and it is very predictable as a consequence.
Java or C++ have just about any feature you can think of, which is beneficial in some ways, but they’re also much more complex.
> immutability is baked into everything
process dictionary