There's a lot to love about Elm, and I've written quite a bit of production code with it starting around 0.18.0. But in 2026 I'm not sure why a company would newly choose a language that hasn't otherwise been updated in nearly 7 years.
This. Generating a frontend with guarantees can almost not be done with any other language. If you use the graphql module with code generation it's an absolute game changer. Every time I have Claude generate a moderately complex frontend in react I regret it sooner or later due to state issues and inconsistent behaviour. Not with elm. Everything that makes it difficult makes it perfect for ai.
Haha we may have worked together. Equatable has been a theoretically huge, actually OK hole in my opinion because it _can_ lead to runtime crashes but never has in any code I've written (\_ -> () == \_ -> () is a runtime crash). So I'm glad to see something more robust than "just don't do that." And "hashable" as the real thing you need to implement Set/Dict is a good idea imo. I'm sympathetic to keeping "comparable" closed and even smaller than it is for the reasons in this discussion [0]. In my perfect world, String would not be comparable as-is because string comparison should be locale dependent. Right now string comparison just ends up using JS's < operator which compares as a list of code units. So I'd like to be able to have a Set of Strings or a Dict with String keys without having the footgun of being able to think that I've alphabetized a list when all I've done is annoy a user by putting Área after Zapato and not between Azul and Barcelona.
But I agree with you that the current solutions for Set/Dict all have one problem or another: You can use elm-sorter-experiment [1] but then you are writing a sort function and passing it around and maybe you don't want the overhead of that. You can switch to the Lamdera compiler and use containers [2] but then it's a different compiler and a you need to tweak your options slightly to compile an Elm project as an Elm project in it and it could get out of sync with the Elm compiler (extremely unlikely though). You can use any of the list/dict implementations that are really just lists with O(n) everything under the hood. So maybe this hashable type is going to make things better, idk.
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
I remember using Elm in one of my gigs. After I left, the client hated me. Not to forget all the drama that it had before Covid. I really want this language to succeed, but its bdfl is trying hard....
The author is very charitable in their description of the Elm Core teams actions in these interactions, but you read it and they come off entirely unaccountable and dismissive. If they want to make a purely functional language locked down, you really should be upfront that they don't have time to make sure basic parts of the web ecosystem are arbitrarily locked off like i18n until they decide users of their langauge are permitted to use it after ruling out any suggestion it doesn't undermine the purity they were going for.
Gonna be honest, really got the impression the maintainer here couldn't be stuffed looking to it, and wasn't personally impacted and largely didn't give a shit. Proceeds to run off some bullshit to dismiss the issue entirely about it being too risky (he had better things to do, and anyone he can delegate this too does too), the poster offers to do the work write a report, etc, etc. Then he's ghosted and for some reason the thread is shut after 10 days lol??? I guess giving him the dignity of a reply is out of the core teams hands because of how they arbitrarily configured their discourse.
Don't blame that dude for leaving Elm, glad I never made the mistake of wasting my time being dependent on its infantilizating runtime.
Look if you want to avoid being too coupled to the runtime your language exists in, sounds like a cool experiment, but maybe don't drag everyone along with you until you figure out the basic issues.
All that is 6 years ago hopefully they're more self aware.
I see all these people complaining about Elm limiting privileges to certain Github projects. A sensible complaint. But why hasn't anyone simply forked Elm, made the small tweak to make the check function return true or whatever, and offer that as a download/patch to the community?
I understand that defaults matter and that can have a large impact on the flow of libraries and code and stuff... my point is more, if you've got production code bases on this language, or at least, did 6 years ago, why so helpless? Nothing makes the point that an open source project can't dictate to its customers like the customers taking the "open source" part seriously.
I don't actually expect that to "work". What I expect to happen is that in the second-order effects that it would resolve this matter one way or the other once and for all. Either the core language realizes they need to accept the change, or the community works around the blocker, or the core language goes closed source and removes all doubt and people can move on, including their production services.
Did the restrictions on JavaScript get resolved? IIRC, they made it so you had to use their “Ports” mechanism to interface with JavaScript, and you couldn’t write your own wrappers.
There was some drama when someone forked it so you could write your own JavaScript wrappers/FFI too?
So many casualties in that period of groping around in functional programming concepts for the frontend from, like, 2014 - 2020 or so. But a lot of good things endured from that at least.
I hope to see progress in the future. I loved Elm and it made me a better programmer. Things changed a lot since then, but beauty of Elm is not matched by any language.
Also, if you ever had to refactor anything, there is no language in the world that makes it as easy to change things.
I'm interested less in getting to Elm 1.0 than getting past Elm 0.19, which is the version that locked out all native modules that weren't officially blessed by Elm's author. Far as I can tell, that pretty well marked the end of Elm.
We had some big Elm proponents who were trying hard to convince the company to use Elm, including doing proof of concept buildouts in Elm.
Then the 0.18 to 0.19 Elm drama happened: The core team restricted the ability for users to do any native JavaScript interop, which broke every Elm app that needed any functionality that wasn’t in the core library.
It split the Elm fans into two groups: Those who were upset that they had invested in a language that now pulled the rug out from under them, and those who were true believers who told us that they trusted the Elm team’s decisions and we all needed to chill out and wait for them to address our needs, which they thought would happen soon. That was 7 years ago. There were some attempts to spin the lack of updates as “Look how mature and stable it is!” but you don’t have to look very deep to see that they just stopped working on it.
Last time I went back to look at it there were several Elm forks, some maintained by former members of the Elm core team that were more active but never caught on. With the way the core team broke important functionality, ignored the user base, and then abandoned the project for years there is no way I would ever allow this near a production website. I know that will earn me some downvotes from the die-hard Elm fans, but I think it’s important context for anyone who finds themself in a situation where Elm is being proposed for an internal project. It was always interesting as an experimental niche framework, but not as something I’d ever want near a product that I had to maintain. Especially not something that had to survive across developer turnover when your company’s main Elm proponent left and the language was abandoned for years.
> It split the Elm fans into two groups: Those who were upset that they had invested in a language that now pulled the rug out from under them, and those who were true believers who told us that they trusted the Elm team’s decisions and we all needed to chill out and wait for them to address our needs, which they thought would happen soon.
It's going to be hard to explain to future generations that the demand for computer-speakers was once such that sometimes they could even decide the language in which they spoke to the computer, and that really was a big deal back then because computers couldn't just switch back and forth like they can today.
We didn't tolerate it for main production projects.
But you're missing the vibe at the time: You would get downvoted and argued with if you tried to say that it was one person's hobby language. It was supposed to be a big movement and the next big thing in FE development. People would argue that it was production ready.
You can even see a lot of those comments in this thread.
I think of Elm more as an incredibly influential research language these days.
It's very focused, there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building or core team building.
But MAN is it nice to work in. This has resulted in several forks/spin-offs. At the recent Gleam conference, Louis Pilfold joked that every Elm user maintains their own compiler :). There are at least 6 of them (two more got announced in the last month, even as the community keeps shrinking).
So I'm glad Evan is now working towards 1.0. Maybe folks can call Elm "finished" and one of the successors can do the hard work of unifying some of the forks and growing the community.
Personally, the next time I'm looking for an Elm-like thing, I'm going to check out Gleam + Lustre. Seems to have a nice mix of maintainers that care about community and design. And it works on frontend + backend!
If you'd like an incomplete list of everything that's downstream from Elm, I made one the last time a TEA library got to the front page here: https://news.ycombinator.com/item?id=47678424 The creator of Derw shows up one comment later to remind me of one that I was forgetting.
The nicest thing of Elm is how much it feels like Haskell. Have built some fun things with Elm years ago.
The second nicest thing with Elm is the philosophy of if it compiles it works. And to be honest you can get that same feeling with most of Rust as well. Sadly not as much of a haskell feeling but at least it has a warm shadow of some of its functional ancestors.
These days, though, why not just use Haskell itself? Upstream ghc cancompile to wasm for several major releases now and there are several actively developed web frameworks, some of them very Elm-inspired, e.g. https://haskell-miso.org
I'm one of those. I extended the language to support a bunch of niceties (essentially supporting a proper error channel and dependency injection through erasable sum types).
Elm is a nice language, but Ewan has no interest in building anything truly useful and the whole administration of the language is s disaster.
I agree and I think the ideas in Elm are applicable in many other contexts. Adopting a new language is just hard, especially with larger teams. I ended up taking some of the ideas of Elm but implementing with Rust and TS - https://dave.tonge.org/articles/make-ts-boring/
The basic idea - all application state and view model creation is in Rust (compiled to Wasm). I'm using Rust not really for performance, but for its strong type system. Components are in TS but have a strict contract they can only accept plain input props and output events. Rust processes the events and ships a view model patch to TS.
This is not "Elm in Rust/TS" but it is definitely Elm inspired.
We're now migrating to React, but have some very large Elm projects still in prod.
The biggest thing for me from practical perspective was to "freeze" some pieces of DOM to be guaranteed to not change/re-created, so that it plays well with some external JS libraries expecting some nodes to not change and stay vanilla.
Another is ability to extend Elm's debugger to filter out big noisy data to keep it usable for our project.
Third is when your data is too big -- it just sometimes fails with "recursion limit" that's hard to debug due to the nature of the langauge.
Otherwise – it's a very beautiful little language that still feels quite modern and easy to work with IMO.
Back in my undergrad, I took a Functional Programming class taught in Elm. It was primarily about functional data structures, but we also got to build a web app using Elm towards the end.
At the time, I didn't think much of it -- I was probably busy learning React and JavaScript and yada yada for employment purposes.
Now, having spent some time in industry and having used some gargantuan web frameworks, I find myself missing Elm. MVC in Elm is wonderfully straight-forward and easy to reason about.
Congrats on the road to 1.0! Glad to see Elm still active all these years later.
77 comments
[ 5.2 ms ] story [ 40.6 ms ] threadit taught me a lot of things - such as simplicity. when I ended up switching to react - redux was easy to pick up cz of elm.
sadly the ecosystem never grew. but oh man elm is nice & the apps were performant.
https://taylor.town/elm-2023
It's 2026, and I'm still using Elm for all the same reasons :)
As an added bonus, Claude seems to play very very nicely with Elm:
https://taylor.town/diggit-000
I love Elm, and I love the community, but I feel a little gaslit here.
I have worked at a few elm places, there is always a dict-for-everything dependency or local implementation.
But I agree with you that the current solutions for Set/Dict all have one problem or another: You can use elm-sorter-experiment [1] but then you are writing a sort function and passing it around and maybe you don't want the overhead of that. You can switch to the Lamdera compiler and use containers [2] but then it's a different compiler and a you need to tweak your options slightly to compile an Elm project as an Elm project in it and it could get out of sync with the Elm compiler (extremely unlikely though). You can use any of the list/dict implementations that are really just lists with O(n) everything under the hood. So maybe this hashable type is going to make things better, idk.
[0] https://github.com/elm/compiler/issues/774#issuecomment-3472...
[1] https://github.com/rtfeldman/elm-sorter-experiment
[2] https://github.com/lamdera/containers/tree/main
But then you see stuff like this https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
The author is very charitable in their description of the Elm Core teams actions in these interactions, but you read it and they come off entirely unaccountable and dismissive. If they want to make a purely functional language locked down, you really should be upfront that they don't have time to make sure basic parts of the web ecosystem are arbitrarily locked off like i18n until they decide users of their langauge are permitted to use it after ruling out any suggestion it doesn't undermine the purity they were going for.
https://discourse.elm-lang.org/t/bindings-for-intl/1264
Gonna be honest, really got the impression the maintainer here couldn't be stuffed looking to it, and wasn't personally impacted and largely didn't give a shit. Proceeds to run off some bullshit to dismiss the issue entirely about it being too risky (he had better things to do, and anyone he can delegate this too does too), the poster offers to do the work write a report, etc, etc. Then he's ghosted and for some reason the thread is shut after 10 days lol??? I guess giving him the dignity of a reply is out of the core teams hands because of how they arbitrarily configured their discourse.
Don't blame that dude for leaving Elm, glad I never made the mistake of wasting my time being dependent on its infantilizating runtime.
Look if you want to avoid being too coupled to the runtime your language exists in, sounds like a cool experiment, but maybe don't drag everyone along with you until you figure out the basic issues.
All that is 6 years ago hopefully they're more self aware.
I understand that defaults matter and that can have a large impact on the flow of libraries and code and stuff... my point is more, if you've got production code bases on this language, or at least, did 6 years ago, why so helpless? Nothing makes the point that an open source project can't dictate to its customers like the customers taking the "open source" part seriously.
I don't actually expect that to "work". What I expect to happen is that in the second-order effects that it would resolve this matter one way or the other once and for all. Either the core language realizes they need to accept the change, or the community works around the blocker, or the core language goes closed source and removes all doubt and people can move on, including their production services.
There was some drama when someone forked it so you could write your own JavaScript wrappers/FFI too?
Also, if you ever had to refactor anything, there is no language in the world that makes it as easy to change things.
Hope to see more releases in the future.
Though with the advent of LLMs it became very easy to spin up alternate backends for it, so it's very much alive outside of JS as well.
Then the 0.18 to 0.19 Elm drama happened: The core team restricted the ability for users to do any native JavaScript interop, which broke every Elm app that needed any functionality that wasn’t in the core library.
It split the Elm fans into two groups: Those who were upset that they had invested in a language that now pulled the rug out from under them, and those who were true believers who told us that they trusted the Elm team’s decisions and we all needed to chill out and wait for them to address our needs, which they thought would happen soon. That was 7 years ago. There were some attempts to spin the lack of updates as “Look how mature and stable it is!” but you don’t have to look very deep to see that they just stopped working on it.
Last time I went back to look at it there were several Elm forks, some maintained by former members of the Elm core team that were more active but never caught on. With the way the core team broke important functionality, ignored the user base, and then abandoned the project for years there is no way I would ever allow this near a production website. I know that will earn me some downvotes from the die-hard Elm fans, but I think it’s important context for anyone who finds themself in a situation where Elm is being proposed for an internal project. It was always interesting as an experimental niche framework, but not as something I’d ever want near a product that I had to maintain. Especially not something that had to survive across developer turnover when your company’s main Elm proponent left and the language was abandoned for years.
It sounds like evaporative cooling.
https://lesswrong.com/posts/ZQG9cwKbct2LtmL3p/evaporative-co...
But you're missing the vibe at the time: You would get downvoted and argued with if you tried to say that it was one person's hobby language. It was supposed to be a big movement and the next big thing in FE development. People would argue that it was production ready.
You can even see a lot of those comments in this thread.
It's very focused, there's no public roadmap or official support and the leadership (which is far as I can tell is just Evan) is uninterested in most (any?) community building or core team building.
But MAN is it nice to work in. This has resulted in several forks/spin-offs. At the recent Gleam conference, Louis Pilfold joked that every Elm user maintains their own compiler :). There are at least 6 of them (two more got announced in the last month, even as the community keeps shrinking).
So I'm glad Evan is now working towards 1.0. Maybe folks can call Elm "finished" and one of the successors can do the hard work of unifying some of the forks and growing the community.
Personally, the next time I'm looking for an Elm-like thing, I'm going to check out Gleam + Lustre. Seems to have a nice mix of maintainers that care about community and design. And it works on frontend + backend!
The second nicest thing with Elm is the philosophy of if it compiles it works. And to be honest you can get that same feeling with most of Rust as well. Sadly not as much of a haskell feeling but at least it has a warm shadow of some of its functional ancestors.
Elm is a nice language, but Ewan has no interest in building anything truly useful and the whole administration of the language is s disaster.
The basic idea - all application state and view model creation is in Rust (compiled to Wasm). I'm using Rust not really for performance, but for its strong type system. Components are in TS but have a strict contract they can only accept plain input props and output events. Rust processes the events and ships a view model patch to TS.
This is not "Elm in Rust/TS" but it is definitely Elm inspired.
The biggest thing for me from practical perspective was to "freeze" some pieces of DOM to be guaranteed to not change/re-created, so that it plays well with some external JS libraries expecting some nodes to not change and stay vanilla.
Another is ability to extend Elm's debugger to filter out big noisy data to keep it usable for our project.
Third is when your data is too big -- it just sometimes fails with "recursion limit" that's hard to debug due to the nature of the langauge.
Otherwise – it's a very beautiful little language that still feels quite modern and easy to work with IMO.
At the time, I didn't think much of it -- I was probably busy learning React and JavaScript and yada yada for employment purposes.
Now, having spent some time in industry and having used some gargantuan web frameworks, I find myself missing Elm. MVC in Elm is wonderfully straight-forward and easy to reason about.
Congrats on the road to 1.0! Glad to see Elm still active all these years later.