[HN Gopher] LLMs and Elixir: Windfall or Deathblow?
___________________________________________________________________
LLMs and Elixir: Windfall or Deathblow?
Author : uxcolumbo
Score : 223 points
Date : 2025-06-04 23:00 UTC (1 days ago)
(HTM) web link (www.zachdaniel.dev)
(TXT) w3m dump (www.zachdaniel.dev)
| fernmyth wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ipnon wrote:
| 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.
| belter wrote:
| >> and because of the runtime, will practically never crash
| your system.
|
| "Practically never crash" ignores software bugs, resource
| exhaustion, or bad architecture
| borromakot wrote:
| Have you written/deployed Elixir before?
| belter wrote:
| 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
| borromakot wrote:
| 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".
| belter wrote:
| 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. :-)
| borromakot wrote:
| > 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.
| freedomben wrote:
| If perfection is your bar, you're going to be looking for
| a stack for a very long time.
| belter wrote:
| 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...
| skrebbel wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| bcrosby95 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| sodapopcan wrote:
| 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.
| jimbokun wrote:
| 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).
| carlmr wrote:
| >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 wrote:
| Lol exactly. "LLMs write good code if you make small changes
| and write tests!" Groundbreaking stuff
| tough wrote:
| 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 wrote:
| 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.
| jaza wrote:
| My conclusion from this is: ChatGPT is the new Google, so LLM
| hints is the new SEO.
| photonthug wrote:
| 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".
| sph wrote:
| 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.
| bubblyworld wrote:
| 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.
| HappMacDonald wrote:
| 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?
| sph wrote:
| 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.
| jimbokun wrote:
| > So what will they be tomorrow?
|
| Gods that hopefully like us enough to keep us around.
| panzagl wrote:
| 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.
| jimbokun wrote:
| To use the tools.
|
| Otherwise they just go to Ikea.
| bad_haircut72 wrote:
| 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
| mkesper wrote:
| 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.
| tobyhinloopen wrote:
| 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.
| te_chris wrote:
| 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.
| peteforde wrote:
| 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.
| badsectoracula wrote:
| > 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.
| rickcarlino wrote:
| 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.
| HappMacDonald wrote:
| 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?
| phinnaeus wrote:
| I am a huge Elixir fan and I would basically never reach for
| it to build a CLI.
| rickcarlino wrote:
| 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 wrote:
| 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.
| bryanrasmussen wrote:
| 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.
| pdimitar wrote:
| 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.
| bryanrasmussen wrote:
| 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.
| dnautics wrote:
| 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.
| borromakot wrote:
| It having strengths and weaknesses doesn't make it not general
| purpose language.
| drekipus wrote:
| In your mind, what distinguishes a language as "general" or
| "specific" purpose?
|
| I'd argue the community and focus of the language.
| rickcarlino wrote:
| 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 wrote:
| 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.
| Capricorn2481 wrote:
| I would honestly have a much easier time writing a web
| app in C than a game in Elixir.
| borromakot wrote:
| You are probably right
| gchamonlive wrote:
| 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 wrote:
| What are some examples of large scale production systems
| written in Elixir that do not use OTP?
| gchamonlive wrote:
| 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.
| rickcarlino wrote:
| 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.
| gchamonlive wrote:
| 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.
| lawik wrote:
| 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.
| westoque wrote:
| 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.
| borromakot wrote:
| https://github.com/burrito-elixir/burrito
| bcrosby95 wrote:
| 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.
| schultzer wrote:
| 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.
| CompoundEyes wrote:
| 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 wrote:
| 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.
| 2d8a875f-39a2-4 wrote:
| 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.
| roxolotl wrote:
| 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?
| the_duke wrote:
| 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 wrote:
| 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...
| aptj wrote:
| 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!
| jshprentz wrote:
| 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/
| duffyjp wrote:
| I wonder if the phoenix.new website was built with
| phoenix.new...
|
| This site can't be reached
|
| The connection was reset.
| itbeho wrote:
| It's hosted on fly.io... :)
| chrismccord wrote:
| 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!
| rhgraysonii wrote:
| 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.
| andruby wrote:
| 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.)
| pdimitar wrote:
| 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.
| rhgraysonii wrote:
| > 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.
| guywithahat wrote:
| > 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.
| Capricorn2481 wrote:
| > 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".
| guywithahat wrote:
| 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
| sodapopcan wrote:
| > 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.
| miki123211 wrote:
| 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.
| morkalork wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| APL is the densest language I have come across.
|
| There may not be enough code out there for LLMs to pick it
| up though.
| inerte wrote:
| 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 wrote:
| Moonbit lang is really interesting. Looks like it's been
| submitted but ignored by HN.
| insane_dreamer wrote:
| 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.
| mhanberg wrote:
| beep boop
| sergiotapia wrote:
| 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.
| tortilla wrote:
| 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.
| sergiotapia wrote:
| I just went back to rails 8 for this one. Vibe coding easily
| and it feels like an SPA out of the box.
| te_chris wrote:
| Same here. I've just setup vite, inertia and react with shadcn
| so we can vibe code our admin. Works incredibly well
| cdelsolar wrote:
| Why did you "scroll past" the Go solutions? Types, man, types.
| Elixir has no types. Ergo, I can't use it.
| dragonwriter wrote:
| > 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.
| te_chris wrote:
| Also the language is strongly typed and has a compiler which
| they're adding more compile-time type checks to.
| djaouen wrote:
| 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
| Dowwie wrote:
| 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.
| artem2471 wrote:
| 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.
| jtbayly wrote:
| 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.
| aczerepinski wrote:
| 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?
| 1oooqooq wrote:
| the lengths people will do to not read the manual.
___________________________________________________________________
(page generated 2025-06-05 23:01 UTC)