Elixir 1.19

Elixir still seems kind of rough and missing creature comforts, needs stabilization and guides to accomplish goals. There's a lot of broken/under-maintained packages and unhelpful guides that don't work because there's so much Phoenix ecosystem churn. It could get better but all the things™ need curation and approachable documentation. Not everyone wants LiveViews or to use their component system, and the learning curve for compatibility with other tools and technologies is still way too steep.

Python 3 was really, really needed to fix things in 2. Hence 2 became 3. They managed it pretty well, vaguely similar to Go, with automated update tools and compatibility-ish layers. It had its speed bumps and breakages as not everything went smoothly.

OTOH: Ruby 3 went the wrong way with types separate files and fragmentation of tools. And that's not mention having to opt-in with boilerplate to change how String literals work. Or: gem signing exists but is optional, not centrally-managed, and little-used. Or: Ruby Central people effectively stole some gems because Shopify said so. PS: many years ago Hiroshi Shibata blocked me from all GH Ruby contributions for asking a clarifying question in an issue for no reason. It seemed agro, unwarranted, and abrupt. So the rubygems repository fragment drama seems like the natural conclusion of unchecked power abuse lacking decorum and fairness, so I don't bother with Ruby much these days because Rust, TS, and more exist. When any individual or group believe they're better than everyone else, conflict is almost certainly inevitable. No matter how "good" a platform is, bad governance with unchecked conduct will torpedo it. PSA: Seek curious, cooperative, and professional folks with mature conflict-resolution skills.

It's a good idea™ to think deeply and carefully and experiment with language tool design in the real world before inflicting permanent, terrible choices rather than net better but temporarily-painful ones. PSA: Please be honest, thoughtful, clear, and communicate changes in advance so they can be avoided or minimized to inflict least net pain for all users for all time.

Honestly, I hope more development goes into making Phoenix/Elixir/OTP easier, more complete, more expressive, more productive, more testable, and more performant to the point that it's a safe and usable choice for students, hobbyists, startups, megacorps, and anyone else doing web, non-web, big data, and/or AI stuff.

Plug for https://livebook.dev, an app that brings Elixir workbooks to a desktop near you. And https://exercism.org/tracks/elixir

Yea each time I’ve upgraded (been using elixir in production since 2017), it’s gone way smoother than I had anticipated.

I usually find the Erlang/OTP upgrades to be a bit more problematic compatibility-wise.

So I’m often in the latest elixir but one Erlang/OTP version behind cuz I wait a few months for all the kinks to be worked out.

> So many examples of programming languages have huge breaking changes between versions

I can only think of 2: python 3 and perl 6.

Those two were very traumatic so it's not surprising it feels like more.

Dart is doing slow nullable changes slowly , opt in. Last time I took a peek

Completely agree. I feel no pressure to constantly upgrade my Elixir versions. I just look at the changes and there is often useful features that make me want to upgrade, as opposed the feeling of dread when I am pushed to upgrade.

You're measuring a cached compile in the subsequent runs. The deps.compile probably did some native compilation in the dep folder directly rather in _build.

    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile
    ________________________________________________________
    Executed in   37.75 secs    fish           external
       usr time  103.65 secs   32.00 micros  103.65 secs
       sys time   20.14 secs  999.00 micros   20.14 secs

    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile
    ________________________________________________________
    Executed in   16.71 secs    fish           external
       usr time    2.39 secs    0.05 millis    2.39 secs
       sys time    0.87 secs    1.01 millis    0.87 secs
    
    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=10 mix deps.compile
    ________________________________________________________
    Executed in   17.19 secs    fish           external
       usr time    2.41 secs    1.09 millis    2.40 secs
       sys time    0.89 secs    0.04 millis    0.89 secs

    mise use elixir@1.19-otp-26 erlang@26
    
    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=1 mix deps.compile
    ________________________________________________________
    Executed in   97.93 secs    fish           external
       usr time  149.37 secs    1.45 millis  149.37 secs
       sys time   28.94 secs    1.11 millis   28.94 secs
    
    rm -rf _build/ deps/ && mix deps.get && time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=5 mix deps.compile
    ________________________________________________________
    Executed in   42.19 secs    fish           external
       usr time    2.48 secs    0.77 millis    2.48 secs
       sys time    0.91 secs    1.21 millis    0.91 secs

Anyone downvoting care to comment on why a benchmark of a feature in this release is downvote worthy?

I quit my job and started a company just so I can use Elixir.

> 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)).

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.

Python has a GIL and is mutable, which makes concurrency impossible and error-prone, respectively. Elixir doesn't have a GIL and is immutable.

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

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.

I hope this helps.

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.

Gleam doesn't give you access to the full amazingness of OTP and BEAM. Elixir does.

Yeah Gleam. Or Kotlin on the JVM is also quite similar and has compile-to-JS if needed.

