Comment by alphazard
1 year ago
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.
> 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.
> 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.
>>>> 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.
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?
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.
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