Elixir is still confusing, not the language, but the ecosystem, tooling, and philosophy. Is it dynamic or static? Is it compiled or not? If it's not, then why do we have Elixir scripts, which have different file extension? If it uses BEAM and you'd inevitably need to know Erlang when you hit the edge cases, then why not just learn Erlang? If it solves concurrency the "right way" due to supervision trees, why not use Python libraries that also implement the actor model, making Python code concurrent the "right way"? I just don't know which niche applications Elixir targets and excels at.
I don’t understand why people drink orange soda. If you want something orange flavoured, eat an orange! If you want something bubbly, drink soda water!
.ex compiles to beam files to be run later
.exs compiles to memory
You don’t need to know Erlang to use Elixir; I’m a few years in now and I’ve never had to write any Erlang.
in the past i would have said learning to read erlang is a very nice to have for an intermediate elixirist but not really anymore, an LLM can translate between the two very easily.
That's true. Even so I would still recommend that you learn to read Erlang because of its unique approach to various software development challenges. It will simply make you a better programmer. The same goes for LISP and possibly Forth because they have some very powerful concepts unique to those languages which you can mimic to some degree in other environments to get some of the benefits.
> If it solves concurrency the "right way" due to supervision trees, why not use Python libraries that also implement the actor model, making Python code concurrent the "right way"?
I can't speak too much about Python – but immutable vars is a core prerequisite for many of the features OTP (the platform underpinning Elixir (and Erlang)).
Erlang/Elixir supervision trees also rely on process linking, which is implemented in BEAM and doesn't have a real equivalent in most other language runtimes (modulo some attempts at copying it like Akka, Proto.Actor, etc, but it's fairly uncommon).
these are all surprisingly specific questions that can actually be answered!
1. It's dynamic
2. It's compiled
3. Elixir script is just a file with Elixir code that compiles and runs right away
4. I've been writing Elixir for 7 years and barely know any Erlang. I even submitted bugs to OTP team with reproductions in Elixir, they're chill.
5. Preemptive scheduler, immutable data
Python allows for memory sharing between threads - which is why a GIL is necessary.
A high-level language with a strict shared-nothing concurrency model doesn't need a GIL... but you naturally can't practically share very large objects between BEAM processes.
1. Regarding Python's GIL: The issue isn't memory sharing between threads. Java and Go allow you to do this, too, but they don't have GILs. The reason Python has a GIL is that it uses reference counting for memory management. If it didn't have a GIL, multiple threads could simultaneously manipulate reference counts, which would lead to memory corruption/leaks.
2. You can share massive "objects" between BEAM processes. For example, if you're running BEAM in a 64-bit environment, you can share maps, structs, and other data structures that are up to 2,305,843,009,213,693,951 bytes in size.
I hope this information helps. I also hope it is correct. I think it is, but I've been wrong before.
The difference in reliability between a BEAM based setup and one built on top of Python is so large I wouldn't know where to start to describe it. Erlang is built from the ground up to be reliable, Python has reliability bolted on as an afterthought and even the most advanced python environments (Anaconda, CPython) still suffer from some of the assumptions baked into the language.
Upvoting you because we should have clear answers for these concerns. To those in the community downvoting: we should take these kinds of posts as opportunities to improve.
Elixir and Erlang are dynamic compiled languages.
The actor model being built in to the runtime offers many benefits, all of which I cannot enumerate here, but prominent among them are the ability for the VM to preemptively schedule actors, and the fact that actors are independent in memory and cannot mess with the internal state of other actors.
The jump from Elixir to Erlang or vice versa is small.
The hardest (and most rewarding) part is learning OTP and the whole BEAM runtime system, which you can do with either language.
Erlang and Elixir are slightly different syntaxes for the same semantics, and if you know one you can learn to read and probably write the other in less than a day.
It isn’t like Clojure and Java where Clojure is significantly higher level than Java in many ways. Elixir adds a few things to Erlang but is otherwise the same programming model.
> I just don't know which niche applications Elixir targets and excels at.
Pretty much any application where concurrent IO and state management are the main problems. Web applications, proxies/brokers, long running network stuff, semi-embedded low power devices that are hard to physically access and must remain reliable for years at a time, that kind of thing.
I actually agree with you that the ecosystem and tooling and especially the value proposition are confusing, and the sales pitch over the years has often been poor.
The whole BEAM community would do well to speak more plainly about the concrete benefits for programmers and companies, and the existing successful applications rather than the theoretical beauty of the syntax or the actor model.
