[dns_snek]

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