Hacker News Reader

Comment by IRLIamOffline | Hacker News Reader

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.

View on HN

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.

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.

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."

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.

Squeak Smalltalk had this. "Burn the diskpacks!"

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.

Reply on news.ycombinator.com