[HN Gopher] Why I'm leaving Elm (2020)
___________________________________________________________________
Why I'm leaving Elm (2020)
Author : flykespice
Score : 88 points
Date : 2025-02-16 16:57 UTC (6 hours ago)
(HTM) web link (lukeplant.me.uk)
(TXT) w3m dump (lukeplant.me.uk)
| satvikpendem wrote:
| 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.
| benatkin wrote:
| 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
| satvikpendem wrote:
| Can you link to the comment specifically? This is just a link
| to the submission itself.
| Philpax wrote:
| Presumably https://news.ycombinator.com/item?id=42954103,
| which does not really concern Elm.
| benatkin wrote:
| 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.
| satvikpendem wrote:
| Not sure what you mean by Google alert, what is that
| regarding?
| benatkin wrote:
| 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.
| benatkin wrote:
| 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.
| satvikpendem wrote:
| 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.
| vosper wrote:
| 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
| lolinder wrote:
| 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.
| catgary wrote:
| 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.
| lolinder wrote:
| 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
| IshKebab wrote:
| I think your second link meant to go to the open PRs...
| but anyway there are only 30 open PRs? That seems
| relatively low?
| evmar wrote:
| 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.
| GiorgioG wrote:
| It's dead, maybe it just doesn't know it yet.
| FullGarden_S wrote:
| 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
| santoshalper wrote:
| 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.
| FullGarden_S wrote:
| 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.
| pyrale wrote:
| > 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.
| satvikpendem wrote:
| 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!
| idoubtit wrote:
| > 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.
| josephcsible wrote:
| 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.
| titanomachy wrote:
| Weird. Why can't you patch your local version to include the
| name of your project?
| benatkin wrote:
| https://youtu.be/E99FnoYqoII?si=r22RK3xy3NJoDnQr
| x0x0 wrote:
| 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.
| zem wrote:
| if your project is a library no one can use it without a
| similar patch
| taurknaut wrote:
| Yup, that's a failed language.
| chefandy wrote:
| 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.
| echelon wrote:
| That burns any interest I ever had for looking into Elm.
| chongli wrote:
| So why hasn't anyone set up their own hard-fork community a la
| neovim? Just not enough interest in it?
| hombre_fatal wrote:
| 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.
| pyrale wrote:
| The community is small enough that it wouldn't make much
| sense.
| hombre_fatal wrote:
| 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.
| digitxpc wrote:
| 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?
| maxiepoo wrote:
| 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.
| dasil003 wrote:
| 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.
| hombre_fatal wrote:
| 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?
| shipp02 wrote:
| But they didn't make that tradeoff.
|
| They said sync FFI for us but not for you.
| pie_flavor wrote:
| 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'.
| satvikpendem wrote:
| 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.
| msm_ wrote:
| 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.
| santoshalper wrote:
| If you don't want to be a steward of an open technology, why
| on earth would you become an open-source maintainer?
| hombre_fatal wrote:
| 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)
| satvikpendem wrote:
| 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.
| jfuasdfjw wrote:
| Wonderful language ruined by toxic culture.
|
| What I use now in-place of Elm: purescript, roc, gleam.
| cma256 wrote:
| 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.
| casey2 wrote:
| 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.
| ericyd wrote:
| 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.
| zahlman wrote:
| >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.
| pyrale wrote:
| As a former Elm production user, the article is spot-on about
| why I moved on from the Elm community.
| fortran77 wrote:
| 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
| jgilias wrote:
| 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.
| wk_end wrote:
| 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.
| alphazard wrote:
| 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.
| santoshalper wrote:
| 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?
| gregors wrote:
| >>>> 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.
| pyrale wrote:
| > 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.
| adius wrote:
| 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
| machine_ghost wrote:
| It may not be dead, but it does seem a bit stagnant. Based on
| Google Trends at least (https://trends.google.com/trends/explor
| e?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).
| felixguendling wrote:
| I asked "Ask HN: Is Elm dead" in 2022 with mixed results.
| https://news.ycombinator.com/item?id=31485011
|
| 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.
| satvikpendem wrote:
| 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.
| fmbb wrote:
| 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?
| giraffe_lady wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-16 23:01 UTC)