Comment by maxiepoo
1 year ago
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.
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?
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'.
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.
But they didn't make that tradeoff.
They said sync FFI for us but not for you.
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.