> your definition of dead is elms definition of stability

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

You are not entirely wrong, but there’s still a difference between being dead and very stable. Among the languages that compile to JS, I would look at ClojureScript as the prime example of stability rather than Elm. I mean Elm has removed features breaking compat; ClojureScript doesn’t do that.

> your definition of dead is elms definition of stability, I think :D haha

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!

This, 200 times. No weekly news does not mean dead. In some specific places like this one, it means stable. (And also arguably, for good or bad reasons, why it will never become mainstream).

I've head the displeasure of working with more than one Elm zealot in the past, and also allowed a service to make it into production (which was a huge disaster). Due to that, I know a lot more about Elm than I'd like to.

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.

I recently learned about that too, how Lean provides ways to create new language syntax and DSLs, which is (on the surface) similar to Lisps like Racket. It's like operator overloading but way more flexible and general purpose. I'm wary of such language features, convenient for specific purposes (like working with vectors or matrices) but I'm afraid it's too powerful for normal usage, if everyone starts building their own DSLs and syntaxes, it would likely make the typical codebase difficult to read and understand. For example, the C++ template metaprogramming madness, it can be used responsibly but in my opinion it was detrimental to the language ecosystem.