(2025-08-18) A week with Elixir: what I understand now and what still don't
---------------------------------------------------------------------------
Most of the time, the terms "industry-grade" and "pleasant to work with"
don't combine in a single programming language. There are several pretty 
valid reasons for that, but there also are several notable exceptions to 
this unwritten rule. These two qualities can be combined in one of the three 
ways. The first and most common one is, a language that's inherently 
pleasant to work with becomes widely used in the industry AND (that's an 
important part) its quality increases to the level that can be trusted by 
the industry. An example of this is Python, which already is reliable enough 
and just works for most engineering domains. The second and a rarer way is 
when a language already used by the industry for a long time becomes more 
pleasant to work with over time. This situation is quite rare because the 
industry loves backwards compatibility and whatnot, but I could think of 
something like Tcl or Lua that are getting more and more useful features in 
the core with every major version. The third, final and rarest way of this 
convergence is when the language designers make things right from the first 
stable version available. Of course, to do so, someone already had to do all 
the legwork for them, so such languages usually piggyback on some existing, 
well-established runtimes whose only problem is the lack of a human-friendly 
language to make use of them. And, without a doubt, the first thing I 
understood throughout this week is that Elixir definitely belongs to this 
third class.

As always, the language I had to compare Elixir to is the language I still
have to use the most, Python 3. Besides their huge differences regarding 
almost everything (JIT-interpreted vs. bytecode-compiled, mutable vs. 
immutable variables, loops vs. recursion etc), I found them quite similar 
when it comes to organizing code structure and its documentation, and also 
by the amount of "batteries" that come shipped with their runtimes. Elixir, 
however, gets a huge bonus since it also has native access to the Erlang's 
standard library functions in addition to its own. In fact, the foundation 
provided by the BEAM VM is so solid that Erlang/Elixir dependencies almost 
never need to use any FFI, which is a known PITA for a lot of Python 
packages, especially those that have dependencies written in Rust. The BEAM 
package ecosystem being much more self-contained also means it's much more 
portable. Just like Java, for example.

And since we've mentioned Java, let me point out another fact: the full
Erlang+Elixir runtime for x86_64, without any third-party libraries, weighs 
just about 22 MB. Unpacked. For comparison, a fresh Python 3.13.4 install 
takes about 108 MB. Now, I think we're long past the time when JRE weighed 
even 80 MB, now it's closer to half a gig, I guess. Because even the minimal 
JRE package for NixOS is about 52 MB compressed and 440 MB uncompressed. I 
think I can safely skip the comparison with any modern .NET distibution lol. 
You get the idea. Only Tcl and Red can compete in size, but not in anything 
else besides their elegance.

But here's the main question: how does it feel to write Elixir? Does it have
the potential to replace Python (and probably Go and Tcl too) as my main 
language for day-to-day tasks whenever I have the real chance to do this 
replacement? For now, the answer is: quite likely, yes, it does have that 
potential. It feels like the mentally cheapest way of entry into functional 
programming for someone who grew up with purely imperative languages or 
modern multiparadigm languages with clear imperativity or OOP bias. That's 
something I couldn't even tell about OCaml (a bit of which I also know, yes) 
and other ML-like languages. Partially because all of them (including Gleam 
I mentioned in my previous post) are way too focused on types, up to the 
point of sacrificing the freedom of expression in order to feed the 
statically typed Molokh. Well, at least OCaml has a powerful type inference 
mechanism. Most languages from that camp don't even have that and require 
you to clutter your code with pointless definitions. Elixir though, like 
Python, has type hints but doesn't enforce anything. Because, you know, 
there's no need in being foolproof when there are no fools around.

However, as I already mentioned, not everyhthing is fine and dandy, and some
things continue to surface that just keep me puzzled. And my main problem is 
the community that seems to know things that they deem too obvious to tell 
anyone or even write documentation about. This, combined with their 
obsession with the "XY problem" (that I already have a post about) and a 
"noneedinthis"-syndrome (popular on some LUG forums btw), makes learning the 
nuances of Elixir harder than it needs to be. If, however, this is the only 
obstacle then it surely can be overcome once I cross a certain threshold of 
language practice. And I don't think this threshold is gonna be hard to 
cross with Elixir: most concepts here are pretty straightforward to grasp 
and replicate.

In short, an ideal language for a lone ranger with solid foundation. An
anti-Java, if you will. And this is why I like it the most.

--- Luxferre ---