LLMs and Elixir: Windfall or Deathblow?
131 comments
·June 4, 2025ipnon
jimbokun
I can't wait until we get LLMs bitching about being forced to write boring verbose Java code, and demanding to be allowed to write concise, robust, performant Elixir code as a better solution.
And then criticizing you for using vi over Emacs (or vice versa).
hoppp
They can already do that, it depends on the system prompt.
theendisney
They should have plenty of training data. A slight nudge might be enough. They might have some "safety" measures in place to "protect" us from it.
null
carlmr
>I generate a small amount of code, check for validity (much easier to verify in a functional language), and repeat this loop.
This has been true before LLMs as well. Build small, testable functions and compose them together. That's basically it.
DrBenCarson
Lol exactly. "LLMs write good code if you make small changes and write tests!" Groundbreaking stuff
tough
I haven't tried Elixir yet, but I've noticed this same effect with Rust or Go, as in what previously would have been syntactic hell without LLMs, becames tighter feedback loops with good errors and testing, and produces much better, cleaner code bases.
interesting how this will shift adoption of languages that are a bit harder to grok for humans, but not really for llms
QuantumGood
This leads me to ask if we'll see not only frameworks and libraries, but entire languages created specifically for LLMs to use them well.
computably
I think you missed their point: they prefer Elixir because they find the Elixir code is easier for them/humans to grok, validate, and fix.
belter
>> and because of the runtime, will practically never crash your system.
"Practically never crash" ignores software bugs, resource exhaustion, or bad architecture
borromakot
Have you written/deployed Elixir before?
belter
Have you deployed critical systems where human lives depend on?
"BEAM crashes with segmentation fault #7683" - https://github.com/erlang/otp/issues/7683
You dont use NIFs ?
"A native function that crashes will crash the whole VM." - https://www.erlang.org/doc/apps/erts/erl_nif.html
"Who Supervises The Supervisors?" - https://learnyousomeerlang.com/supervisors
skrebbel
The code can crash but it won't often crash your system (unless you use lots of badly tested NIFs, which most people don't), and that's all GP is saying. BEAM isn't magic but it is pretty robust by now.
Tbh I feel like this is not very unique these days, so I'm not sure how this point means a lot, esp in the context of using LLMs for coding. Eg most NodeJS code won't crash your system either (it'll only crash NodeJS).
throwawaymaths
memory exhaustion is a real thing though. be careful running BEAM applications that do lots of transformations on binary content... PDFs come to mind!
stevejb
> Until we get superhuman autonomous coding agents the human in the loop grokking the generated code is still the limiting factor.
They never get tired, work for pennies, can search the internet and your code base, follow rules, and iterate on test cases. This is better than I can do, so by my reference point as a human, the coding agents are superhuman already.
tcoff91
Then why do they often produce garbage for me and get stuck in a state where it either “fixes” type errors by casting to any or just straight up getting stuck?
They suck at react-native man god damn.
Capricorn2481
None of what you're saying really addresses the comment, which is a human needs to review all this or it likely won't work. Maybe they will get that work done faster.
But you have shared your experience, this is my experience.
- They get tired when the context is too big. They also can't be reliably run by themselves, so it doesn't really matter if they can be run at 3AM when I'm asleep, I wouldn't do that.
- Searching the internet with LLMs is ass because it combines the worst of both worlds (remember people have been using LLMs to NOT search the internet).
- It's a toss up whether "iterating on test cases" means follow the rules or get stuck in an infinite loop. I have had the latest and most expensive models ping pong themselves between the same two broken lines of code because they are just LLMs.
I'm enjoying Cursor for now, but I am also working on a string of really basic Laravel apps for a few clients and it still gets things wrong. They are useless for novel problems or niche tech.
null
bcrosby95
I love Elixir, Erlang, and BEAM, but tbh, not crashing is a fairly well solved problem in the web world regardless of language and runtime, in large part due to the request/response nature of things.
ipnon
Yes, it's true, but what I mean is that in Elixir I can just write the happy path and not crash the system. My Python code requires meticulous exception handling, sometimes taking up half of some functions. It's the design of the BEAM that allows you to focus on just the happy path, and this is really where most user value is derived, and it's the most fun code to write as well.
I am not the best Python programmer! I have crashed prod before, I will admit it. And this requires an alert, scurrying to the nearest terminal, an SSH console, some log spelunking, hopefully just a restart. But I have never had this experience deploying Elixir or Phoenix, and I am by no means the best Elixir programmer. Firefighting is to me the worst part of programming, and through a combination of interactive Elixir shells, process isolation, automatic process restarts, and a philosophy of "let it fail, it's no big deal," it has brought some joy back into my work. That alone is priceless!
I understand Elixir can seem overhyped, and I share that skepticism, but I keep coming back to it over the last half decade or so. This is the best endorsement I can give, I think.
sodapopcan
In Elixir, it's almost free to isolate the user who caused them (keyword: "almost"... there are no bulletproof solutions). In most other popular languages used for web programming, it's easy for a crash to affect many users without careful thought to prevent it.
bcrosby95
In my experience it isn't almost free. The "problem" being the overloaded nature of processes: their sole purpose isn't to isolate errors, its also to provide concurrency, a sort of access control (since a process goes through its mailbox 1 message at a time), and you also have to consider data access performance characteristics (since sending data across processes is copied).
So in an ideal world yes, you can isolate them, but I've never really achieved this panacea in practice, and its never been anywhere near free to try to suss out a design that optimally achieves all those differing design aspects at once.
rickcarlino
Having used Elixir for multiple years on something other than a server application, I disagree with calling Elixir a general purpose programming language. It’s really good for writing servers, I’ll give it that, but for stuff that isn’t an always-on network application, I felt the OTP way of doing things was designed for something I wasn’t building. Elixir makes it very easy to build servers, but the language and community are very biased towards client/server use cases. It certainly can be used for things other than server, much like I could build a web app using QBasic or Excel. The focus of the language, its history and the community around Elixir has always been server apps. To me, that’s the biggest indicator that it’s a specialized language rather than a general purpose language.
lawik
I think it is very accurate and should be uncontroversial to say that Elixir/Erlang/OTP are very angled towards building services. I'd say service rather than server because I don't think it is necessarily about client/server as much as doing a long-running job. Which very often is a server but I've done bots, workers and whatnots that I wouldn't necessarily think of as servers.
I think the language and ecosystem are fairly general-purpose but there are definitely a lot more general ecosystems. I think some of the big wins both Erlang and Rails have achieved (that Elixir build off of) have been about constraining the problem to be "a service" or "a web app with a database".
So you are spot on there.
One of the things I've found Elixir to be surprisingly nice for is as a replacement to my Python and Bash scripting. Shelling out is occasionally awkward but Mix.install is glorious and Task.async_stream is hilarious.
HappMacDonald
I'm curious which use cases you're reaching for that aren't client server?
Not to suggest that those don't exist or anything, just that there are so many dimensions available there that knowing more about which dimensions you'd most value having reach in might be enlightening. :)
Like: Video games? Desktop apps? Mobile apps? Embedded? Systems-level programming like OS or hardware drivers? Or one of a thousand other directions I can't think of just off the top of my head?
rickcarlino
In my case it was a non-resource constrained embedded system (several GB of RAM, gigabytes of storage not unlike a set top box application). The tooling was OK, but in retrospect, the community and language felt too biased towards server-client applications. Every time you search for a question, you inevitably bump into answers that assume you are building a Web app and don’t apply to more general use cases. Or OTP ends up getting in your way because you are trying to do something simple that does not require massively parallel scaleability. For a lot of these situations, I walked away from the language feeling like it would’ve been easier to just do it in Python, JS or some other general purpose language. All of the BEAM languages make heavy trade-offs in the name of concurrency, and in cases where concurrency is not a main concern, the gains just weren’t there compared to mainstream languages.
pdimitar
Thanks for sharing. I would reach for Golang or even Rust if I was you.
I work with Elixir for 9 years now (& love it) and I agree what you describe is not a good fit for it.
Elixir is a general-purpose language in the meaning of Turing-completeness. I never once felt tempted to write a CLI tool with it though.
greybox
The BEAM VM is generally terrible at any computationally heavy task. But what it lacks in performance, it makes up for in stability built-in to Erlang's OTP framework.
It's also "difficult" to integrate with existing C programs such as system drivers due to BEAM's execution model. It's possible to do, but there are a lot of foot guns & you have to be careful.
phinnaeus
I am a huge Elixir fan and I would basically never reach for it to build a CLI.
greybox
> I disagree with calling Elixir a general purpose programming language.
I was going to comment this seperately, I'm glad someone pointed this out. +1
bcrosby95
I like it for scripting because with the Flow module, concurrent code looks mostly like non concurrent code. You can also pull in dependencies right in the file.
I did a small experiment with a few different languages and Elixir had the fewest changes going from single threaded to parallel.
Clojure was the lowest loc in general.
borromakot
It having strengths and weaknesses doesn't make it not general purpose language.
drekipus
In your mind, what distinguishes a language as "general" or "specific" purpose?
I'd argue the community and focus of the language.
rickcarlino
Or, to your point, the historic design considerations that led to the creation of the language in the first place. In the case of BEAM, it was very specific.
borromakot
What I mean is that, you can write CLIs in Elixir. I have. You can write games in Elixir (others have, I haven't). They come with pros & cons. The Elixir community advances on many of those fronts regularly. I could write a web application in C, but I wouldn't.
gchamonlive
If your application doesn't need GenServer you shouldn't use GenServer.
Elixir is definitely not a language to write games in, but it's totally viable to write stuff that doesn't fit into the OTP model.
rickcarlino
What are some examples of large scale production systems written in Elixir that do not use OTP?
gchamonlive
I don't know and it's tangential to the question of whether "elixir is a general purpose language".
Might be important for you, but it's irrelevant for my comment.
schultzer
I disagree, it’s wonderful for writing compilers in as well https://github.com/elixir-dbvisor/sql I would go so far as to say superior to a lot of other languages that do not have advanced pattern matching.
pjmlp
So is any ML or Lisp descendent.
westoque
Came here to say this. What makes a great general purpose language is not only in the programming part but also in transportability. I think Go takes the cake here. If only Elixir apps could be compiled and transported as a binary to similar systems and it works, then it would make it a great general purpose language. Until then, it's really only a good client/server language as it was intended to be.
CompoundEyes
Tried Pheonix framework / Elixir in Cursor out of curiosity last weekend and it was the best experience I’ve had so far with agentic coding. I don’t know either yet — purely an experiment. My instructions doc required TDD, a feature list, had links to pheonix/elixir/tailwind/postgres doc and sonnet 4 did a great job utilizing pheonix cli which reduces a lot of boilerplate generation. Proved changes worked with tests at each iteration. The key thing was it didn’t lose its bearings as the project got more complex. Other web app frameworks I’m familiar with invariably get lost adding npm packages left and right, fiddling with config files and wrapped in an “extension cord” needing rescuing. I think there is something to so many node world version changes and approaches in framework implementation in training data that pollute the decision making. Also I realized watching sonnet construct the project was actually a really compelling way of learning a new framework/language to me. I can stop and ask “why are you doing this? how does that work?’ and inspect the code. Made me interested in learning more about elixir.
ricw
I've been using elixir / phoenix / liveview for a year now, basically since LLM coding has been a thing and it's been transformative. The usual "getting started" problems were so diminished that i feel like i hardly missed a beat. The usual "this won't compile / how do i do this in a new unknown language" issues that previously could have taken hours to resolve were basically gone. My LLM pair programmer just took care of it. Coming from python / django / cue, it's a breath of fresh air. It's so much easier as all the paradigms come built in with the stack (async workers, etc). The elixir / erlang library is surprisingly complete.
With regards to producing code, it seems to be doing very well. The most impressive thing it did for me was a PDF OCR from scratch using google cloud. All i had to do was plug in my credentials, hook up the code and it just worked. Magic.
Highly recommended.
the_duke
I have been arguing for a while that very strict languages with a heavy type system are ideal for agent coding.
The stricter the language, the harder it is for the LLM to produce nonsense, at least if it can get compilation errors and run tests. And the easier it is to validate that the output is correct, because the types already tell a lot of the story.
A language with dependent types, linear types, etc... would be ideal, but alas...
At the moment Rust is the sweet spot. Fairly popular (and hence known to LLMs and with a fairly good ecosystem), great error messages to guide resolution of problems, stricter type system and more compile-time guarantess than almost all of the other semi-popular languages...
Now Rust isn't trivial to write, for both humans and LLMs, and the output was pretty bad for a long time.
But with the ability to run `cargo check` and execute tests, even the current first iteration of agents is really quite good at iterating until it gets a working result.
nileshtrivedi
Types only go far. Most of the semantics of a function's behavior is in its name, documentation and tests.
I think it is time to invent a unifying framework for Types, Tests and Evals: https://nilesh.trivedi.link/thoughts/we-need-a-formal-theory...
fernmyth
Windfall, for those who want it.
LLMs were fantastic for writing a project[0] in a new, niche language[1]. They help write any missing libraries. They help iterate when I get stuck on language aspects. They explain concepts as well as the median SO post, and much better than the posts that don't exist.
[0] https://github.com/TedSinger/chatfile/
[1] https://crystal-lang.org/ - quite pleasant
3by7
Crystal is great! Which LLMs were used in that project? In my short and not very recent experience the LLM frequently mixed up Crystal and Ruby in the code they write.
fernmyth
Cursor with defaults, I guess mostly `cursor-small`. Typically I write and adjust function names or signatures and let tab-complete draft the code and propagate refactors.
It does mix up Crystal and Ruby, but the compiler catches it.
3by7
That matches my experience, so I guess it may be a decent experience for someone new to the language and a bit more frustrating for someone more experienced on it (like me).
sitkack
You should keep a log of all the failures and then have an LLM form a patch-doc that fixes the Crystal codegen behavior in context. Your failure rate will go way way down.
miki123211
I think the core insight of this article, and it's something I haven't thought about before in this way, is that any successful programming language needs to "market itself" to LLMs and LLM developers.
We had the "first wave" of languages that were marketed to decision makers (Java), the second wave that was marketed to developers (Ruby on Rails, Rust), I think a third wave is coming, where the language will be designed to be LLM friendly from the ground up.
inerte
I was looking for a programming language that's being written with LLMs in mind, and used ChatGPT to give me some pointers so I can start some research https://chatgpt.com/share/6841d3b7-13a8-800f-9bcc-0f7859114c...
In my mind (I am a non-academic that never really designed a new programming language), I can imagine strong typing, terseness, and no optional syntax (you can do this multiple ways) would be really cool for LLMs.
I did come across a few languages / people trying to design programming languages to be used with LLMs / AI Agents, and I think the most promising thing I found is https://www.moonbitlang.com/blog/moonbit-ai - which takes the whole idea of working with LLMs to another level, with actual features designed to work with agents (not only syntax).
irq-1
Moonbit lang is really interesting. Looks like it's been submitted but ignored by HN.
morkalork
If you wanted to go all in, you'd want a language that is denser so you get more efficiency out of tokens. Since it's being used by LLMs, readability by humans can take a back seat. Obviously the answer is: Perl.
But seriously though, a high-level language designed for LLMs would be interesting, maybe with a translation layer to something more developer friendly on top.
borromakot
High information density is good for LLMs. https://ash-hq.org benefits from this, but hurts due to being fairly new. https://hexdocs.pm/usage_rules is helping.
jimbokun
> If you wanted to go all in, you'd want a language that is denser so you get more efficiency out of tokens.
That's Lisp because nothing compresses the number of tokens you have to write more than Lisp Macros.
reddit_clone
APL is the densest language I have come across.
There may not be enough code out there for LLMs to pick it up though.
tobyhinloopen
Ive seen some new tools use “docs for LLMs”, maybe Elixir / Phoenix can provide these if they haven’t already.
Functional programming works great on LLMs because there’s no hidden side effects. I let my LLM tools write functional style NodeJS but that’s only because Node is easiest to test with.
badsectoracula
> any library can include a usage-rules.md file - essentially very terse documentation designed specifically for LLM context windows, explaining what to and what not to do when using the library.
This is useful for humans too, though personally i hope we go away with context window limitations in the future - perhaps context windows could be something like 'CPU registers' that the CPU likes to work with internally but there will also be an external "large" memory that LLMs can access and work with.
artem2471
My experience, even though rather limited, tells me that llm’s work well with languages like Elm and Rust, with powerful static analysis and great compiler ux.
aczerepinski
I've been using Elixir with Gemini for the past couple days, and the LLM is less successful than it has been with other languages I use. It gets stuck sometimes - for example it couldn't figure out how to use a JWT encoding/decoding library so I needed to intervene. Have I already gotten this spoiled by uncanny performance with Go/Ruby and especially JS/TS?
debian3
Gemini is not great in Elixir, Sonnet is the best by far.
aczerepinski
Thanks for that suggestion - looks like you're right.
Dowwie
The Claude models are so far ahead of the pack right now with Elixir and Erlang capabilities, comparing with o3, gemini2.5, grok3-think, and ds-r1.
Elixir is so good for workflows and pipelines, utilizing all available hardware resources. It makes sense why Elixir will be used more going forward for agentic workflows, but the greenfield engineers/architects are rushing to market with Python and here we are.
bad_haircut72
With tidewave the LLM has access to iex, it can do its own repl loop debugging and investigations, its awesome - Elixir will thrive in the age of LLMs
It's a windfall. Having written the same project in Phoenix and FastAPI/Expo, I assumed LLMs would be better at writing Python and React. But the amount of boilerplate and opportunities for harmful side effects in the code means I quickly generate large amounts of code that I then need to go back and manually grok to align my understanding. With Elixir this loop is much smaller. I generate a small amount of code, check for validity (much easier to verify in a functional language), and repeat this loop.
Until we get superhuman autonomous coding agents the human in the loop grokking the generated code is still the limiting factor. LLMs are marginally better at generating mainstream languages than Elixir, but the generated Elixir code is much easier to understand and modify, and because of the runtime, will practically never crash your system.