Indeed. It's like a feature democracy where each library gets a vote on which features it finds most useful. Those that then get deeply embedded are clearly those that are most useful. Those features that aren't particularly used don't really get anywhere.

I sort of agree with that, but features often have externalities. For example, let's say I choose to use lambda case because it makes some of my code a little bit more concise. From my narrow point of view, that seems like a win. But then it's one more piece of syntax that external tools have to deal with, one more barrier to anyone trying to develop an alternative to GHC, one little piece of additional complexity to throw off Haskell newbies who want to read my code, etc. etc.

True. Those are all good points. I do still feel the upsides more than make up for it, but yes I am glad I'm not responsible for developing any external tools for Haskell!

Do you need an alternative to GHC?

What's GHC's bus factor? (Actual question.)

The top 10 contributors are active and fairly well known in the community (I recognize 5 of the names at least), of 170 members with commit bits for the project.

https://gitlab.haskell.org/ghc/ghc/graphs/master

I would certainly like a compiler that was fast enough to be usable with realistically-sized codebases. I'm writing this while waiting a couple of minutes for ~10,000 lines of Haskell to compile.

Interestingly, compilation time was one of the motivations for Go.

Can you create a Haskell compiler that is faster than GHC? Probably. Can you create one that is fast? I'm much more skeptical of that.