frustrating, too, because I was really enjoying the language, and everything about it up to that point. The tooling support for Elm is REALLY solid compared to some other functional compile-to-js languages out there.
If anyone is looking for a good functional compile-to-js language, I would suggest taking a look at ReasonML or possibly ClojureScript. Personally, I've just been using TypeScript written in a functional way, and it serves my needs at this point.
What's infuriating is that I do see the benefit of some degree of strict stewardship. It's just that it's too much in this case.
Basically my point is, some people like me are happy that there's a high bar of entry for contributions and that every change is carefully considered, even if sometimes that means changes happens more slowly.
Don't know if that could be true of Elm as well?
Imagine in Clojure if they said "you can't use Java libraries any more. Pure Clojure only from now on" but kept the ability to use Java libraries for the core libraries of the language. -- That is my understanding of the issue with Elm as it currently stands.
I can see the frustration with Elm though, especially that it was enacted as part of a version upgrade. If it was from the start, people would know what to expect, but this seems like a huge backward breaking change. I'd be annoyed as well.
In Clojure/Script, a lot of the tensions are more about what should be a community provided library, and what should be lifted as officially included in core. I see the core team tends to favour most language extensions to be kept as a library. And often when people want changes to the language to be made, the answer is that Clojure/Script is designed to allow user level changes, so whatever you don't like you can change for yourself. Some people still arn't happy about that, they want their ideas to become the standard.
A lot of that stems from it being a Lisp. There's very little of Clojure/Script that actually necessitates changes to the compiler itself. Even the core functionality, most of it is implemented on the basic primitives the compiler gives, so you can happily change and extend almost anything if you disagree with the core team's choices.
Back to Elm, I know personally, I've never been into a language restricted to only one use case, the web. It seems Elm has always wanted to be more of a framework for web development. A very opinionated one. This seems to be a move even more on that direction. Like if Ruby didn't exist, but only Ruby On Rails did. Correct me if I'm wrong here. It could lead to something nice in the long run, but like any framework, the trade off is that when it doesn't have the feature you need, you're stuck.
>all the top community contributors left
Please don't pass on misinformation.
I just feel like people are right that the core team is not reasonable but at the same time, if there are that many people that like Elm, why not create a total fork?
It might come down to the people that would care enough to do the fork and a server or whatever have already had so much Koolaid that they just accept those negatives. And the other ones that can't accept it don't like it enough anymore to go to the trouble of making a fork.
But to me it seems like the best outcome is a fork that becomes successful.
Hard pass on Elm if this is true. This is an incredibly damaging accusation, is this consistent with other people's experience using Elm?