Why I'm leaving Elm (2020)(lukeplant.me.uk)
lukeplant.me.uk
Why I'm leaving Elm (2020)
https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
88 comments
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.
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.
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.
One of the core team members mentioned in the article showed up on HN a couple weeks ago:
https://news.ycombinator.com/item?id=42935516
https://news.ycombinator.com/item?id=42935516
Can you link to the comment specifically? This is just a link to the submission itself.
Presumably https://news.ycombinator.com/item?id=42954103, which does not really concern Elm.
He’s the author of the article but only chimes in once.
Sorry for not linking it, just wasn’t sure I wanted a Google Alert, but it seems likely at this point and I don’t mind. I’m somewhat undecided about Elm and Roc. Both are at least innovative.
Sorry for not linking it, just wasn’t sure I wanted a Google Alert, but it seems likely at this point and I don’t mind. I’m somewhat undecided about Elm and Roc. Both are at least innovative.
Not sure what you mean by Google Alert, what is that regarding?
A Google Alert notifies when a search term, such as someone's name, appears online, so mentioning someone in a public comment might trigger an alert, causing them to notice it.
I see what you mean, that's probably pretty unlikely though as the vast majority of people, even developers or leads, don't set up Google Alerts.
The “his comment” link here for this article: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/#forka... In the HN submission I linked, the author of the article is the same.
Now I understand, the author is (or was, I suppose) a core team member of Elm, I thought it were someone that commented on the post instead. I interpret "showed up on HN" to typically mean a commenter rather than an article author as typically many authors don't even realize their article was submitted to HN on any particular day.
The person in question (Richard Feldman) is the creator of Roc, which the linked article is about.
He also shows up in the comments here https://news.ycombinator.com/item?id=42954103
He also shows up in the comments here https://news.ycombinator.com/item?id=42954103
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.
I kind of wish the effort spent on Roc was put into productionizing/commercializing Koka (which Roc draws a lot of inspiration from) rather than starting an entirely new language. Like I get starting from scratch when it comes to Haskell, since there’s so much baggage there, but Koka is a pretty blank slate.
Koka is still pretty much one person's project [0], and it's not for lack of PRs [1]. To push Koka forward at the kind of pace that Richard wants to move would require forking it or commandeering it, and it makes total sense that neither option is as appealing as just starting fresh.
[0] https://github.com/koka-lang/koka/graphs/contributors
[1] https://github.com/koka-lang/koka/graphs/contributors
[0] https://github.com/koka-lang/koka/graphs/contributors
[1] https://github.com/koka-lang/koka/graphs/contributors
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.
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 last commits on GitHub are from mid 2024
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.
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.
It's dead, maybe it just doesn't know it yet.
No, its not. They are focused on introducing ELM on the backend as well. ELM isn't backed by big corpos like Rust and Go do so their way of operation will differ by a huge margin than those two langs, especially in terms of marketing so its inaccurate to judge that its dead just due to the inactivity.
https://www.youtube.com/watch?v=0SUM4869ODc
https://www.youtube.com/watch?v=0SUM4869ODc
Dead means different things to different people, but there is no way in hell I'd start a new project using a niche language that hasn't been updated in almost a year.
I see.
I would though. ELM has a very simple, straight forward syntax and everything revolves around the ELM architecture, which makes the whole thing very intuitive. I believe a statically typed and functional language will do just fine without any update for years as long as the initial implementation is done right. Unless there is a need to add some new feature, there is not point in updating the language if all the essentials were well implemented already. ELM compiles to JS and not to a native architecture. It'd be inappropriate to view ELM like one would view languages like C or any that uses LLVM as its backend.
I would though. ELM has a very simple, straight forward syntax and everything revolves around the ELM architecture, which makes the whole thing very intuitive. I believe a statically typed and functional language will do just fine without any update for years as long as the initial implementation is done right. Unless there is a need to add some new feature, there is not point in updating the language if all the essentials were well implemented already. ELM compiles to JS and not to a native architecture. It'd be inappropriate to view ELM like one would view languages like C or any that uses LLVM as its backend.
> there is not point in updating the language if all the essentials were well implemented already.
There are bugfix PRs open for years now on the compiler and the core libraries.
There are bugfix PRs open for years now on the compiler and the core libraries.
And keep in mind you can't even fork the compiler to fix them lest you be cast out of their community, whatever is left of it anyway!
From the comments:
> I was very excited for this interview but felt like Evan really didn’t say much of substance and largely avoided the interesting questions
>> It was a total pity party, dude acts like he invented bottled water
>>> Except, no, he doesn't act like that. He did invent something new, though, that is valuable to a lot of people. In spite of this he's still humble; outside of jealousy I'm not sure how you can justify saying he's acting like that. Why did you watch this video? To pick on Evan or Elm?
>>>> And to your insidious question, I reject the premise as neither of your hateful canned options for me fit the bill. You can spend your days defending people you don’t know, I will spend mine critiquing publicly what is obvious: Even thought he’d end up like Van Rossum or Dahl but he forgot the part where your creation brings something new to market—he only brought a new way of creating something that was already in the market (web applications). When will people get it through their skulls that can’t monetize anything if you’re unwilling to let others be involved in your work aside from throwing money at you. It’s completely ridiculous and naive and he’s butt hurt over this realization.
Another thread:
> For my part, the Elm ship has mostly sailed. I can't ignore the fact that the bdfl disappeared for multiple years without notice. That's not how trust is built.
>> i mean did Elm cease to be a perfectly usable language in the interim? what part of the FOSS social contract made you think he was obligated to provide notice?
>>> No one is "obligated" to do anything. I'm not obligated to put in effort to keep in contact with my friends and family, but if I don't I also can't be mad if our relationships drift apart. No, Evan isn't obligated to do anything with Elm that he doesn't want to do, but we also shouldn't be surprised if people question the suitability of a language, if the BDFL just up and disappears. A language isn't a small, one or two file, library that I can just copy paste and fix a bug, if the maintainer isn't reacting to issues or accepting pull requests. And it certainly isn't something that I want to take over the full burden of maintaining. So I need to know that I can, at the very least, work with the maintainers to fix issues as they come up. The view on open source is also extremely negative. Evan was offered a lot of chances to have other people come in and to build a strong core team for Elm. And there are many open source projects (including languages), that operate very successfully around that model and even manage to rotate people out, if they become exhausted with the project. So while I in no way condone attacking Evan directly, it's also fair to acknowledge that there are very good reasons people aren't investing into Elm for their next big project.
This sort of community is part of why I left Elm too, supporters seem to have an immediate knee jerk reaction to any sort of criticism and literally seem to treat Evan as some sort of messiah figure, unreasonable things like, "well, it never said anywhere that people have to give notice" if they're going to have radio silence for 5+ years, like, yeah, but it'd be a good faith effort if they did.
> I was very excited for this interview but felt like Evan really didn’t say much of substance and largely avoided the interesting questions
>> It was a total pity party, dude acts like he invented bottled water
>>> Except, no, he doesn't act like that. He did invent something new, though, that is valuable to a lot of people. In spite of this he's still humble; outside of jealousy I'm not sure how you can justify saying he's acting like that. Why did you watch this video? To pick on Evan or Elm?
>>>> And to your insidious question, I reject the premise as neither of your hateful canned options for me fit the bill. You can spend your days defending people you don’t know, I will spend mine critiquing publicly what is obvious: Even thought he’d end up like Van Rossum or Dahl but he forgot the part where your creation brings something new to market—he only brought a new way of creating something that was already in the market (web applications). When will people get it through their skulls that can’t monetize anything if you’re unwilling to let others be involved in your work aside from throwing money at you. It’s completely ridiculous and naive and he’s butt hurt over this realization.
Another thread:
> For my part, the Elm ship has mostly sailed. I can't ignore the fact that the bdfl disappeared for multiple years without notice. That's not how trust is built.
>> i mean did Elm cease to be a perfectly usable language in the interim? what part of the FOSS social contract made you think he was obligated to provide notice?
>>> No one is "obligated" to do anything. I'm not obligated to put in effort to keep in contact with my friends and family, but if I don't I also can't be mad if our relationships drift apart. No, Evan isn't obligated to do anything with Elm that he doesn't want to do, but we also shouldn't be surprised if people question the suitability of a language, if the BDFL just up and disappears. A language isn't a small, one or two file, library that I can just copy paste and fix a bug, if the maintainer isn't reacting to issues or accepting pull requests. And it certainly isn't something that I want to take over the full burden of maintaining. So I need to know that I can, at the very least, work with the maintainers to fix issues as they come up. The view on open source is also extremely negative. Evan was offered a lot of chances to have other people come in and to build a strong core team for Elm. And there are many open source projects (including languages), that operate very successfully around that model and even manage to rotate people out, if they become exhausted with the project. So while I in no way condone attacking Evan directly, it's also fair to acknowledge that there are very good reasons people aren't investing into Elm for their next big project.
This sort of community is part of why I left Elm too, supporters seem to have an immediate knee jerk reaction to any sort of criticism and literally seem to treat Evan as some sort of messiah figure, unreasonable things like, "well, it never said anywhere that people have to give notice" if they're going to have radio silence for 5+ years, like, yeah, but it'd be a good faith effort if they did.
It has been dead for years and years. I had an interest in learning and using Elm several years ago, but the bus factor of 1 told me it was dead on arrival.
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.
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.
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.
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?
>>>> 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.
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.
> 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.
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.
> 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.
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
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.
Guess what, if the project leader doesn't owe anyone anything, then the author of TFA also doesn't owe him anything.
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.
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.
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.
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.
>and then a high level language like c or shell
I think it's been decades since I last saw a phrase like this used unironically.
I think it's been decades since I last saw a phrase like this used unironically.
As a former Elm production user, the article is spot-on about why I moved on from the Elm community.
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.
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.
The authors of Gren are all active in Elm community spaces. The first commit of Gren is the last public commit of Elm.
> 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.
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.
Wonderful language ruined by toxic culture.
What I use now in-place of Elm: purescript, roc, gleam.
What I use now in-place of Elm: purescript, roc, gleam.
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.
Is anyone using rescript for anything?
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?
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.
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.
Elm is not dead. Here some recent commits: https://github.com/search?q=stars%3A%3E1+language%3Aelm&type...
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
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).
Most people searching for "elm" are researching elm trees, not the language - the highest search activity was in May 2010, before Elm existed.
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.
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.
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.
TypeScript is as old as Elm, though. Arguably more so when you consider prod deployments.
I don't like this kind of diatribe.
Evan this, Evan that.
Yes, if the license on the thing is open source, it is open source.
People don't owe you being in their community or whatever.
Fork it, get your shit working, don't tell anyone.
When you fork, change the name. Even GNU projects prohibit forking under the same name; you can't fork GNU Emacs and call your forked project GNU Emacs.
Evan this, Evan that.
Yes, if the license on the thing is open source, it is open source.
People don't owe you being in their community or whatever.
Fork it, get your shit working, don't tell anyone.
When you fork, change the name. Even GNU projects prohibit forking under the same name; you can't fork GNU Emacs and call your forked project GNU Emacs.
tl;dr: the Elm compiler has a hardcoded whitelist of projects allowed to use certain critical language features, and anyone who releases a fork of the compiler without that antifeature gets banned from the project's community.
Weird. Why can’t you patch your local version to include the name of your project?
That's a poor analogy. Rails has always had "here's a sharp knife; be careful with it, but you're an adult so use it how you will" philosophy. So Rails comes with recommendations for use, but not mandates.
if your project is a library no one can use it without a similar patch
Yup, that's a failed language.
Appreciate it. I got through about 10 paragraphs of preamble and disclaimers before giving up. I’m sure this document is what the community and author need it to be, but only being interested in the technical takeaways, your comment at least helps me know what to skim for.
That burns any interest I ever had for looking into Elm.
The language features in question are, to my knowledge, unrestricted JS FFI and adding infix operators. Banning the former completely removes a whole class of security vulnerabilities. Banning the latter means you can't be as terse as you want but new authors in a codebase don't have the problem that new authors in a Haskell codebase can have. So they're both tradeoffs.
So why hasn't anyone set up their own hard-fork community a la neovim? Just not enough interest in it?
1. In open source, everyone plays lip service to how you can just fork things, but nobody wants to do the hard, infinite work of building a new ecosystem. You'll just rediscover the exact thing that burned evancz out.
2. Elm's stance on sync vs async ffi isn't a big deal. A fork is like when there was that IcedCoffeeScript spin off on CoffeeScript: https://maxtaco.github.io/coffee-script/ -- it's more of a gimmick in what is already a tiny ecosystem.
3. Last I checked there was "elm-janitor" for managing patches and getting them into core Elm as an end user or something. Dunno what came of it, but I think it goes back to only a handful of people are going to use something like that. And there are already Elm-inspired languages with ~0 users out there. The hard part is ecosystem.
It's not like Javascript where you can launch something like preact (react but smaller) and get 38k github stars. It's not going to be rewarding.
2. Elm's stance on sync vs async ffi isn't a big deal. A fork is like when there was that IcedCoffeeScript spin off on CoffeeScript: https://maxtaco.github.io/coffee-script/ -- it's more of a gimmick in what is already a tiny ecosystem.
3. Last I checked there was "elm-janitor" for managing patches and getting them into core Elm as an end user or something. Dunno what came of it, but I think it goes back to only a handful of people are going to use something like that. And there are already Elm-inspired languages with ~0 users out there. The hard part is ecosystem.
It's not like Javascript where you can launch something like preact (react but smaller) and get 38k github stars. It's not going to be rewarding.
The community is small enough that it wouldn't make much sense.
This may be a good summary of the blog post, but in my opinion it is an uninformed understanding of Elm and Elm's history. JavaScript FFI isn't and never has been a "critical language feature". Rather, people discovered an implementation detail that allowed them to create thin Elm wrappers around JS libs (think Elm interface for d3, leaflet, moment, etc...). This was (rightly IMO) seen as undesirable for multiple reasons and 0.19 closed off the loophole at the compiler level.
As for being banned from the community, I keep seeing this claim but have never seen or heard of such things happening. Sure, there may be a negative reception to folks who keep wanting to re-litigate a decision that was made over and over, but nobody has been banned from anything.
As for being banned from the community, I keep seeing this claim but have never seen or heard of such things happening. Sure, there may be a negative reception to folks who keep wanting to re-litigate a decision that was made over and over, but nobody has been banned from anything.
[deleted]
> native modules in Elm allow you to write part of an Elm module in Javascript
LOL
LOL
I think this post captures the wave of entitlement among a group of Elm participants of that era that led to what looks like catastrophic burnout in evancz, Elm's creator.
It's been a while since I watched them, and I recommend his talks, but at least one or two of his talks are centered around what is basically unfair expectations. In one talk, [bad paraphrasing, but] he compares how people's expectations of him and Elm aren't much different than the expectations they have of languages with millions of dollars of corporate support behind them, and people don't temper their their expectations accordingly when dealing with him.
You just know it's a shit show starting a language and then having an increasing amount of your time pilfered by people who think because they are a big fish in your small pond (ecosystem), they deserve a level of command they would never expect from, say, React or Javascript or SwiftUI or Swift.
I still use Elm for personal projects. It's the one stack I've used where I can revisit a project I haven't touched in ten years and instantly push out a new feature. Just by writing the code I want to exist and then backtracking through type errors until it's implemented (that really never gets old). It makes a lot of sense for personal projects for that reason which tend to accumulate infinitely.
I always kinda wonder how evancz would describe his experience off the record, friend-to-friend.
It's been a while since I watched them, and I recommend his talks, but at least one or two of his talks are centered around what is basically unfair expectations. In one talk, [bad paraphrasing, but] he compares how people's expectations of him and Elm aren't much different than the expectations they have of languages with millions of dollars of corporate support behind them, and people don't temper their their expectations accordingly when dealing with him.
You just know it's a shit show starting a language and then having an increasing amount of your time pilfered by people who think because they are a big fish in your small pond (ecosystem), they deserve a level of command they would never expect from, say, React or Javascript or SwiftUI or Swift.
I still use Elm for personal projects. It's the one stack I've used where I can revisit a project I haven't touched in ten years and instantly push out a new feature. Just by writing the code I want to exist and then backtracking through type errors until it's implemented (that really never gets old). It makes a lot of sense for personal projects for that reason which tend to accumulate infinitely.
I always kinda wonder how evancz would describe his experience off the record, friend-to-friend.
I'm still trying to wrap my head around the anti-forking sentiment among the community and how tight the governance structure of the project is. Open source is hard, and people will always have unfair expectations of open source, but if I'm to take the article at face on the forking drama, what's so bad about letting people tinker with it and release their own forks of Elm? If you're burned out, what's the harm in letting others step in more?
Because it means having to give up control and accept that other people are going to contribute - even when they don't follow your own long-term vision.
The Elm Vision is that every library should be infinitely powerful, trivial for novices to learn, and written 100% in Elm. Any deviation from this is seen as a failure of the entire Elm project and a personal embarrassment. The problem is that these standards are way too high and essentially impossible to achieve for any nontrivial library.
The biggest risk of letting other people step is that they may succeed. They're going to write code which is incredibly useful to a lot of people, and it's going to become popular. But those developers aren't strictly following the Elm Vision. They are pragmatic, and they are willing to cut some corners in order to actually ship something. This of course leads to difficult questions like "It works great in library XYZ, why don't we just adopt that in Core Elm?". But you can't, because it breaks your Elm Vision, and you don't have infinite time and money to reinvent the wheel for dozens of core web features until it is 100% perfect according to your Vision. You're rapidly losing grip, and people start talking about a fork.
Elm is becoming a success, but your Elm Vision is rapidly degrading and at risk of failing completely. You can't let them fork. You must maintain control. Your Vision must survive, and it's the only way. You've spent so much time and effort on this. You can't let it fail. It's your life's work. You don't want all that effort to go to waste. You don't want to be a failure. We just have to make sure everyone understands the Vision, and everything will work out okay. We just have to properly educate the dissenters and all will be fine.
---
I don't live in Evan's head, so I'm not going to claim this is his train of thought. But if you're looking for a reason not to let other people step in, here's one possible explanation for you.
The Elm Vision is that every library should be infinitely powerful, trivial for novices to learn, and written 100% in Elm. Any deviation from this is seen as a failure of the entire Elm project and a personal embarrassment. The problem is that these standards are way too high and essentially impossible to achieve for any nontrivial library.
The biggest risk of letting other people step is that they may succeed. They're going to write code which is incredibly useful to a lot of people, and it's going to become popular. But those developers aren't strictly following the Elm Vision. They are pragmatic, and they are willing to cut some corners in order to actually ship something. This of course leads to difficult questions like "It works great in library XYZ, why don't we just adopt that in Core Elm?". But you can't, because it breaks your Elm Vision, and you don't have infinite time and money to reinvent the wheel for dozens of core web features until it is 100% perfect according to your Vision. You're rapidly losing grip, and people start talking about a fork.
Elm is becoming a success, but your Elm Vision is rapidly degrading and at risk of failing completely. You can't let them fork. You must maintain control. Your Vision must survive, and it's the only way. You've spent so much time and effort on this. You can't let it fail. It's your life's work. You don't want all that effort to go to waste. You don't want to be a failure. We just have to make sure everyone understands the Vision, and everything will work out okay. We just have to properly educate the dissenters and all will be fine.
---
I don't live in Evan's head, so I'm not going to claim this is his train of thought. But if you're looking for a reason not to let other people step in, here's one possible explanation for you.
Basically, Evan decided he wanted Elm to be a pre-packaged closed ecosystem where it was easy to develop very simple standalone apps, but made it very difficult to impossible to actually integrate with any existing JavaScript code or libraries. This was a baffling decision to people who thought Elm was supposed to be a practical language.
Blaming everything on "entitlement" from people who bought Elm's marketing about "making functional programming practical" is ridiculous. Thankfully there are now plenty of languages with better type systems than Elm (Rust, OCaml) that deploy to the web just fine.
Blaming everything on "entitlement" from people who bought Elm's marketing about "making functional programming practical" is ridiculous. Thankfully there are now plenty of languages with better type systems than Elm (Rust, OCaml) that deploy to the web just fine.
Yeah I think you summed this up nicely. "Entitlement" is an easy go-to explanation since the internet is filled with it, but it's one sided. If you're pitching a language to people and they put a lot of energy into building on it, only to have their work permanently broken with no workarounds, you're going to get blowback. At the end of the day, Elm core team is free to make their own decisions, but they have to live with the consequences of those decisions. They are no more entitled for their users to remain silent than their users are to demand a certain technical direction.
This is why open source governance is so important. Technical excellence is orthogonal to community management excellence, and you can't scale an open source project without some measure of the latter.
This is why open source governance is so important. Technical excellence is orthogonal to community management excellence, and you can't scale an open source project without some measure of the latter.
The entitlement doesn't come from thinking "dang, the project doesn't do what I want".
It comes from getting worked up that it doesn't. And it comes from getting worked up that your github/forum/slack correspondence doesn't go in your favor just because you really want something, even if you think you should have more clout because it's a small community.
Elm made a controversial but reasonable trade-off for its packaging ecosystem: No synchronous FFI, only async FFI (over ports or web components). That means that you can count on Elm packages to not have runtime bugs due to sync JS which is a reasonable guarantee with reasonable workarounds.
As for whether Elm is impractical or impossible to integrate with JS code because of it, did you try? To me this complaint is like when I used to read people saying JS Promises led to worse code than JS callbacks early on in Javascript's transition. I couldn't relate to it much. You learn the idiosyncrasies and you move on.
I think part of the entitlement is the people who choose to never move on. Elm sucks, it's impossible to integrate, it's impractical, nobody should use it. Or... exit the theater and let the rest of us enjoy the show?
It comes from getting worked up that it doesn't. And it comes from getting worked up that your github/forum/slack correspondence doesn't go in your favor just because you really want something, even if you think you should have more clout because it's a small community.
Elm made a controversial but reasonable trade-off for its packaging ecosystem: No synchronous FFI, only async FFI (over ports or web components). That means that you can count on Elm packages to not have runtime bugs due to sync JS which is a reasonable guarantee with reasonable workarounds.
As for whether Elm is impractical or impossible to integrate with JS code because of it, did you try? To me this complaint is like when I used to read people saying JS Promises led to worse code than JS callbacks early on in Javascript's transition. I couldn't relate to it much. You learn the idiosyncrasies and you move on.
I think part of the entitlement is the people who choose to never move on. Elm sucks, it's impossible to integrate, it's impractical, nobody should use it. Or... exit the theater and let the rest of us enjoy the show?
But they didn't make that tradeoff.
They said sync FFI for us but not for you.
They said sync FFI for us but not for you.
Actually, it comes from the concrete complaints specified in the article, such as the total exclusion from official Elm spaces if you try to fix your own problems. If it was what you described, i.e. the inability to do things within the packaging ecosystem, that would be acceptable; that was the status quo in 0.18 and everyone dealt with it.
The basis for calling complaints about functionality 'entitlement' is that you put it into the world because you want to, and the default avenue for other people getting what they want is to put it into the world themselves. If you lure people to get invested in your project, cause a problem for anyone invested in your project, and attempt to prevent them from solving their problem themselves, then you are behaving irresponsibly and complaints about this do not stem from 'entitlement'.
The basis for calling complaints about functionality 'entitlement' is that you put it into the world because you want to, and the default avenue for other people getting what they want is to put it into the world themselves. If you lure people to get invested in your project, cause a problem for anyone invested in your project, and attempt to prevent them from solving their problem themselves, then you are behaving irresponsibly and complaints about this do not stem from 'entitlement'.
To Elm's supporters, Evan can do no wrong (because anyone who disagrees is ejected from the community, of course), creating a cult-like following that only gets more insular as times goes on. Thankfully, it seems to have gotten so insular that the language has essentially now died out.
Author addresses this at the beginning, but I disagree with them:
>This means that even if a single person wrote every line of code of a language's compiler themselves, when it comes to thinking about the project, they need to think of themselves as stewards and not owners
I respect the author if they believe this and stick to it (they are involved in OS too), but for the rest of us this is a sure way to burn out.
>This means that even if a single person wrote every line of code of a language's compiler themselves, when it comes to thinking about the project, they need to think of themselves as stewards and not owners
I respect the author if they believe this and stick to it (they are involved in OS too), but for the rest of us this is a sure way to burn out.
If you don't want to be a steward of an open technology, why on earth would you become an open-source maintainer?
Almost nobody knows what it's like to maintain a popular project until they do it.
It's very hard to not spend all of your time managing people.
We like think that even responding to issues and pull requests are "just code", but they are actually people problems. You're managing people.
For example, this person spent a week on this pull request, but it wasn't something you wanted to be done, and they didn't do it the way that it should have been done. What do you tell them and how do you tell them? Now let's say they are a vocal person in your tiny ecosystem. It's not easy.
And a lot of the ecosystem you get is pure luck of the draw. Since ecosystems self-select (people who don't fit in in certain ways move on) you can get dynamics that really have nothing to do with you, whether you had zero presence or were 100% prescriptive about how the ecosystem should work. It's kind a bizarre to see over time. (Message boards back in the day were a good example of this too)
It's very hard to not spend all of your time managing people.
We like think that even responding to issues and pull requests are "just code", but they are actually people problems. You're managing people.
For example, this person spent a week on this pull request, but it wasn't something you wanted to be done, and they didn't do it the way that it should have been done. What do you tell them and how do you tell them? Now let's say they are a vocal person in your tiny ecosystem. It's not easy.
And a lot of the ecosystem you get is pure luck of the draw. Since ecosystems self-select (people who don't fit in in certain ways move on) you can get dynamics that really have nothing to do with you, whether you had zero presence or were 100% prescriptive about how the ecosystem should work. It's kind a bizarre to see over time. (Message boards back in the day were a good example of this too)
It is just the same as any other organizational leader, if it's getting to be too much, get others to join in to lead, delegate tasks, and the last solution, allow others to take your place and leave the organization. Not everyone is cut out to be a leader and we should not waste everyone's time forcing or pretending that it were so.
The author addresses exactly those sorts of talks you discuss, including explicitly showing how Evan made fun of the author after, even politely, making a criticism (if you could even call it that) of the language.
This is one of the major things that turned me off of Elm after having used it for a few years, the transformation of its supporters to essentially becoming fanboys instead, insisting that Evan could do no wrong, and that the very real criticisms of the community were merely "entitlements." The community simply became cult like in a way I have not seen before or since, in any language or technology discussion. Even in this thread you have people saying to avoid reading the article entirely and that surely the language is not dead despite not having a new version in almost 7 years.
Creators can make whatever decisions they want, but consumers can do so just as well, opting largely to leave the language and ecosystem.
This is one of the major things that turned me off of Elm after having used it for a few years, the transformation of its supporters to essentially becoming fanboys instead, insisting that Evan could do no wrong, and that the very real criticisms of the community were merely "entitlements." The community simply became cult like in a way I have not seen before or since, in any language or technology discussion. Even in this thread you have people saying to avoid reading the article entirely and that surely the language is not dead despite not having a new version in almost 7 years.
Creators can make whatever decisions they want, but consumers can do so just as well, opting largely to leave the language and ecosystem.
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.