I maintain Elixir and Rails applications. In my opinion, almost all LLMs handle Elixir better. I suspect, though do not know, being an immutable functional language and composing applications in a functional style makes it easier for the models to "reason" about the code and state. I learned very quickly that this is my preferred language for that very reason.

Additionally, the features available in the BEAM and OTP mean the agents have built-in tools for many things that would require reaching for 3rd-party libraries or even additional services. This means less variability in design as the models will happily use all the language features human developers would have to learn about and understand over time to use effectively. Not that this isn't important, but I believe models do a better job steering you to obvious and optimal solutions with Elixir.

The new type system is only going to make it better.

An agent that was looking at the log output from a program in a typical language, and also looking at the code for that program, would have a lot of unanswered questions related to "how do I iterate on this?" Maybe there's a kubernetes cluster involved somewhere. Maybe it there's a cloud storage bucket. Maybe there's dashboards and metrics and telemetry hosted by servers that the agent doesn't know the name of.

Elixir runs on the BEAM which lets you do hot code reloading process at a time. And these are much more lightweight than your typical OS process. So you can do things on the BEAM which would be just crazy to do on other achitectures. Like if you have a server which needs to support a million users, it would be insanity to run a million separate OS processes for the job. But BEAM processes are so lightweight that you can do that, which gives each one isolation from misbehavior of the others.

And since these support hot code reloading, without restarting the BEAM's OS process, you can patch the code for your user's sliver of the server and do a sort of "what-if" experiment. Other architectures would require you to implement separate test environments or complicated feature flag systems, but the beam lets you just reach out and change it for just the process you care about--you're not baking the experiment into an OSI image or anything so dangerous as that... blast radius is kept small.

And the steps for carrying out this experiment, it's all doable at the elixir shell. You connect to the BEAM and make changes. That's a tremendous reduction in context that an agent needs to load--context which would otherwise instruct the agent about how to reason about the deploy process and how to wall off your experiment from others so as to not cause problems with it is just answered implicitly by how the BEAM works.

Elixir compiles to BEAM bytecode, so you get all of this because the BEAM is cool. As for Elixir as a language... I don't think there's anything agent-specific about it. Gleam might be a better choice since it's statically typed and also compiles to BEAM bytecode except that it's not as popular as Elixir, which is probably more important.

You can also do all of this in the language that started it all: Erlang (Java : JVM :: Erlang : BEAM) but it's not exactly fashionable at present (similar to java vs like... kotlin or clojure or something).

Disclaimer: I'm more of a fan than a seasoned pro. I'd love to actually be working with this stuff daily, but my team wouldn't have it because they prefer familiar things and pain.

It's vibes all the way down.