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.
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).
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
1. Yes
2. You didn't answer my question? Your answer ""Practically never crash" ignores software bugs, resource exhaustion, or bad architecture" indicates I think ignorance of actually deploying BEAM applications, and instead just making statements based on things you've heard. Isolating failures in software systems is not a bad thing. The developer can choose the boundaries between the elements of their system up to and including "stopping the entire application if things go wrong".
Instead of answering on the technical merits of an argument, you went for an ad hominem so...? I ask again...do you use NIFs ?
"If the entire computer crashes, you're screwed. you can't really do fault tolerant computation from one machine."
- Joe Armstrong
And the reason for the quote above is to remind you Erlang/BEAM gives you tools for fault containment and recovery, but not immunity from failure.
Say: Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows...And we will conclude in a nice agreement. :-)
> Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows
Correct.
> you went for an ad hominem
Not my intention. I asked a simple question, and you answered a question with a question, effectively gish galloping me with "but there are ways it can crash" except nobody said there wasn't. It stopped feeling like a technical debate at that point.
FWIW, I didn't make the original comment you replied to, I just pointed out that this statement:
> "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture
felt like a surface response to the OPs sentiment of localized failures not tanking an entire software system.
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).
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.
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.
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.
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.
Processes are only overloaded in that they are a primitive. I'm not sure if this is what you're implying, but a single process shouldn't be doing all those jobs at once. For example only supervisors should be dealing with error isolation. As for sending large amounts of data between processes, I can only speak really generally here, but one common way is to flip the script and send functions to the data instead of the other way around but ya, bigger topic! When I say for "free" I mean more like my sibling comment where you don't have to think about every possible way something can fail.
> 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.
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.
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?
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.
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.
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?
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.
I wrote a custom bioinformatics pipeline (CLI) in Elixir the other week. Not a terrible experience. Being able to save annotations to a binary and unpickle using term_to_binary was amazing.
If that CLI tool integrates with a bigger ecosystem (like connect to a cluster and reuse data / services) that's already written in Elixir, then that would make it an even bigger no-brainer to use.
Also hi, haven't seen you active in ElixirForum in a long time.
css is Turing complete, XSL-T is Turing complete, so I don't think Turing completeness is a good measure of if something is a general purpose programming language. I would argue for environmental completeness - does the language have the possibility of accessing everything in the operating system it runs in? If so, it is environmentally complete and usable as a general purpose programming language.
Despite something being a general purpose programming language there are some tasks it may be better at than others. Visual Basic is a general purpose programming language but really you would most often use it for a particular subset of purposes. Elixir it seems is not good for writing a CLI.
I was mostly clarifying what most people I've met believe is a "general-purpose language". I agree with your take on telling it like it is for the practical needs of the commercial programmers / users of a language.
And again, as a guy who loves Elixir, it absolutely is not suited for writing CLI tools. Many would say it can be easily done, the community even has a few really good libraries for it as well, but the BEAM VM startup time absolutely kills its utility for tooling for me.
And, as others also said, Erlang / Elixir simply excel at orchestrating a lot of runtime micro-agents, each with their own small responsibility. And they do this better than any other language I've seen. But, for one-offs / scripts / CLI tools, Golang / Rust are very difficult to dethrone. We could also add Zig / D / V and others, I suppose, but I am not familiar with them.
yeah sorry, I've just got some trauma from people claiming that languages can be used for stuff they can't really be used for just because of Turing completeness.
What irked me many times: people around here idolizing a certain PL they learned as kids and giving it much more credit than it ever deserved.
[/rant]
What I'm actually saying is that I completely understand the almost PTSD levels of reactions when people say "you actually can do ${obviously_difficult_thing} in ${obviusly_niche_language}!". I have the same reactions towards these statements myself.
I mean sure, if you're a good enough physicist you probably can make a lounge chair out of toothpicks, toilet paper tubes, rubberbands and glue. Doesn't mean that it's sustainable or viable to do so for everyone else. It's just your hobby; go wild and have fun! Don't pretend that's how lounge chairs should be produced.
Same goes for PLs.
A lot of PLs should have remained niche curiosities and research ideas -- but nothing beyond that. Sadly we both know how people are. They easily fall in love and lose all scientific objectivity.
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.
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.
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.
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.
My main point is that a language’s historic design considerations, community and ecosystem play a huge part in determining its applicability to a particular domain. Years of personal anecdote, coupled with the history of the project, and what people are building with it in practice (rather than what could be built in theory) drive my conclusion that it is not a general purpose language. That doesn’t mean it’s not a good language for what it was historically intended for.
But in the process you are redefining general purpose language to general applicable language and making everybody confused. Why not adhere to the general convention and accept that Elixir is totally a general purpose language but has limited applicability depending on the domain.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
> 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.
Claude is reasonably good at Elixir in my experience, but gets a bit carried away with logging. Gemini is quite shit. o3 is pretty great - but I mostly use it to review things when I get stuck with claude.
It definitely feels like Gemini has been fine-tuned to ace the react benchmarks.
It turns out that I don’t know Elixir at all, but I’m vibe coding an app in it.
I didn’t ask what language or framework to use. I “heard of Elixir on a blog post, or they saw this article topping the hacker news charts.”
I even asked an LLM what else I should consider besides Phoenix, but after considering, I stuck with it.
Gemini gets stuck sometimes, but I just ask ChatGPT to help and bust through.
It kind of reminds me of when I wrote code and couldn’t easily see the errors. Another pair of eyes can really help. Another LLM that didn’t write the code can really help, too.
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.
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.
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?
Good article as it gives advice on what to do proactively as a community to assure your relevance in these LLM times.
The steps taken of small, compressed 'LLM docs' make me think of ideas of the semantic web. That one never gained traction but as search more and more gets replaced by AI (even by enterprises formerly primarily identified with search) strategies like this become more and more relevant.
I have been using LLMs to write Elixir full time at work for months now. AMA, if anyone is interested.
I sometimes have different thoughts of approach than Zach, but this post really resonates with me. I've been in Elixir full time for over 10 years and would love to see an evolution in its adoption fueled by this.
I'm curious what your setup looks like. Do you use an IDE like Cursor or Windsurf, an editor like Zed or more directly an agent like Claude Code?
Have you used tidewave.ai? The demo from Jose looks fun, but I've yet to play with it.
What use-cases have LLMs shined in for you? I've really enjoyed using it to reduce the learning curve, eg to use Svelte and LiveSvelte on a small side-project.
(I've been using Rails for 20 years, Erlang & Elixir for ~10, but spend more time on the product side nowadays.)
> Do you use an IDE like Cursor or Windsurf, an editor like Zed or more directly an agent like Claude Code?
At work, we use both Windsurf and Cursor.
At home, I also use Claude Code.
> Have you used tidewave.ai?
My coworkers have and are impressed, I can't speak to it.
> What use-cases have LLMs shined in for you?
Well, I managed to literally have it do all my work for 3 weeks. I didn't write a single line of code. That was pretty cool. I didn't even cherry-pick work best for the LLM. It was my normal flow.
I also use Claude code as an interactive tutor. I will have it implement something, break it into logical commits, then in each one break a few pieces and write tests for them and have me learn by fixing the broken tests.
The bias towards frameworks and languages for which there is most abundant code is not only real, but self-reinforcing. As "vibe coding" (I hate that term) devs crank out AI-generated code and make it available to be trained on, LLMs will see more of that code and therefore be more likely to recommend those same code pathways.
This also makes it much more difficult for new, better, and innovative ideas to break through the noise floor.
We will start to see the emergence of frameworks and libraries (and languages?) that are optimised for LLM coding rather than human coding. Maybe - overly verbose and repetitive, but easy to generate correctly and very flexible? Or maybe super obscure syntax that allows an LLM to output much more information per token emitted?
At lot of current paradigms are about things like abstraction and DRY that matter to humans creating and maintaining a code base. An agent driving some LLMs will have other priorities.
It’s already easy to generate such things without LLMs. Gleam, another BEAM language, is intentionally very simple and can tend towards the verbose however because of strict typing the lsp has code actions that’ll generate most of that verbose code for you in a way that’s provably correct, instant, and doesn’t require a network connection. Maybe a gleam specific agent could utilize those code actions?
In his ElixirConf EU 2025 presentation [1], Chris McCord demonstrated Phoenix.new [2], an LLM-augmented VS Code in a browser that knows how to build Elixir/Phoenix apps.
McCord began by reviewing the current scripted and templated Phoenix code generator. He then showed how a tool-invoking LLM agent could be implemented in one screen of Elixir code. The bulk of his talk demonstrated generating apps with the Phoenix.new tool. It was interesting to see the tool generate development plan and begin coding to implement the plan.
I was fascinated to hear McCord explain and critique the LLM agent as it generated a Phoenix app.
"[It's] going to come up with a plan for our app and codify that into a Markdown file."
"Now it's going to take our high-level plan and make it into an expanded plan for us and itself."
"You can say, 'I changed the plan; execute the plan.'"
"We just recursed in the server and we did a req post. It's doing a req post right now and the tokens are coming back!"
"The agent just invoked a tool, which is 'I'm going to create a file.'"
"Hopefully it does a 'surgical modify tool,' which makes it not have to modify the whole file."
"A run-time error! Oh, no! Live coding is terrible. Oh, wait. It knows I need to add some missing functions here."
"You would be like, 'Oh, no, the page broke. What happened? I'm going to look at this error.' We just send that thing back to the chat completions endpoint and magic comes out and fixes the error."
"It didn't change a web file. We should fix that."
"This is an issue that humans hit; Steff and I need to fix that."
"It added the input at the bottom. That's not ideal."
"The agent decided to idle here. ... The way I implemented this is everything the agent responds with is a tool call and it has an idle tool and that's what it invokes when it is done."
yes large parts of it were built with itself, including non elixir/phoenix things. The entire headless browser (node playwright script) for example was made inside phoenix.new and it iterated on itself. More to come soon!
Yeah. I was there and this demo was a jolt. More so was the phrasing we were witnessing the end of our punchcard era. I don’t know if it’s the history nerd in me or what, but that thought has been living in my head ever since. Looking forward to playing with Phoenix.new—and keeping an eye out for looms to smash. Kudos, Chris.
Very good article with actionable ideas and suggestions. Thanks for writing and sharing!
Another problem that Elixir community must address is to make it super-easy ("one-click") to deploy to hosting of choice (own VPS or cloud) with most things working auto-magically (configured): app, DB, admin-panel, observability (app, server, db), backups/restore, domain, emails (admin, transactional), even maybe CDN/caching and perhaps some integrations (payments, uptime, alerts, etc.)
Make it a no-brainer as much as possible, otherwise it's a choice to buy (and fight with) a ready SaaS-in-a-box solutions, or go with FREE: Astro+CF_Workers+Neon+any_JS_payment_and_email_packages vibe-coding today!
Dialyzer is easy to intentionally or accidentally mislead, so it's only as good as the quality of human-authored typespecs (which are sometimes absent from major mainstream Hex packages) and the inference is simultaneously more open-ended and unhelpfully precise than most people are accustomed to if they have prior experience with something like Rust or TypeScript. People also frequently struggle to accurately interpret its output.
I still find dialyzer to have non-zero value, but it's not uncontroversial and it's not usefully integrated with the vanilla language tooling. Mix/elixirc is not generally going to throw you a bone if you violated a syntax-correct type spec. It's an opt-in secondary tool and that diminishes its utility a tad.
Making this point in typed vs untyped debates about Elixir/Erlang specifically has never once lead to either an educational moment or a change of opinion on either side. You know exactly what they meant by that, and you're using a different definition than they are to try to pull a pedantic gotcha. It's snide and unproductive.
My takeaway from these articles instead is that vibe coders and Copilot jockeys are just people in SWE that don't like the craft, so instead of doing the work themselves, are learning how to communicate the requirements effectively with a low-IQ code monkey.
They have turned themselves into micro-managers of an idiot savant.
Today they are low-IQ code monkeys. Yesterday they were low-IQ writers of grade-school essays. So what will they be tomorrow?
At minimum, still low-IQ code monkeys. Especially since AI research has come in fits and starts and stalls for many decades now.
But a weakly monotonic process rarely remains plateaued for very long, now does it? It only has one direction to respond to any changes in the environment after all. Tomorrow's models will either be the same or they will be smarter.
How much smarter do they need to get for that "low-" prefix to go away then?
Tomorrow, if you keep trying to make them smarter, they might decide to take over; who knows, maybe they'll let you live in a human zoo. I'll probably be the first one to be turned into biofuel.
Do people get into woodworking to use tools or do they get into woodworking to make furniture? We all have an approach to craft that is an ever-changing combination of self-fulfillment, practicality and external pressures.
Yep. Tfa mentions elixir being below the suggestions to rewrite a web app in rust and golang (??). The conclusion here should be that the LLM cannot be trusted that much, but we know that’s not going to happen, so anyone who wants to remain relevant must start playing games and damn the consequences.
Now instead of improving the language in other ways there will be distracting constant pressure to appease the machine. Now call this added “efficiency” with AI, similar to how adtech calls hiring your own director of marketing and paying tons of people who actually work for google with money from your own company coffers “5:1 ROI on advertising investment“.
If you're worried about people who literally have no opinion or preference about the tech stack they use taking your job... actually, I don't have anything witty to say beyond those people are not going to take your job.
Those people will go back to selling real estate or whatever it was they were doing before someone convinced them to take a nine week bootcamp.
> If LLMs turn out to be a fad and you’re reading this after they jump the shark, please accept this article as a historical artifact from a time when we entertained the idea that fancy autocomplete might eat the world.
> Aside, for those who don’t know what Elixir is: it’s the best general purpose language in the world and if you haven’t heard of it wake up and smell the bacon.
I find a certain humor in this, as elixir is more likely to be a fad than LLM's. I like and use elixir, but their lightweight processes are too restrictive for a lot of use cases. It's great for scaling web apps, however, and I think it's worth recommending over nodejs or other javascript based backends for a lot of people.
> I find a certain humor in this, as elixir is more likely to be a fad than LLM's. I like and use elixir, but their lightweight processes are too restrictive for a lot of use cases
I'm not an Elixir user, but you're criticizing Erlang/OTP, which has been around way too long to be considered a "fad".
Elixir/Erlang is best for building long-running systems that you don't want to go down. Erlang's creators optimized for stability (phone systems) and sort of reinvented concurrency and distribution in support of that goal. There are some great talks by Joe Armstrong about this on YouTube, highly recommend!
For CPU-bound tasks and number crunching you can always just write it in Rust (or C or Zig) and NIF out to it from Elixir.
As a dev who builds apps that are served over the internet, it covers everything I need. Maybe that's a specialty niche.
There is no such fad. The vast majority of seasoned BEAMists will tell you that it is not for everything. There are enthusiasts bringing some surprising stuff to it which is great as it mostly falls into the category of "useful for things users are already outsourcing to other languages." But there is a whole host of things it will just never be able to do and no is pretending that it will.
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.
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).
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.
They can already do that, it depends on the system prompt.
>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.
Lol exactly. "LLMs write good code if you make small changes and write tests!" Groundbreaking stuff
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
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.
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.
>> and because of the runtime, will practically never crash your system.
"Practically never crash" ignores software bugs, resource exhaustion, or bad architecture
Have you written/deployed Elixir before?
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
1. Yes 2. You didn't answer my question? Your answer ""Practically never crash" ignores software bugs, resource exhaustion, or bad architecture" indicates I think ignorance of actually deploying BEAM applications, and instead just making statements based on things you've heard. Isolating failures in software systems is not a bad thing. The developer can choose the boundaries between the elements of their system up to and including "stopping the entire application if things go wrong".
Instead of answering on the technical merits of an argument, you went for an ad hominem so...? I ask again...do you use NIFs ?
"If the entire computer crashes, you're screwed. you can't really do fault tolerant computation from one machine."
And the reason for the quote above is to remind you Erlang/BEAM gives you tools for fault containment and recovery, but not immunity from failure.Say: Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows...And we will conclude in a nice agreement. :-)
> Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows
Correct.
> you went for an ad hominem
Not my intention. I asked a simple question, and you answered a question with a question, effectively gish galloping me with "but there are ways it can crash" except nobody said there wasn't. It stopped feeling like a technical debate at that point.
FWIW, I didn't make the original comment you replied to, I just pointed out that this statement:
> "Practically never crash" ignores software bugs, resource exhaustion, or bad architecture
felt like a surface response to the OPs sentiment of localized failures not tanking an entire software system.
If perfection is your bar, you're going to be looking for a stack for a very long time.
I am not aiming for perfection, just correcting Erlang mythology :-)
I can guarantee you Erlang wont save you from an Ericsson AXD301 switch with a full storage...
What languages/frameworks/runtimes will save you from full storage on a single system?
Apparently Erlang....
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).
memory exhaustion is a real thing though. be careful running BEAM applications that do lots of transformations on binary content... PDFs come to mind!
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.
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.
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.
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.
Processes are only overloaded in that they are a primitive. I'm not sure if this is what you're implying, but a single process shouldn't be doing all those jobs at once. For example only supervisors should be dealing with error isolation. As for sending large amounts of data between processes, I can only speak really generally here, but one common way is to flip the script and send functions to the data instead of the other way around but ya, bigger topic! When I say for "free" I mean more like my sibling comment where you don't have to think about every possible way something can fail.
As much as people love to hate it, PHP is also really good here. Each request is isolated.
> 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.
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.
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.
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.
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.
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?
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.
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.
I wrote a custom bioinformatics pipeline (CLI) in Elixir the other week. Not a terrible experience. Being able to save annotations to a binary and unpickle using term_to_binary was amazing.
If that CLI tool integrates with a bigger ecosystem (like connect to a cluster and reuse data / services) that's already written in Elixir, then that would make it an even bigger no-brainer to use.
Also hi, haven't seen you active in ElixirForum in a long time.
css is Turing complete, XSL-T is Turing complete, so I don't think Turing completeness is a good measure of if something is a general purpose programming language. I would argue for environmental completeness - does the language have the possibility of accessing everything in the operating system it runs in? If so, it is environmentally complete and usable as a general purpose programming language.
Despite something being a general purpose programming language there are some tasks it may be better at than others. Visual Basic is a general purpose programming language but really you would most often use it for a particular subset of purposes. Elixir it seems is not good for writing a CLI.
I was mostly clarifying what most people I've met believe is a "general-purpose language". I agree with your take on telling it like it is for the practical needs of the commercial programmers / users of a language.
And again, as a guy who loves Elixir, it absolutely is not suited for writing CLI tools. Many would say it can be easily done, the community even has a few really good libraries for it as well, but the BEAM VM startup time absolutely kills its utility for tooling for me.
And, as others also said, Erlang / Elixir simply excel at orchestrating a lot of runtime micro-agents, each with their own small responsibility. And they do this better than any other language I've seen. But, for one-offs / scripts / CLI tools, Golang / Rust are very difficult to dethrone. We could also add Zig / D / V and others, I suppose, but I am not familiar with them.
yeah sorry, I've just got some trauma from people claiming that languages can be used for stuff they can't really be used for just because of Turing completeness.
I agree and completely sympathize.
[rant]
What irked me many times: people around here idolizing a certain PL they learned as kids and giving it much more credit than it ever deserved.
[/rant]
What I'm actually saying is that I completely understand the almost PTSD levels of reactions when people say "you actually can do ${obviously_difficult_thing} in ${obviusly_niche_language}!". I have the same reactions towards these statements myself.
I mean sure, if you're a good enough physicist you probably can make a lounge chair out of toothpicks, toilet paper tubes, rubberbands and glue. Doesn't mean that it's sustainable or viable to do so for everyone else. It's just your hobby; go wild and have fun! Don't pretend that's how lounge chairs should be produced.
Same goes for PLs.
A lot of PLs should have remained niche curiosities and research ideas -- but nothing beyond that. Sadly we both know how people are. They easily fall in love and lose all scientific objectivity.
So yeah, I quite get your frustration.
I am a huge Elixir fan and I would basically never reach for it to build a CLI.
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.
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.
It having strengths and weaknesses doesn't make it not general purpose language.
In your mind, what distinguishes a language as "general" or "specific" purpose?
I'd argue the community and focus of the language.
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.
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.
I would honestly have a much easier time writing a web app in C than a game in Elixir.
You are probably right
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.
What are some examples of large scale production systems written in Elixir that do not use OTP?
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.
My main point is that a language’s historic design considerations, community and ecosystem play a huge part in determining its applicability to a particular domain. Years of personal anecdote, coupled with the history of the project, and what people are building with it in practice (rather than what could be built in theory) drive my conclusion that it is not a general purpose language. That doesn’t mean it’s not a good language for what it was historically intended for.
But in the process you are redefining general purpose language to general applicable language and making everybody confused. Why not adhere to the general convention and accept that Elixir is totally a general purpose language but has limited applicability depending on the domain.
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.
So is any ML or Lisp descendent.
> 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
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.
https://github.com/burrito-elixir/burrito
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.
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.
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.
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...
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
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.
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.
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).
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.
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.
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).
Moonbit lang is really interesting. Looks like it's been submitted but ignored by HN.
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.
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.
> 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.
APL is the densest language I have come across.
There may not be enough code out there for LLMs to pick it up though.
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.
> 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.
Claude is reasonably good at Elixir in my experience, but gets a bit carried away with logging. Gemini is quite shit. o3 is pretty great - but I mostly use it to review things when I get stuck with claude.
It definitely feels like Gemini has been fine-tuned to ace the react benchmarks.
It turns out that I don’t know Elixir at all, but I’m vibe coding an app in it.
I didn’t ask what language or framework to use. I “heard of Elixir on a blog post, or they saw this article topping the hacker news charts.”
I even asked an LLM what else I should consider besides Phoenix, but after considering, I stuck with it.
Gemini gets stuck sometimes, but I just ask ChatGPT to help and bust through.
It kind of reminds me of when I wrote code and couldn’t easily see the errors. Another pair of eyes can really help. Another LLM that didn’t write the code can really help, too.
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
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.
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.
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?
Gemini is not great in Elixir, Sonnet is the best by far.
GitHub Copilot's Sonnet 4 is not great in Elixir either, but I'm not sure if it's because of Copilot or Sonnet.
Thanks for that suggestion - looks like you're right.
Good article as it gives advice on what to do proactively as a community to assure your relevance in these LLM times. The steps taken of small, compressed 'LLM docs' make me think of ideas of the semantic web. That one never gained traction but as search more and more gets replaced by AI (even by enterprises formerly primarily identified with search) strategies like this become more and more relevant.
I have been using LLMs to write Elixir full time at work for months now. AMA, if anyone is interested.
I sometimes have different thoughts of approach than Zach, but this post really resonates with me. I've been in Elixir full time for over 10 years and would love to see an evolution in its adoption fueled by this.
I'm curious what your setup looks like. Do you use an IDE like Cursor or Windsurf, an editor like Zed or more directly an agent like Claude Code?
Have you used tidewave.ai? The demo from Jose looks fun, but I've yet to play with it.
What use-cases have LLMs shined in for you? I've really enjoyed using it to reduce the learning curve, eg to use Svelte and LiveSvelte on a small side-project.
(I've been using Rails for 20 years, Erlang & Elixir for ~10, but spend more time on the product side nowadays.)
> Do you use an IDE like Cursor or Windsurf, an editor like Zed or more directly an agent like Claude Code?
At work, we use both Windsurf and Cursor. At home, I also use Claude Code.
> Have you used tidewave.ai?
My coworkers have and are impressed, I can't speak to it.
> What use-cases have LLMs shined in for you?
Well, I managed to literally have it do all my work for 3 weeks. I didn't write a single line of code. That was pretty cool. I didn't even cherry-pick work best for the LLM. It was my normal flow.
I also use Claude code as an interactive tutor. I will have it implement something, break it into logical commits, then in each one break a few pieces and write tests for them and have me learn by fixing the broken tests.
LLMs greatly reduced my annoyance in learning various plumbing details in Phoenix (dead views), LiveView and Ash.
What would be days or weeks of impatient unpacking of long tutorials and guides has shrunk to days, in rarer occasions days.
The bias towards frameworks and languages for which there is most abundant code is not only real, but self-reinforcing. As "vibe coding" (I hate that term) devs crank out AI-generated code and make it available to be trained on, LLMs will see more of that code and therefore be more likely to recommend those same code pathways.
This also makes it much more difficult for new, better, and innovative ideas to break through the noise floor.
A point made by Theo- t3․gg in the following. 'React is the last framework.'
https://www.youtube.com/watch?v=P1FLEnKZTAE
We will start to see the emergence of frameworks and libraries (and languages?) that are optimised for LLM coding rather than human coding. Maybe - overly verbose and repetitive, but easy to generate correctly and very flexible? Or maybe super obscure syntax that allows an LLM to output much more information per token emitted?
At lot of current paradigms are about things like abstraction and DRY that matter to humans creating and maintaining a code base. An agent driving some LLMs will have other priorities.
It’s already easy to generate such things without LLMs. Gleam, another BEAM language, is intentionally very simple and can tend towards the verbose however because of strict typing the lsp has code actions that’ll generate most of that verbose code for you in a way that’s provably correct, instant, and doesn’t require a network connection. Maybe a gleam specific agent could utilize those code actions?
Elixir and Phoenix is my tech stack of choice for many years, nearly a decade now.
The two thorns that remain:
1. The Phoenix Form <> changeset story is still quite tricky, even to me. It's very 'yappy'.
2. Elixir not having types hurts when a project grows. Even typespecs help very little. I wish we had proper types and let the computer flag stuff.
Same. My tech stack now is: Phoenix, Elixir, Inertia.js, and React.
I started calling it the PIER stack. lol. I prefer React to LiveView.
I just went back to rails 8 for this one. Vibe coding easily and it feels like an SPA out of the box.
Same here. I’ve just setup vite, inertia and react with shadcn so we can vibe code our admin. Works incredibly well
In his ElixirConf EU 2025 presentation [1], Chris McCord demonstrated Phoenix.new [2], an LLM-augmented VS Code in a browser that knows how to build Elixir/Phoenix apps.
McCord began by reviewing the current scripted and templated Phoenix code generator. He then showed how a tool-invoking LLM agent could be implemented in one screen of Elixir code. The bulk of his talk demonstrated generating apps with the Phoenix.new tool. It was interesting to see the tool generate development plan and begin coding to implement the plan.
I was fascinated to hear McCord explain and critique the LLM agent as it generated a Phoenix app.
"[It's] going to come up with a plan for our app and codify that into a Markdown file."
"Now it's going to take our high-level plan and make it into an expanded plan for us and itself."
"You can say, 'I changed the plan; execute the plan.'"
"We just recursed in the server and we did a req post. It's doing a req post right now and the tokens are coming back!"
"The agent just invoked a tool, which is 'I'm going to create a file.'"
"Hopefully it does a 'surgical modify tool,' which makes it not have to modify the whole file."
"A run-time error! Oh, no! Live coding is terrible. Oh, wait. It knows I need to add some missing functions here."
"You would be like, 'Oh, no, the page broke. What happened? I'm going to look at this error.' We just send that thing back to the chat completions endpoint and magic comes out and fixes the error."
"It didn't change a web file. We should fix that."
"This is an issue that humans hit; Steff and I need to fix that."
"It added the input at the bottom. That's not ideal."
"The agent decided to idle here. ... The way I implemented this is everything the agent responds with is a tool call and it has an idle tool and that's what it invokes when it is done."
[1] https://www.youtube.com/watch?v=ojL_VHc4gLk
[2] https://phoenix.new/
I wonder if the phoenix.new website was built with phoenix.new...
This site can’t be reached
The connection was reset.
yes large parts of it were built with itself, including non elixir/phoenix things. The entire headless browser (node playwright script) for example was made inside phoenix.new and it iterated on itself. More to come soon!
It's hosted on fly.io... :)
Yeah. I was there and this demo was a jolt. More so was the phrasing we were witnessing the end of our punchcard era. I don’t know if it’s the history nerd in me or what, but that thought has been living in my head ever since. Looking forward to playing with Phoenix.new—and keeping an eye out for looms to smash. Kudos, Chris.
Very good article with actionable ideas and suggestions. Thanks for writing and sharing!
Another problem that Elixir community must address is to make it super-easy ("one-click") to deploy to hosting of choice (own VPS or cloud) with most things working auto-magically (configured): app, DB, admin-panel, observability (app, server, db), backups/restore, domain, emails (admin, transactional), even maybe CDN/caching and perhaps some integrations (payments, uptime, alerts, etc.)
Make it a no-brainer as much as possible, otherwise it's a choice to buy (and fight with) a ready SaaS-in-a-box solutions, or go with FREE: Astro+CF_Workers+Neon+any_JS_payment_and_email_packages vibe-coding today!
... PS: Minor edits, love Elixir!
Why did you "scroll past" the Go solutions? Types, man, types. Elixir has no types. Ergo, I can't use it.
I thought I would miss static typing more than I do. Elixir's pattern matching is actually extremely powerful in its own right.
> Types, man, types. Elixir has no types.
Elixir (and BEAM more generally) has Dialyzer, which does static analysis including (but not limited to) type checking.
Dialyzer is easy to intentionally or accidentally mislead, so it's only as good as the quality of human-authored typespecs (which are sometimes absent from major mainstream Hex packages) and the inference is simultaneously more open-ended and unhelpfully precise than most people are accustomed to if they have prior experience with something like Rust or TypeScript. People also frequently struggle to accurately interpret its output.
I still find dialyzer to have non-zero value, but it's not uncontroversial and it's not usefully integrated with the vanilla language tooling. Mix/elixirc is not generally going to throw you a bone if you violated a syntax-correct type spec. It's an opt-in secondary tool and that diminishes its utility a tad.
Also the language is strongly typed and has a compiler which they’re adding more compile-time type checks to.
> Elixir has no types.
Elixir is strongly typed. I think you mean it is not statically typed.
Making this point in typed vs untyped debates about Elixir/Erlang specifically has never once lead to either an educational moment or a change of opinion on either side. You know exactly what they meant by that, and you're using a different definition than they are to try to pull a pedantic gotcha. It's snide and unproductive.
the lengths people will do to not read the manual.
As usual, AI is more reasonable than the humans utilizing it (see: Claude's comment on the blog post vs. human comments here on HN). Lol
beep boop
My conclusion from this is: ChatGPT is the new Google, so LLM hints is the new SEO.
My takeaway from these articles instead is that vibe coders and Copilot jockeys are just people in SWE that don't like the craft, so instead of doing the work themselves, are learning how to communicate the requirements effectively with a low-IQ code monkey.
They have turned themselves into micro-managers of an idiot savant.
Today they are low-IQ code monkeys. Yesterday they were low-IQ writers of grade-school essays. So what will they be tomorrow?
At minimum, still low-IQ code monkeys. Especially since AI research has come in fits and starts and stalls for many decades now.
But a weakly monotonic process rarely remains plateaued for very long, now does it? It only has one direction to respond to any changes in the environment after all. Tomorrow's models will either be the same or they will be smarter.
How much smarter do they need to get for that "low-" prefix to go away then?
Today they're low-IQ code monkeys.
Tomorrow, if you keep trying to make them smarter, they might decide to take over; who knows, maybe they'll let you live in a human zoo. I'll probably be the first one to be turned into biofuel.
> So what will they be tomorrow?
Gods that hopefully like us enough to keep us around.
Do people get into woodworking to use tools or do they get into woodworking to make furniture? We all have an approach to craft that is an ever-changing combination of self-fulfillment, practicality and external pressures.
To use the tools.
Otherwise they just go to Ikea.
There's a time for craft, and a time for other approaches. It all depends on the problem, I this is a bit of a false dichotomy.
ooh yes, I read something similar that resonated - LLMs are turning more devs into project managers, than project managers into devs.
Yep. Tfa mentions elixir being below the suggestions to rewrite a web app in rust and golang (??). The conclusion here should be that the LLM cannot be trusted that much, but we know that’s not going to happen, so anyone who wants to remain relevant must start playing games and damn the consequences.
Now instead of improving the language in other ways there will be distracting constant pressure to appease the machine. Now call this added “efficiency” with AI, similar to how adtech calls hiring your own director of marketing and paying tons of people who actually work for google with money from your own company coffers “5:1 ROI on advertising investment“.
If you're worried about people who literally have no opinion or preference about the tech stack they use taking your job... actually, I don't have anything witty to say beyond those people are not going to take your job.
Those people will go back to selling real estate or whatever it was they were doing before someone convinced them to take a nine week bootcamp.
> If LLMs turn out to be a fad and you’re reading this after they jump the shark, please accept this article as a historical artifact from a time when we entertained the idea that fancy autocomplete might eat the world.
> Aside, for those who don’t know what Elixir is: it’s the best general purpose language in the world and if you haven’t heard of it wake up and smell the bacon.
I find a certain humor in this, as elixir is more likely to be a fad than LLM's. I like and use elixir, but their lightweight processes are too restrictive for a lot of use cases. It's great for scaling web apps, however, and I think it's worth recommending over nodejs or other javascript based backends for a lot of people.
> I find a certain humor in this, as elixir is more likely to be a fad than LLM's. I like and use elixir, but their lightweight processes are too restrictive for a lot of use cases
I'm not an Elixir user, but you're criticizing Erlang/OTP, which has been around way too long to be considered a "fad".
I guess I mean "beam for everything" is a fad. It has a place, and is exceptional at some things, but it's relatively specialized
Elixir/Erlang is best for building long-running systems that you don't want to go down. Erlang's creators optimized for stability (phone systems) and sort of reinvented concurrency and distribution in support of that goal. There are some great talks by Joe Armstrong about this on YouTube, highly recommend!
For CPU-bound tasks and number crunching you can always just write it in Rust (or C or Zig) and NIF out to it from Elixir.
As a dev who builds apps that are served over the internet, it covers everything I need. Maybe that's a specialty niche.
> I guess I mean "beam for everything" is a fad.
There is no such fad. The vast majority of seasoned BEAMists will tell you that it is not for everything. There are enthusiasts bringing some surprising stuff to it which is great as it mostly falls into the category of "useful for things users are already outsourcing to other languages." But there is a whole host of things it will just never be able to do and no is pretending that it will.