So it was dead, it just now has been resurrected (and AFAIK with a whithered community in the meantime).
javascriptland really warps peoples minds on stability and project-liveness
If Elm's definition of stability is keeping bugs and runtime errors for years, then I'm glad I stopped using Elm long ago.
Not only were the issues unaddressed, but for the past years the PR got no human response. For instance this one¹ fixes infinite loops in the core. [¹]: https://github.com/elm/core/pull/1137
To be fair, Elm hasn't made it to 1.0 (yet). That's where languages should make breaking changes before being stuck with the flaws forever.
The Elm community (or those who remained anyway) has a very cult-like way of spinning the current status quo as being good for you, even if it’s not.
Removing native JavaScript interop in 0.19? They’re just making it more pure! Sorry your project had to become impossible to continue on Elm, but this is the price we pay for a leader with vision.
No appreciable updates or bug fixes for 7 years? That’s just stability! Look how stable and mature it is that it can go 7 years without a release!
If not, the expectations you and many have here seem pretty unreasonable. There's room for projects like Elm. Not every PL has to meet the demands of every single non paying user of the community.
Even if there had just been incremental bug fixes, I suspect between some and most people would have gotten over it, but seven years of silence is a very long time- long enough for an entire generation of new developers to start calling themselves seniors knowing only that Elm has stalled and shouldn't be used, because the controlling developers are unreliable and prone to giving the appearance of abandoning the language.
I think the "Elm is stable not dead" seen from the few people that stuck around with Elm is largely cope for being stuck with an unmaintained language. Languages, like all other pieces of software need maintenance or they degrade in the world moving around it (e.g. there is/was no official aarch64 build of Elm in the period of non-maintenance).
I also would say that Elm is still largely unfit for most realistic production scenarios, unless you have the manpower to build everything from scratch, as interoperability with the outside web world (JS/TS) is an afterthough, and by some parts of the community not desired.
In my eyes, it was probably the right decision technically, but deeply unpopular and probably the wrong decision socially.
Elm served its purpose for me - an example of a small language with great tooling and error messages. And the strictness was helpful in learning to do things the "proper" way in the Elm model, even if I did reach for escape hatches in later projects. E.g. writing a notion-like application in Elm, I had to walk through my data twice - once to render it and another time to collect cache misses. With hyperapp, I broke purity a little and accumulated the information on the side.
I never used elm except for doing a tutorial, but lately I've built a full stack gleam app (using coding agents for the most part, with a lot of control in the beginning on the structure of the code) and have found that process works quite well
However, I feel people often miss the real value of a good DSL: it's not about the syntax, but about providing hardened semantics that can bolster or guarantee desired qualities. Elm, for instance, provides value insofar as it makes producing runtime exceptions significantly more difficult.
Personally, I hope languages like Lean, which provides exceptional support for creating DSLs within the language, renew interest in semantically sound DSLs, especially if we insist on using LLMs.
It’s a whole different set of values. Good React code in 2026 looks like any compiling Elm code since 2016.
I get that some people like stability, but that is quite different from going without updates for 6+ years.
Today's Elm toolchain is the Elm toolchain of 6 years ago!