Why I'm leaving Elm (2020)
lukeplant.me.uk
lukeplant.me.uk
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.
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 are bugfix PRs open for years now on the compiler and the core libraries.
> 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.
30 PRs that have been open for a very long time untouched. The point is getting stuff merged into Koka is not easy.
He also shows up in the comments here https://news.ycombinator.com/item?id=42954103
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.
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.
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.
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.
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.
LOL
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.
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.
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?
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'.
They said sync FFI for us but not for you.
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 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.
>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.
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)
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.