What’s the advantage of using this language over Rust, Go, Java (or any other JVM language), or Python?
Saša Jurić's talk "The Soul of Erlang and Elixir" (https://www.youtube.com/watch?v=JvBT4XBdoUE) is a good introduction to why someone might choose Elixir. The payoff is the slide (https://imgur.com/gallery/G6lfUW6) where he compares the stack of a "traditional" web app (Nginx + Ruby on Rails + Go + Redis + Mongo + Cron + Upstart) to the Erlang rewrite of the same app, which is... just Erlang.
This isn't to say that Erlang ships a complete replacement for Redis, Mongo, Upstart, etc.—but it provides most of the functionality that most apps will need, such that your dependency tree can be much simpler. It's really nice to not have to become an expert in all the infrastructure surrounding a normal web app and instead just learn Erlang/Elixir.
It is also so much easier to test when all of your architecture is in one form. You don't have to spin up whole deployments on real infrastructure to see if the parts still talk - your normal local unit testing architecture gets you much more confidence.
The Norm library (https://github.com/keathley/norm) is an attempt at higher-level, more expressive type checking which I think shows a lot of promise, but I've not adopted it in a real project yet.
Go: Go's CMT implementation is fundamentally broken (you can't just use go channels without mutexes for complex work unless you want your application to have bugs). Elixir and Erlang Actors have much better guarantees.
Java: BEAM is slower than the JVM, but much more stable. Native actors are a much better experience than Akka.
Python: Django finally added initial support for async development, but library support is a long ways off (and the GIL is its own issue). BEAM is about an order of magnitude faster than Cpython (though probably similar performance with pypy). If you prefer Ruby syntax over Python, there is no contest here.
My big question is less Why BEAM? and more Why Elixir?
I prefer the native Erlang Syntax, LFE/Joxa (lisps), or alpaca (ML family with static types) over Ruby-ish syntax.
I came from Python. For me Elixir was much more approachable as a first step into a functional language. Syntax, documentation, getting started/onboarding. I believe there are efforts under way to make Erlang docs a bit easier to approach.
And then Phoenix with projects like Presence really built my excitement for the language. Had some colleague that was thrilled by Ecto changesets.
So a combination of ergonomics, easily accessible to new people and strong hype-marketing brought me in I guess. And I enjoyed it and am happy with the results it gives.
I write scraps of Erlang from time to time, but hate the idiosyncrasies such as the rules behind commas and full stops, and variable names starting with capitals. There are so many other weird quirks too, like how strings are handled.
- It runs on the Erlang VM, which is (tech-wise, anyway) fairly old and battle tested. It was deliberately built for resiliency and concurrency. It has some very clever concepts, like supervision trees, cheap processes, interprocess communication via message passing (hey, sounds like OO, right?), and 0 downtime deployments built-in.
- Its creators (namely Jose Valim) come from the Ruby community, and value a lot of the same things Rubyists do: good documentation, testing, and excellent tools for package management, debugging, builds, testing, etc. Several libraries are very similar to their Ruby counterparts. E.g., Phoenix will feel very familiar to a Rails developer. Ditto, the syntax is kind of similar to Ruby. The paradigm is completely different, as Elixir is an immutable, functional programming language. But... aesthetically, they look similar-ish.
In my opinion, the Elixir community (at least for the core language and major libraries) does documentation better than any other environment I've used. Almost every question I've ever had about using Elixir, Phoenix, or any of a dozen other libraries has been answered by using hexdocs.pm. The few things that aren't clear from those docs can generally be resolved by reading the source.
After that, elixirforum.com or the elixir slack give me higher level discussions on less immediate issues. I don't recall ever needing Stack Overflow for any elixir question.
The other key feature is that Erlang/Elixir/Beam implement 'the actor programming model'. This is a series of separate bits of code that have their own state and communicate to each other with messages. It turns out that for long running processes (web servers, control software etc.) this model is an excellent way to build your code. A lot of code ends up doing a subset of this, and usually not that well. Elixir gives you the tools to do it properly and easily.
Elixir is not quite as popular as Go. But there are absolutely job opportunities out there. And huge projects currently using it (e.g., Discord). I wouldn't focus on needing there to be a job market to learn something new, though. You'll learn techniques and a new way of problem solving that will make you a better Python, JS, and PHP programmer, even if you never professionally work as an Elixir developer.
The Introduction guide on the Elixir website is a really good place to get started. You should be able to pick up the basics pretty quickly: https://elixir-lang.org/getting-started/introduction.html
It focuses on practicality rather than adhering to the functional paradigm (lambda calculus etc.). That's probably the right choice for building highly concurrent industrial systems, but purely for learning about FP not quite as good as something like Elm would be.
You also spend a considerable amount of time on Elixir learning how to architect fault tolerant concurrent systems. While useful, this doesn't have much to do with functional paradigm per se.
And I'd say for that type of case it may be more approachable for not being qiite so pure.
Personally, learning Elixir didn't really help me understand many fundamental FP concepts such as function composition & higher order functions, algebraic data types, referential transparency, functional purity, currying etc. It was only after spending time learning Elm and Haskell that many of these things dawned to me.
So I'd say if your aim is to really learn about the functional programming as a paradigm, there are better alternatives out there.
Job opportunities are fine, not Python+ML or JS+React great but there is work out there.
Job opportunities seem tied to doing RoR as well, but I guess that's less and less true.