Comment by hombre_fatal
1 year ago
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.
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'.
1 reply →
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.
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.
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.
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)
1 reply →
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.