If I recall correctly, Elm grew out of Mr Czaplicki's PhD thesis or project. It seems that he still considers it _his_ project, which is fine for him and his employer but it does it make it hard for those not close to him to see where the language is going and get support.

In a perfect world (according to me), Elm would have 5-10 people in its core team, with at least a few of those tasked with triaging issues and PRs. That wouldn't mean "giving up" control of the language and its future.

His senior thesis at Harvard. Evan doesn’t have a PhD (not that he needs one).

> Elm would have 5-10 people in its core team, with at least a few of those tasked with triaging issues and PRs

That would be amazing, but I see this being very similar to Node in its infancy. It took a fork (io.js), and a lot of strong opinions to get Joyent to relinquish its grip on the ecosystem.

I think what the developers who forked Node into io.js showed was competency and care with regards to progress. I'm not sure that could ever happen in the elm ecosystem due to it being somewhat small and niche.

If Node was in its infancy when the io.js fork happened, then Elm is downright fetal. I don't think you can compare them.

It seems to me that the extreme BDFL governance of Elm is also its strong point at the expense of being then limited to that bandwidth, it's weak point.

Unfortunately, delegating work does not come for free and a great deal of energy will be burned in people management. Unless you're clairvoyant, it can't be said whether that would be any better for Elm or mire it in an even thicker mud.

Elm has a lot of unknowns that someone has to sit down and make decisions about because it wants to generalize over environments beyond browser-side Javascript. I think that sits at the root of why you can't just delegate out core contributor access.

But trying to do that generalization in the first place is also why Elm has some really interesting potential in the long run than just another SPA abstraction.

Definitely agree. I wouldn't even call the angular thing a transition, since it basically threw everything out. It should've really been called something else.

There's also big examples like Perl 6 and Python 3.

IMO, you can make breaking changes as long as it's done gradually and you provide a clear migration path. After experiencing React's strategy [0] for a few years, I'd say it's become my gold standard for how breaking changes should be made.

[0] https://reactjs.org/docs/design-principles.html#stability

Eh, python 3 wasn't really fundamentally different from 2, it just had some breaking changes and aside from that was an upgrade.

The React team seems that they put a lot of forethought into keeping the API and core stable. I was super impressed at the core rewrite that integrated the fiber architecture. The console warnings are a nice nod to good developer ergonomics.

The upgrade from Elm 0.17 to 0.18 was almost 100% automated. I thought it was going to be painful - but, thanks to the type system, wasn’t. Nothing like Angular.