Elixir (really, the Erlang VM it's built on) is designed for highly concurrent, reliable systems. For my org, building a distributed webapp, we chose it over the languages you listed because of how much you get "out of the box" with Elixir.
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'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.
I hadn't seen that slide, it's pretty compelling. Is there a story for typechecking or a typed language that runs on BEAM? This is one aspect that holds me back a little.
Erlang's type checker Dialyzer has an Elixir wrapper called Dialyxir (https://github.com/jeremyjh/dialyxir). As someone coming from C++, Dialyzer leaves a lot to be desired—I still miss C++ type checking—but it's better than nothing.
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.
Rust: much lower-level systems language which will take quite a bit more development time.
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'd not written any Ruby before touching Elixir (and still don't, barring tools like Dependabot and Vagrant), but far and away prefer Elixir's syntax to Erlang.
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.
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.
This isn't to say there aren't disadvantages, too. But for advantages, specifically, I think some pros of Elixir are:
- 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.
> and value a lot of the same things Rubyists do: good documentation
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.
Speaking of excellent documentation, from the documentation you can jump right into the code and see how a particular elixir function is implemented. Super useful personally for me as a learner. For example , go to https://hexdocs.pm/elixir/Enum.html#map/2 and click on the little "<\>" on the top-right
The language itself is a dynamic, functional programming language. The benefits of functional programming languages have been much discussed (and much disagreed with), but Elixir is a particularly gentle introduction to the space while being a great language to work with.
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.
Asking for "the advantage" is probably not quite the right question. Different toolbox, different tools, for different solutions to different jobs. Elixir runs on the Erlang VM, is functional, has a Ruby-like syntax.
How easy (or hard) is it to learn Elixir for someone with Python/PHP/JS background and zero knowledge of functional programming? Also, are there job opportunities for Elixir or is it a niche language?
As far as functional programming languages go, I think Elixir is probably one of the best intros: especially for someone coming from another dynamically typed language like Python or PHP. The syntax will be far less foreign than a language like Lisp or Haskell. You won't have to deal with types (though they are neat to learn, too).
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.
I don't really agree that Elixir is a good intro to functional languages. It doesn't really teach you much about the functional paradigm as Elixir is fairly imperative by nature.
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.
Here I thought that's exactly the fact that makes it less ideal for learning about the functional paradigm.
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.
Easy enough, for me. I have roughly the same history of languages. Functional programming as a paradigm was the biggest hurdle for me. But Elixir guide docs help yout quite a bit there.
Job opportunities are fine, not Python+ML or JS+React great but there is work out there.
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.