Hacker News Reader

Comment by auslegung | Hacker News Reader

About two years ago I was experimenting with ChatGPT vibecoding a snake game in the browser in elm, because elm is my favorite language. It was rough going and I concluded at the time that LLM‘s might kill elm. Today I use elm in production and LLMs are vastly better at it, and if anything I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now. It’s a simpler language than most, it’s stable, it has an opinionated architecture built into the language which causes most code bases to be very similar to one another

View on HN

On that note, because of AI I've been more into music, bought a midi keyboard, got real DAW software setup. I've also finally built more and more with Rust, and have been reading more Rust docs. LLMs should never be an excuse not to learn the things you're using it for, those are the bad engineers. An LLM affords me the time to research and learn what it gave me so I can maintain it. It's easier to prompt about the problem if you understand it.

If you have a blog or something anywhere, I'm very interested in your journey.

I do though I havent been blogging as much, its a blessing and a curse to have a SSG based blog. I would love to have an SSG engine that I can use remotely from anywhere, currently using Publii.

https://giancarlostoro.com

This is very similar to my recent experience!

LLMs are surprisingly effective at helping you learn the "vibes" of making music and understanding various concepts.

> I think LLM‘s might increase elm adoption because it is the ideal language for an LLM right now

Yes but no? It really just depends on the amount of elm in the training data and rlhf. I agree that structured frameworks/languages have codebases more similar to one another and that would ease generation. But that alone won't work and usually dev adoption is a total discourse per se

That's not why Elm is an ideal language for LLMs: it's because, if it compiles, it's most likely working software. Agentic workflows have gotten significantly better over the last year, so LLMs using languages like Elm, Haskell, or even Rust have an amazing feedback loop where even lower quality models can keep trying until things compile.

can keep failing til you're tired of having the agent running in loops, as I said it doesn't matter, agent tools are more effective with models trained with a lot of elm examples

Yet Elm due to its simplicity does not need a lot of examples. Language itself is small and blessed way to architecture things consist of few patterns. Then things are composable. This is ideal for LLMs.

The price for that is verbosity. What in other languages are hidden behind async and complicated libraries in Elm has to be done explicitly resulting in boilerplate. But that is never a problem for LLMs.

Then Elm compiler has one of the best error messages. This helps agents a lot.

Then Time Machine debugger is another big help for agents as they have access to the full execution trace of the program. The trace is much smaller than would be necessary for other languages and typically fits into content window.

> Yet Elm due to its simplicity does not need a lot of examples

But does the neural net ;)

Maybe it's improved, but I was very disappointed to find agents constantly tripping over significant white space with Elm (Claude Code). Always struck me as strange since they are very proficient with python... and Elm has been one of the most stable modern languages (so stable that people complain about it never changing!). I think the last time I tried was a year ago though, so I assume it has improved.

I started working with Elm in production again about a year ago and have bounced back and forth between codex and Claude code and haven’t noticed whitespace problems, so I would conclude it’s better but of course your mileage may vary

I was already working with elm (have been since Signals) and I was very disappointed in what agents (CC) produced. In contrast, I was pleased with the Rust code they produced.

LLMs are way past that, Claude Code can very competently write Elm code now, for example.

Good to know. I built https://github.com/pairshaped/hypertea to get some of Elm's safety in typescript while being easy for LLMs to use (this is basically just hyperapp in TS, with added elm-like guardrails). Maybe I'll go back to Elm now that LLMs are handling it better.

> I think the last time I tried was a year ago though, so I assume it has improved.

I noticed that coding agents seemed to get pretty good around 2025 Oct/Nov.

If it's improved? My experience with Nickel-lang (probably as not-in-training-data as Elm) is coding agents have improved with this compared to last time I tried.

I don't think anyone complained about the language changing, it was a lack of trust in the language due to the compiler not getting any updates. You can still improve the compiler without having to change the language.

Yes. But that is about to change, and the compiler is now getting the updates it needs.

Mostly the compiler was fine, we could do with some bug fixes in core packages - not many, but there are a small number of long time bugs that should really be sorted.

Fair point. I hadn't thought about it that way, but I would still hesitate if the ecosystem isn't moving forward.

Reply on news.ycombinator.com