IMO it's safe to say that Elm is dead and won't come back with this attitude of the core team (which is not the only problem of the language). We never switched to Elm 0.19 from 0.18 but moved on to rewrite in Svelte 5 with TypeScript and never looked back.
I saw these threads pop up here and there over the years, always funny to read comments (even in this very thread!) about how (paraphrasing) "good ideas take time" and "the creator shouldn't add everything people are asking for into the language," meanwhile the last release is still 0.19 in 2018 and I honestly don't know what Evan and the core team have been doing with regards to Elm since then.
There's a vast gulf between being prudent with feature additions, and doing effectively nothing at all. Of course a language that preaches the former but materializes the latter would die sooner or later, as people get fed up with the lack of updates. And in the meantime, TypeScript just gets better and better.
Like even no updates since 2018 might be ok if Evan et all communicated more about the goals and direction of the project
Evan especially wrote and spoke a lot about his philosophy re: the project which I think can be fairly summarized as “everyone just sit down and shut up.” But that’s not a lot to go on when trying to evaluate if a project has staying power, mature governance, and so on.
I remember reading this article when it was published, it seems like everything said continues to be true about Elm, so much that I don't hear about anyone using Elm these days, as even those who have used it as legacy code have now largely had enough time to migrate away.
I don't really follow Elm, but I was curious and tried to see whether the project is still alive. It appears the last commits on GitHub are from mid 2024 and the last installable release was 2019. It appears the main developer is working on a new thing?
There's definitely a "the bear is sticky with honey" confusion of discussion over whether it's dead or not. It would be nice for interested strangers like me if they could make some sort of clear statement on it.
> It appears the main developer is working on a new thing?
One of the problems is that the developer said several times, even in a recent interview, that he was still working on elm, with a focus on the long term. He gave a few vague hints about his private roadmap. After 4 years without any real public activity, I find it hard to believe there's some private activity.
Assuming that you're talking about Richard Feldman, he shows up regularly but not to talk about Elm—Roc is his new project, which is inspired by Elm but not trying to target the same niche.
The author is critical primarily of Elm's governance and processes, and claims that these are what killed the project. I don't think that's entirely true. There was a recent interview with the creator of Elm here.
I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting out as much as he was putting in. That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.
Elm's governance and process are what made it such a delight to use. Instead of allowing the full spectrum of bad ideas in frontend development to slowly make their way into the language, the authors carefully curated a coherent set of good ideas. They said no to a lot of things, and cut out as often as put in. This is going to piss off a lot of people because it means saying no to a lot of people. Saying yes to those people would make the language worse; you can't have it both ways.
> I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting out as much as he was putting in.
That's two different topics. The work situation Evan had with NRI is completely unrelated to what he and the core team decided to shape the community into, which is the subject of TFA's criticism.
> That's his decision to make and he doesn't owe anyone anything.
In the world of emergent programming languages, the language author isn't the only one taking risks. Early adopters do have skin in the game, and their work spent growing the ecosystem is valuable. Sure, I get that Evan doesn't owe work to anyone. However, he also made sure that everyone in the community had to rely on him, and that's the issue.
In retrospect, Luke Plant correctly identified the risks Elm's community management style created, and eventually these risks came to materialize.
For these reasons, I can't advise people to touch anything Evan does in the future.
> Elm's governance and process are what made it such a delight to use.
I guess you haven't been personally contacted by a member of the core team trying to steer you into changing course on a technical topic. That interaction was not delightful.
> For these reasons, I can't advise people to touch anything Evan does in the future.
> I guess you haven't been personally contacted by a member of the core team trying to steer you into changing course on a technical topic. That interaction was not delightful.
I agree, the community itself has a sort of toxic positivity to it, where criticisms are verboten and one must act like everything is good.
>>>> That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.
Completely correct, and the users of Elm also don't owe him anything. They are free to hold their opinions and free to move away from Elm ...and they did.
In the end Elm will be remembered for being an extremely interesting technology but mainly failed in industry due to poor project/community relationship.
Sometimes interesting tech just isn't the right fit for business. C'est la vie.
Your defense of the Elm leadership team is far more vague than the article criticizing it. He is very specific about limitations of the platform and the behavior of the leaders. You, on the other hand, are very hand-wavey in their defense "sometimes you just have to say no and piss people off". Do you believe these decisions were good ones? Do you believe they were done the right way?
This is a frustrating comment because it doesn't engage with anything the article is saying and just tries to counter it with the truism that "he doesn't owe anyone anything", something which the author specifically addressed at the beginning of his post.
Guess what, if the project leader doesn't owe anyone anything, then the author of TFA also doesn't owe him anything.
They threw people out of the community if they even created forks of the language, and they literally hard coded in their buddies' projects to use compiler features that everyone else couldn't. "Rules for thee but not for me" does not inspire much confidence in using a new niche language, much less using it in production.
If the features were actually cut, then that would be a separate discussion point. However, that was not the case, the author directly says that the features are still there but restricted to blessed set of users. So, author considers elm to be crippleware
Still the best web language and framework ever introduced. Its influence is everywhere. Unfortunately no one implements all of it so they can never live up to the standard it set.
I would recommend everyone avoid reading this article. It didn't accomplish anything. In the five years since writing nothing has changed and no alternative replaced it. Elm is not used because the JavaScript community chose something else not because of anything mentioned in this article.
The core of the complaint is a lack of native modules. Fork the compiler and remove the few lines preventing it. Vendor your native dependencies and the jobs done. You can ignore whatever snide remarks you receive (assuming there's anyone in the world who still cares about this).
If you've never used Elm I highly recommend taking this chance to learn it.
Per TFA, you don't just get "snide remarks" if you fork the compiler. You get booted from all the official community spaces.
Given that those are the first place someone would go to seek help if and when they need one, especially for a community that small, that feels like a considerable risk.
> Elm is not used because the JavaScript community chose something else not because of anything mentioned in this article.
Actually a big reason why the JS community chose something else has a lot to do with what is mentioned in the article. Typescript has a much different governance.
I would recommend people learn the assembly language for the computer they own and then a high level language like c or shell. Far too many developers these days don't know anything about computers.
Going into your kitchen and making some food with the ingredients you have will always be, to use a buzzword, more sustainable than ignoring the state of the kitchen and saying make me an omelette, or worse calling up uber eats which isn't even sustainable if you pay.
What a strange non sequitur, for what reasons do you believe learning assembly is worthwhile and how does it relate to this discussion about Elm? Also the food analogy does not make sense to me.
Tangentially, does anyone know how to actually get anything done with rescript?
I feel like I would love it. It seems pretty darn awesome.
But getting started on a MacBook Air 2018 seems like an exercise in defeat. Building the toolchain takes ages, I have tried twice just getting started and never got to compiling any examples.
I have used rescript quite a lot but never really ran into problems like that with the tooling. The tooling is pretty twiddly so I'm not surprised. But for me more in how it integrates with "normal" frontend tools. It's easy to wire it up in a way where the compiler doesn't always get all of your most recent changes, or the compiled artifacts aren't picked up by the js bundler correctly.
Anyway I have since switched to gleam, mostly for project governance and tooling reasons! The particular way rescript ended up eventually emerging from the reason/bucklescript schism I think just had it shed a lot of interest and goodwill. The core of the language is so so strong (because of ocaml) but they seem almost embarrassed by the ocaml connection and seem to be trying to distance themselves from it. They've implemented a new standard library that reproduces mutable JS semantics and I just think that's a big step back too.
Gleam is a HN darling that comes up all the time but it's in a really great spot for being such a young language. Very very similar semantics to rescript if you're targeting JS, rock solid standard lib, tooling is very good, package ecosystem surprisingly robust and high quality. It's not always obvious if a library supports js targets or erlang or both, and I hope they address that soon. I think they have a much clearer idea of what they want to accomplish than rescript does so I switched. IDK check it out, I originally ended up in rescript looking for an elm replacement and now I've ended up here.
I want to use rescript but the unit testing story seems non-existent, there's some vague mentions of using Jest which is just an awful choice. If there's a way pf using Vitest with it, or something at all, that would be good.
Since Elm compiles to JavaScript, all the new development features from JavaScript, HTML, and CSS are also instantly available in Elm. I.e. it's not necessary to change Elm all the time to keep it up to date with the web platform. For non-stop Elm content check out all the communities at https://elm-lang.org/community
It may not be dead, but it does seem a bit stagnant. Based on Google Trends at least (https://trends.google.com/trends/explore?date=today%205-y&ge...), Elm has the same general interest level as it did five years ago (despite going up a bit in-between).
I loved Elm, and it's disappointing it never achieved critical mass. We wrote a few front-ends with it about 6 years ago. Very easy to write, debug, and deploy
Me too. It’s one of the big “could’ve been” in my opinion.
Though I’m convinced it didn’t reach critical mass purely because of community management issues mentioned in the post. Too many people just threw their hands in the air and divested from Elm because of it. Not everybody wrote a blog post about it.
While those community management issues probably didn't help, I don't think Elm's failure to break out can be placed purely on their shoulders.
The big reason why it - and all the other typed/functional compile to JS languages (PureScript, Reason, etc.) - remained niche is because TypeScript came along. It integrated with the ecosystem more seamlessly, was instantly comfortable for JS devs, and was backed by MS who gave it first-class support in VSCode. Arguably TypeScript is not as good as those other languages, but none of them are better enough to overcome those network effects.
Readit News
IMO it's safe to say that Elm is dead and won't come back with this attitude of the core team (which is not the only problem of the language). We never switched to Elm 0.19 from 0.18 but moved on to rewrite in Svelte 5 with TypeScript and never looked back.
There's a vast gulf between being prudent with feature additions, and doing effectively nothing at all. Of course a language that preaches the former but materializes the latter would die sooner or later, as people get fed up with the lack of updates. And in the meantime, TypeScript just gets better and better.
Evan especially wrote and spoke a lot about his philosophy re: the project which I think can be fairly summarized as “everyone just sit down and shut up.” But that’s not a lot to go on when trying to evaluate if a project has staying power, mature governance, and so on.
There's definitely a "the bear is sticky with honey" confusion of discussion over whether it's dead or not. It would be nice for interested strangers like me if they could make some sort of clear statement on it.
That's not what I see.
The last commits for elm/compiler were minor fixes in 2023. Last substantial changes were in 2021. See https://github.com/elm/compiler/commits/master/
The last commits for elm/core were in the first months of 2021. See https://github.com/elm/core/commits/master/
> It appears the main developer is working on a new thing?
One of the problems is that the developer said several times, even in a recent interview, that he was still working on elm, with a focus on the long term. He gave a few vague hints about his private roadmap. After 4 years without any real public activity, I find it hard to believe there's some private activity.
https://news.ycombinator.com/item?id=42935516
https://www.youtube.com/watch?v=0SUM4869ODc
I'd encourage everyone to watch that as a grain of salt to TFA. It seems like the project leader felt he was being taken advantage of, and was just not getting out as much as he was putting in. That's his decision to make and he doesn't owe anyone anything. If you want continued support, pay up.
Elm's governance and process are what made it such a delight to use. Instead of allowing the full spectrum of bad ideas in frontend development to slowly make their way into the language, the authors carefully curated a coherent set of good ideas. They said no to a lot of things, and cut out as often as put in. This is going to piss off a lot of people because it means saying no to a lot of people. Saying yes to those people would make the language worse; you can't have it both ways.
That's two different topics. The work situation Evan had with NRI is completely unrelated to what he and the core team decided to shape the community into, which is the subject of TFA's criticism.
> That's his decision to make and he doesn't owe anyone anything.
In the world of emergent programming languages, the language author isn't the only one taking risks. Early adopters do have skin in the game, and their work spent growing the ecosystem is valuable. Sure, I get that Evan doesn't owe work to anyone. However, he also made sure that everyone in the community had to rely on him, and that's the issue.
In retrospect, Luke Plant correctly identified the risks Elm's community management style created, and eventually these risks came to materialize.
For these reasons, I can't advise people to touch anything Evan does in the future.
> Elm's governance and process are what made it such a delight to use.
I guess you haven't been personally contacted by a member of the core team trying to steer you into changing course on a technical topic. That interaction was not delightful.
> I guess you haven't been personally contacted by a member of the core team trying to steer you into changing course on a technical topic. That interaction was not delightful.
I agree, the community itself has a sort of toxic positivity to it, where criticisms are verboten and one must act like everything is good.
Completely correct, and the users of Elm also don't owe him anything. They are free to hold their opinions and free to move away from Elm ...and they did.
In the end Elm will be remembered for being an extremely interesting technology but mainly failed in industry due to poor project/community relationship.
Sometimes interesting tech just isn't the right fit for business. C'est la vie.
Guess what, if the project leader doesn't owe anyone anything, then the author of TFA also doesn't owe him anything.
I would recommend everyone avoid reading this article. It didn't accomplish anything. In the five years since writing nothing has changed and no alternative replaced it. Elm is not used because the JavaScript community chose something else not because of anything mentioned in this article.
The core of the complaint is a lack of native modules. Fork the compiler and remove the few lines preventing it. Vendor your native dependencies and the jobs done. You can ignore whatever snide remarks you receive (assuming there's anyone in the world who still cares about this).
If you've never used Elm I highly recommend taking this chance to learn it.
Given that those are the first place someone would go to seek help if and when they need one, especially for a community that small, that feels like a considerable risk.
Actually a big reason why the JS community chose something else has a lot to do with what is mentioned in the article. Typescript has a much different governance.
Going into your kitchen and making some food with the ingredients you have will always be, to use a buzzword, more sustainable than ignoring the state of the kitchen and saying make me an omelette, or worse calling up uber eats which isn't even sustainable if you pay.
I think it's been decades since I last saw a phrase like this used unironically.
What I use now in-place of Elm: purescript, roc, gleam.
I feel like I would love it. It seems pretty darn awesome.
But getting started on a MacBook Air 2018 seems like an exercise in defeat. Building the toolchain takes ages, I have tried twice just getting started and never got to compiling any examples.
Is anyone using rescript for anything?
Anyway I have since switched to gleam, mostly for project governance and tooling reasons! The particular way rescript ended up eventually emerging from the reason/bucklescript schism I think just had it shed a lot of interest and goodwill. The core of the language is so so strong (because of ocaml) but they seem almost embarrassed by the ocaml connection and seem to be trying to distance themselves from it. They've implemented a new standard library that reproduces mutable JS semantics and I just think that's a big step back too.
Gleam is a HN darling that comes up all the time but it's in a really great spot for being such a young language. Very very similar semantics to rescript if you're targeting JS, rock solid standard lib, tooling is very good, package ecosystem surprisingly robust and high quality. It's not always obvious if a library supports js targets or erlang or both, and I hope they address that soon. I think they have a much clearer idea of what they want to accomplish than rescript does so I switched. IDK check it out, I originally ended up in rescript looking for an elm replacement and now I've ended up here.
Since Elm compiles to JavaScript, all the new development features from JavaScript, HTML, and CSS are also instantly available in Elm. I.e. it's not necessary to change Elm all the time to keep it up to date with the web platform. For non-stop Elm content check out all the communities at https://elm-lang.org/community
Though I’m convinced it didn’t reach critical mass purely because of community management issues mentioned in the post. Too many people just threw their hands in the air and divested from Elm because of it. Not everybody wrote a blog post about it.
The big reason why it - and all the other typed/functional compile to JS languages (PureScript, Reason, etc.) - remained niche is because TypeScript came along. It integrated with the ecosystem more seamlessly, was instantly comfortable for JS devs, and was backed by MS who gave it first-class support in VSCode. Arguably TypeScript is not as good as those other languages, but none of them are better enough to overcome those network effects.