gleam's 1/0 = 0 is crazy just because the author doesn't want there to be any raises anywhere. problem is, in many real world scenarios 0 is used as a sentinel value that doesn't "just" mean 0. iirc reading somewhere (in a non gleam system where 1/0 = 0) there was a system where everyone woke up to having zero shares because a 0 share tx was posted to everyone's trading endpoint, and a zero share tx means "zero the account".

    type Record {
      NShares(n: Int)
      ZeroTheAccount()
    }
    
    fn parse_record(n: Int) -> Record {
      case n {
        0 -> ZeroTheAccount()
        _ -> NShares(n)
      }
    }

I would not entirely compare it to TypeScript. Due to pattern matching, legacy elixir will probably come out roughly 50% typed (extrapolating from my own usage, I'm not sure the accuracy of this number). Then since vanilla elixir is getting types (not a separate TypeElixir) I would venture anything actively maintained will get typed relatively quickly.

I personally do not like type systems, and still code in JS, not TS. Any JS artifacts I produce are untyped. Yet even my Elixir-code is nearly type ready.

So while TS is fighting an uphill battle, I think Elixir is working downhill.

Elixir has had types since forever, both primitive and things like structs and shape based destructuring. Then there's Dialyzer and libraries like TypedStruct.

It's never been a wat-language in the style of JavaScript.

Kotlin is almost the jruby we always wanted.

I have the opposite experience. Even in production builds, I get Elixir stacktraces, and they're exceptionally helpful. Macros only save me time and LoC, I think maybe once I've struggled with a macro-caused issue (and it was immediately apparent that macros were the issue).

ExUnit has been hands down the most impressive testing library I've ever worked with, and the debugging, profiling, analytics, introspection, observability, etc of the BEAM is unbeatable.

Documentation of elixir, elixir deps, and elixir code is also far and above any language I've ever seen.

And the struggles I had supporting minimal concurrency in python were completely alleviated - so even if you don't need massive concurrency, elixir has a good chance of massively simplifying anything that needs minimal concurrency (which is probably most web related projects).

Even though I do not write Elixir on the job, I often cite their docs as a gold standard. They're succinct, easy to read, and most often show an example of how a method is used. What's better is that the language has documentation as a first-class citizen (it's even testable!) meaning your auto-generated docs will look as nice as the language's.

I complain about OCaml docs all the time. But Elixir? no way.

> On a production build, stack traces look like Erlang code

Do you have an example? There are some cases that I can think of where the application dumps some foreign-looking data structures if the release fails to start, but that's very rare and usually the actual error is somewhere near the beginning like "eaddrinuse" here:

    [notice] Application my_app exited: MyApp.Application.start(:normal, []) returned an error: shutdown: failed to start child: MyAppWeb.Endpoint
        ** (EXIT) shutdown: failed to start child: {MyAppWeb.Endpoint, :http}
            ** (EXIT) shutdown: failed to start child: :listener
                ** (EXIT) :eaddrinuse
    Kernel pid terminated (application_controller) ("{application_start_failure,my_app,{{shutdown,{failed_to_start_child,'Elixir.MyAppWeb.Endpoint',{shutdown,{failed_to_start_child,{'Elixir.MyAppWeb.Endpoint',http},{shutdown,{failed_to_start_child,listener,eaddrinuse}}}}}},{'Elixir.MyApp.Application',start,[normal,[]]}}}")

Here's how runtime errors are normally reported (in `MIX_ENV=prod mix release` build):

    10:47:17.229 [error] GenServer {MyApp.Registry, "some-long-running-thing:4196f8ae-c971-439b-854e-5057e45076b9", %{}} terminating
    ** (RuntimeError) attempted to call GenServer #PID<0.2892.0> but no handle_call/3 clause was provided
        (my_app 1.1.0) /home/runner/work/elixir/elixir/lib/elixir/lib/gen_server.ex:895: MyApp.Monitoring.SomeServerMonitor.handle_call/3
        (stdlib 5.2.3.5) gen_server.erl:1131: :gen_server.try_handle_call/4
        (stdlib 5.2.3.5) gen_server.erl:1160: :gen_server.handle_msg/6
        (stdlib 5.2.3.5) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
    Last message (from #PID<0.2891.0>): {:some_unknown_request, %MyApp.Monitoring.Stats{ts: ~U[2025-10-17 08:47:17.229542Z], some_data: 2}}

> Then you have macros, which make code unmaintainable at the 10k SLOC mark, and increasingly harder to maintain as projects get larger.

Absolutely, so don't write macro-heavy code. This is mentioned in the first paragraph of official Macro documentation and documented as an anti-pattern in the official documentation.

> The toolchain has much room for improvement.

I agree that editing experience (due to lacklustre language server support which is now being worked on officially), and debugging tools are lagging behind.

> And the documentation for most of the projects you will use is full of noise, with few workable examples, grandiose claims of performance and fantastic treasures, and the articles are a great read if you want to waste your entire evening.

I don't agree with this at all.

I'm sorry you had a bad experience, but this doesn't reflect the experience of most Elixir programmers. I'll share my experience as a counterpoint.

> On a production build, stack traces look like Erlang code...

Elixir has the most readable stacktraces of any language I've used. Here's an example (which is color-coded in the terminal for even more clarity and, as you can see, doesn't contain any Erlang code):

  == Compilation error in file lib/app_web/live/authentication/settings.ex ==
  ** (MismatchedDelimiterError) mismatched delimiter found on lib/app_web/live/authentication/settings.ex:96:1:
    error: unexpected reserved word: end
     │
   4 │   on_mount {AppWeb.UserAuth, :require_sudo_mode
     │            └ unclosed delimiter
  ...
   96 │ end
    │ └ mismatched closing delimiter (expected "}")
    │
    └─ lib/app_web/live/authentication/settings.ex:96:1

It's easy to see that the issue is on line 4, and that it is a missing curly brace.

> Then you have macros, which make code unmaintainable...

Elixir gives you full access to the AST, making macros extremely easy to read and reason through. The point of the Lisp-style macros Elixir uses is to simplify your code. If your code becomes unmaintainable due to your use of macros, you're probably misusing them. I'd have to see a sample to make that determination, though.

> Running "mix xref graph" on most Elixir projects shows a spaghetti mess.

Spaghetti? It's a simple two-level tree that is in alphabetical order. Here's an example, and it is like this all the way down:

  Compiling 26 files (.ex)
  Generated stow app
  lib/app.ex
  lib/app/accounts.ex
  ├── lib/app/accounts/user.ex (export)
  ├── lib/app/accounts/user_notifier.ex
  ├── lib/app/accounts/user_token.ex (export)
  └── lib/app/repo.ex
  ...

To me, this output seems extremely accessible.

> The toolchain has much room for improvement...

Having developed many Windows apps using Borland's tools in the 80s and 90s, I disagree with this statement for these reasons:

• Mix is one of the best and most integrated build tools/task runners I've used. For example, you can create, migrate, and reset databases, execute tests, lint code, generate projects, compile, build assets, install packages, pull dependencies, etc.

• ExUnit is a great testing framework that handles all kinds of tests in an easy-to-read DSL similar to Ruby's RSpec.

• IEx is a fantastic REPL.

• Elixir's debugging tools are excellent. For example, IEx.pry lets you stop all processes and interact with your system in that frozen state in the REPL. You can watch variables, run functions, and even create new functions on the fly to interact with your data to see how it behaves in different scenarios.

> Building a team around Elixir is hard.

Why is it hard? I've worked exclusively on Elixir projects for both start-ups and large companies with hundreds of engineers for over ten years now, and never had a problem with hiring teams.

> And the documentation for most of the projects you will use is full of noise, with few workable examples, grandiose claims of performance, and fantastic treasures, and the articles are a great read if you want to waste your entire evening.

All technical documentation could be improved, but Elixir's is already quite good. See for yourself: https://hexdocs.pm/elixir/1.19.0/Kernel.html.

Furthermore, from within IEx, you can type:

  function |> h

for any function and see an explanation of what the function does and examples of how to use it.

> Support for massive concurrency is nice, but you are realistically not going to need it...

Elixir supports minute concurrency as well, and yes, I do need it. For example, in Ruby on Rails, which has a GIL, I'd have to use a gem like Sidekiq to push long-running processes into Redis so they can be processed in the background. In Elixir, I can just run them in a separate, concurrent process, which is simple.

Here's an example that takes a collection of users and a function and then runs each user through that function, each in a separate thread:

  defmodule ParallelProcessing do
    def map(collection_of_users, func) do
      collection_of_users
      |> Enum.map(&(Task.async(fn -> func.(&1) end)))
      |> Enum.map(&Task.await/1)
    end
  end

Here's the same Elixir code running in a single thread.

  defmodule SequentialProcessing do
    def map(collection_of_users, func) do
      collection_of_users
      |> Enum.map(func)
    end
  end

In the first example, I could have 1 user, 1,000 users, or 1,000,000 users, and this code would run as optimally as possible on all the cores in my CPU or across all the cores in all the CPUs in my multi-server BEAM cluster. There are no extra programs or libraries needed. In the second example, users are processed one at a time, similar to languages like Python, Ruby, JavaScript, PHP, and Perl.

Given the simplicity of writing parallel code in Elixir, why would I limit myself to one CPU core to perform a task when I can use all cores simultaneously?

> Or deal with people that won't stop selling you how great the language is.

The reason they won't stop selling you on Elixir is that Elixir is a fantastic language. I hope you take the time to revisit it in the future. It really is much better than most things out there.