It doesn't actually make sense to fork Elm. There are pretty good general-purpose languages already which offer a superset of Elm's (the language) functionality. I think all of them already have Elm-like implementations available as libraries. In fact there's at least one migration tool that helps convert away from Elm: https://github.com/darklang/philip2
Choosing to hard-fork Elm and create lots of internet drama just doesn't make sense compared to moving to one of the above.
And if it worked, they either A) split the userbase in half and make Elm LESS likely to be useful or B) get most of the userbase and make Elm totally irrelevant.
Forking a language isn't like forking a tool. Forking gcc doesn't make C any better or worse. Forking C (if you could) would make the C worse.
But "if they all got together" is waving away the difficulty of getting them all together, cooperating, and working together. Open source projects are a lot more difficult to run than you might expect.
> Open source projects are a lot more difficult to run than you might expect.
Indeed. You pour thousands of hours of work into something and give it to the world for free, only to be met by “give us synchronous IO or we will throw our toys out of the pram!”
That specific example would just be laughable. "I gave you awesome asynchronous I/O; just write the five lines of code around a semaphore if you want it synchronous."
I am sure this moment is coming when somebody creates a fork and gets rid off the artificial hypocritical limitations imposed by the current core team.
All of these leavers could've maintained that fabled community fork they want with the features they want if they all got together.