[pjmlp]

From someone that comes from Java/.NET land, I hardly see a benefit, specially given the wealth of programming language options on those platforms.

Now for someone starting new, maybe the Erlang eco-system might be a good bet, and Elixir an entry point.

Still, not everyone has Ericson scale problems to solve.

[klibertp]

Erlang (and, by extension, Elixir) is still one of the very few systems which offer this exact (or even just close enough) mix of features AFAIK. Whether this set fits your use-case or not, and whether it would give you an advantage over your chosen technology, are both very important points, but there's also something to be said about how good and well-implemented it is for some use-case(s). To be honest, I first learned Erlang along with Prolog, Forth, Lisp or J - out of curiosity about various paradigms and the most "pure" implementations of them. Erlang was at the time the oldest, actively developed, open-source system for concurrent and distributed programming. Today I think I'd go with Pony, which implements Actor-model on the language-level too, but also with support for it in the (static) type system.

Anyway, what I wanted to say is that Erlang is first and foremost a fault-tolerant language and system, of which both distribution and concurrency are by-products. As an example of a "fault" that the creators of Erlang had in mind, Joe Armstrong often cites "being hit by lightning": the only way to ensure the system will still function after that is to have its copy running somewhere else, hence distribution. Another type of fault I think explicitly mentioned in "Programming Erlang" is dealing with hardware failures, sensors and outputs getting disconnected and reconnected, etc. - hence concurrency and per-process error isolation. Finally, "programmer errors" are also a kind of a fault (as impossible to completely avoid as lightning or flood), hence immutability, versioned rolling upgrades and rollbacks and live introspection into any node from anywhere in the system (among other things).

That is not to say that the by-products aren't important or nice to have, just that many of the design decisions in Erlang start making a bit more sense if you look at them from this angle. It also helps to decide whether Erlang is the right tool for you: it's going to save you many, many years of effort if you need a nine-nines guarantee for a system you'd otherwise have to write a few million loc of C; it can still give you a bit of an edge if you are able to make use of its unique features like a built-in distributed data-store or if the Actor-model with preemptive scheduling fits your app very well. Outside of these pretty specific use-cases (although, to be fair, I'm just giving examples - Erlang/OTP is a large (in terms of built-in functionality) system and Elixir adds even more stuff, so there are many more good use-cases for it) you may struggle to realize any positive outcome with Erlang: unfamiliar everything, no libraries, a runtime system always ready for connecting to remote nodes even if you're writing command-line script, immutability has a performance cost and overall performance is not impressive and so on, each of this things could potentially bring down your project if not carefully considered.