Elixir's Standing in the Age of LLMs: Optimism and Concerns
Several commenters expressed excitement about advancements in LLMs' ability to generate Elixir code, viewing it as crucial for the language's future competitiveness. "Ah man I'm really happy to see this and excited to try it out," says arrowsmith, continuing "As an Elixir enthusiast I've been worried that Elixir would fall behind because the LLMs don't write it as well as they write bigger languages like Python/JS. So I'm really glad to see such active effort to rectify this problem. We're in safe hands." This sentiment is also reflected in zorrolisto's comment, referencing Theo's video and expressing hope that LLMs will be able to infer Elixir code effectively.
The Nature of Functional Languages and LLM Code Generation
The difficulty LLMs may have generating Elixir or other functional language code was discussed, leading to speculation regarding the underlying cause. throwawaymaths posits that "in principle llms should do better on immutable languages since there is no risk a term will get modified by a distant function call." However, bevr1337 counters that "In my experience, it's the functional part, not immutability, where they fall short. Any LLM can write immutable C# because it's easy and there's incredible amounts of training data." throwawaymaths then argues that Elixir's functional nature is limited to immutability and first-class lambdas.
The Potential for Data Poisoning of LLMs
A more contrarian perspective centered on the possibility of "poisoning" LLMs by feeding them plausible but incorrect code snippets, especially given the widespread use of web crawlers for gathering training data. dingnuts asks "since models can't reason, as you just pointed out, and need examples to do anything, and the LLM companies are abusing everyone's websites with crawlers, why aren't we generating plausible looking but non working code for the crawlers to gobble, in order to poison them?" They express frustration with the data gathering practices of LLM companies and suggest that "hordes of vibe coders are actively doing what I just suggested -- unknowingly." fragmede raises the point that models could potentially detect such poisoned data by "run[ning] the code, not get[ting] the expected output, and then exclud[ing] the bad code from their training data?".
Concerns About the Elixir Ecosystem: Package Maintenance and Growth
Several comments focused on the perceived shortcomings of the Elixir ecosystem, particularly concerning the maintenance of packages and the relative lack of comprehensive client libraries, especially when comparing it to more established languages. mrcwinn claims the Elixir ecosystem "is a wasteland of abandoned packages" and expresses disappointment that Elixir lacks alternatives to tools like Mastra in TypeScript or PydanticAI in Python. They elaborate stating "The fundamental question for any developer: can I be productive quickly? Despite all that Elixir has going for it, the answer is often 'no.'" and "Want a first-party client library for the service you're using? Typically the answer is 'too bad, Elixir developer.'". These concerns are echoed by AlchemistCamp, who cites the popular Stripe wrapper's outdated API version as an example, stating "None of this is a fault of anyone working on Elixir or Phoenix but it definitely has an effect of discouraging some of the fledgling entrepreneur types who Elixir would otherwise be a near perfect fit for, as Rails was in the late aughts."
Rebuttals Against Perceived Lack of Maintenance and Ecosystem Concerns
Counterarguments were presented, asserting that many "unmaintained" Elixir packages continue to function effectively due to the language's stability. uncircle states that "All languages are a wasteland of abandoned packages... It’s all relative to the mindshare. For its size, Elixir is doing quite well." and erichocean makes the analogy that "Some languages—Clojure is a good example—have packages from 10 years ago, entirely unmaintained, that still work great because no maintenance is needed." mervz questions the assumption that frequent updates are inherently better, stating "It sucks people have been tricked into thinking a library must be updated every 2 weeks in order to still be relevant... You think just because an author bumps the version number of a library it's somehow better than a library that is considered complete?".
Elixir's Attractiveness and Challenges from a Business Perspective
The discussion also touched on the challenges Elixir faces in attracting wider adoption, particularly from a business and engineering management perspective. matt_s argues that while Elixir is enjoyable for developers and encourages innovative solutions, it presents difficulties for engineering leaders: "LLMs not writing it well, developers that know it typically needing higher compensation, a DIY approach to libraries when there aren't any or they were abandoned and haven't kept pace with deprecations/changes, etc."
Positive Experiences with LLMs and Elixir
Despite the general concern of LLMs struggling with Elixir, several participants reported positive results. bad_haircut72 claims that "Claude crushes elixir especially a fullstack app in liveview" and heeton adds, "Yea CC is great with phoenix / liveview. It’s been doing things that teach me new tricks about elixir I didn’t know yet." Another user, te_chris, says that "Claude and o3 are both excellent (if a bit erratic) elixir developers."