It's interesting that you bring this up, because I'd consider Go and Haskell as almost polar opposites. Go is a simple language which lacks expressibility but with strong opinions on almost everything from formatting to architecture, which leads to a streamlined (and refreshing) developer experience.

Haskell is a complex language, with an expressive type system giving you more tools and guarantees but I would call the learning / dev experience everything but streamlined.

I wonder whether the difference in the organisational structure (single entity vs community) manifests in the characteristics of these languages.

I think a big part of the success of Haskell is down to its language extensions. New features are introduced as off by default and can be opted into. This allows all kinds of crazy features to be introduced without really impacting users if they don't want to. It does allow the community to be quite experimental without fear of destroying things.

Haskell also has the motto "Avoid 'success at all costs'."[1] What that means is not that they want to fail at the things they set out to do, but that they want to ensure the language is never in a position where it's so important that certain behaviors or code be kept exactly the same because there's too much code that depends on it in the wild that they can't experiment with some new interesting feature in the next release. It is fundamentally an experimental language; while it is used for certain production applications, there's a sense in which the Haskell community+language simply can not ever become a top-tier language, by the community's design. If anything like Haskell ever does get into top-tier status, it'll be something that claims Haskell as a parent, not Haskell itself.

[1]: Edited, thank you maxiepoo.

The "motto" (if it can be called that) is not "avoid success", it's "avoid 'success at all costs'" which makes the sentiment clearer: increasing adoption should never be a priority over principled design.

Interestingly, the motto can be parsed two ways, with different connotations.

"Avoid (success at all costs)" or "(avoid success) at all costs."

You can opt out of using those extensions in your own code, but many of them are now deeply embedded in the library ecosystem.

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.

Ironically the community designed language is so complicated that programs can only be mantained by small teams of original authors, while the tightly controlled language is consistent enough that large groups can collaborate on one program.

Haven’t most of the top Haskell devs been on the Microsoft payroll for years and years?

SPJ and a fe wothers work at microsoft, but they are few compared to the community. Likewise, several high profile haskellers were at Standard Chartered, but I don't believe this was significant.

I would say the main drivers of Haskell these days are academics, PhDs and consultancies.

SPJ is a Microsoft Research Cambridge employee, but as far as I know that doesn't give Microsoft Research (let alone Microsoft itself) any undue influence over the language's direction, they can't gatekeep or ram things into Haskell or GHC.

It would still be corporate sponsorship and not a true community effort though. Not having to work to pay bills makes it much easier to run a large project.

Pretty sure SPJ does have to work to pay bills. It's just that they work for a research institution and can thus do part of their work in / on the project. In no small part because CS research was one of the use cases for creating Haskell.

Majority of open source contributors have a day job.

And Haskell's market success is still very limited. This isn't a very compelling argument for community-driven language design. I think a better one would be Rust (to the extent that we can agree that Rust is designed by community) which seems to be getting a fair amount of market penetration given its age.

Haskell deliberately "avoids success at all costs" though.

It don't think it matters whether it avoids success deliberately or accidentally.

And the community is by far the friendliest I have encountered!

Wasn't Haskell created by a university? That would be more tax dollars than community-driven.

Haskell was designed by a committee of researchers from various universities, but the first(?) working compiler came out of a University of Glasgow project.

Aren't tax dollars the ultimate manifestation of "community driven"?

I think Haskell was largely derived from Miranda, a commercial product.

Perhaps 'inspired by', but not 'derived from'.