Developing GHC for a Living

Re:Developing GHC for a Living by dustingetz on Thursday January 30, 2020 @01:10PM (#22193656)

There are a lot of unacknowledged tradeoffs in tools like Haskell. For example the value of Haskell is balanced against ecosystem value of having 10M people using the same tools. Getting 10M people to choose Haskell is actually a goto market strategy problem that could be solved by a charismatic leader, but I don't hear anybody from that community talking about that.

[ Parent | on HN ]

Re:Developing GHC for a Living by _bxg1 on Thursday January 30, 2020 @01:14PM (#22193684)

To be clear: I'm not making any statements about Haskell itself (though I think you make a good point). A certain amount of idealism can be a good thing. It's perfectionism that's dangerous, and there's a fine line between the two.

[ Parent | on HN ]

Re:Developing GHC for a Living by Ericson2314 on Thursday January 30, 2020 @03:47PM (#22195375)

> ecosystem value of having 10M people using the same tools

That is I think one of the fairer criticisms of Haskell. I don't personally mind, but I respect others that do so.

That said, I wouldn't want 10M more users right now. The Haskell ecosystem right now has tons of breaking changes, and I think that is important. More users would freeze things in place until we have the tooling to both have breaking changes and tool-assisted migrations. Only then would I want rapid growth in popularity.

(Compare Rust's "backwards compat is really important", ....as if they they could get everything right the first time ....as if that won't lead the way of C++. Thank god they relented a bit with "editions".)

[ Parent | on HN ]

Re:Developing GHC for a Living by dragonsh on Thursday January 30, 2020 @05:16PM (#22196404)

You are absolutely right adherence to backward compatibility will eventually leads to situations similar to C++ or C. Rust and go eventually will be facing same issues as C++ or C today, once they reach critical mass like them (which itself is a question mark for Rust).

Haskell and other FP language is a completely different paradigm and it’s true unless there is very good tooling which can transparently take old code and move it to new code with breaking changes every language will go through that transition, we can’t be prophets, who can know exactly what’s there in future precisely. Python learned it the hard way as when it was designed didn’t have Unicode and later to support it gone through 2 to 3 transition disaster. Java was lucky in 1996 as by that time Unicode was popular and it backed it in language and JIT infrastructure.

But at present in Haskell tried both cabal and stack to compile elm 0.19.1 compiler and pandoc and found it’s really hard due to version incompatibilities of GHC. I hope situation in Haskell improves so that GHC can compile old and new code transparently without too much fiddling and pain.

[ Parent | on HN ]

Re:Developing GHC for a Living by aratakareigen on Thursday January 30, 2020 @06:50PM (#22197325)

> Rust and go eventually will be facing same issues

Isn't Rust's workaround their "edition" system? It seems to be working pretty well for them, but it sounds like it could end up being a massive maintenance headache.

https://doc.rust-lang.org/nightly/edition-guide/editions/ind...

[ Parent | on HN ]

Re:Developing GHC for a Living by bontaq on Friday January 31, 2020 @01:15AM (#22199534)

Absolutely, after stack happened and ghc started a faster release cycle it felt like the system was breathing again. 10M more users would be detrimental at this point, because the language is actually moving.

[ Parent | on HN ]

Re:Developing GHC for a Living by erik_seaberg on Thursday January 30, 2020 @08:54PM (#22198256)

I doubt you can appeal to ten million people without turning your language into just another Blub dialect. There's a joke that Haskell is navigating between "avoid success-at-all-costs" and "avoid success, at all costs".

[ Parent | on HN ]