4 ms·

The attraction of Haskell is to build correct software in a mathematically principled way. With practice, it is also remarkably productive, certainly more so th

The attraction of Haskell is to build correct software in a mathematically principled way. With practice, it is also remarkably productive, certainly more so than Go when used as a general purpose language. Haskell is simply much more expressive and capable of abstracting over many more things (perhaps this is why you say it is hard to read). The Haskell ecosystem is also constantly evolving and solving more and more real world problems, often problems that have not been solved in other languages. Modern Haskell effectful streaming libraries actually make reasoning about stream processing much easier than in say Java, where the presence of effects (exceptions etc) destroys reasoning. > Go is now my favorite language. Is this really true? Or is it just the tool you are now most familiar with? It's certainly a much more riskier proposition to try and feed the kids writing Haskell. Quoting Rob Pike on Google's own Go programmers: "They're typically fairly young, fresh out of school, probably learned Java ... They're not capable of understanding a brilliant language ... So the language that we give them has to be easy for them to understand and easy to adopt." The Go toolset can obviously get the job done, but I don't understand why it would be anyone's favourite language, it doesn't even sound like it's Rob Pike's favourite language.

foldr 9y ago
>certainly more [productive] than Go when used as a general purpose language. Come on, there isn't really any evidence that Haskell is more productive than Go. It's not as if anyone's run a controlled experiment. Anecdotally, I've written code in both languages and not found much difference in productivity. I think a lot depends on the size of the team, the size of the code base, the nature of the algorithms being implemented, and the amount of IO that's performed. Haskell's abstractions have saved me time in some cases. But then again, I've also spent unproductive hours figuring out the complex abstractions that someone else decided to use. Haskell's so-so tooling and culture of using unqualified imports compound this problem. And then there's the issue of compile times. Do monad transformers make me more productive? Do functional dependencies make me more productive? I'm not sure. In contrast, I have no doubt whatsoever that fast compile times make me more productive. Most go codebases compile in under a second, whereas GHC's compile times are absolutely abysmal. Go is a language without intellectual insecurity. It doesn't care if you think it's stupid, or if you think that go programmers are stupid. It focuses on features that are known to make everyone more productive (e.g. fast compile times) at the expense of features that make you feel smart.
- willtim 9y ago
  > There isn't really any evidence that Haskell is more productive than Go. Go appears to be a network services language. Although Haskell has equally good for-loops and channels, it does not have an incremental garbage collector or fast build times. So Go has its place. For general purpose programming, Go is lacking so many features and provides such verbose syntax for what little it does have (worse than modern Java, e.g Lambdas and conditionals), that one can certainly say it is starting from a disadvantaged point with regard to productivity. It sounds like you've had some bad experiences with some of Haskells libraries and tooling. The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. With regard to complex abstractions, the Haskell community usually likes to formalise and reuse them. Learning an abstraction usually results in a big payoff. EDIT: > Do monad transformers make me more productive? Monad transformers are specific to pure functional programming, but yes they aid productivity. For example, I can build an effectful streaming type with resource management and other desired features by stacking existing transformers. In Go I would be solving such problems with for loops. > Do functional dependencies make me more productive? Functional dependences are specific to Haskell type classes, but yes they can aid productivity. For example, you want to express arithmetic ops on matrices and scalars and have the compiler figure out the correct dispatch and return type depending on the type of the values. In Go I can't overload operators or do multiple dispatch.
  - foldr 9y ago
    >The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. Hmm, that's what people have been telling me since I first learned Haskell in 2002. Your brush this off as if it's a minor point ("some bad experiences with Haskell's libraries and tooling"), but libraries, tooling and compile times are a major, major influence on productivity. If you're at leisure to wait for decent libraries and tools to become available, then good for you! I was kind of hoping to get stuff done now, though. Abstractions have both positive and negative payoffs. Take MTL as an example. It certainly increases code reuse and makes code more concise. On the other hand, it's also partly responsible for Haskell having a gazillion different techniques for handling errors, with little community consensus on what the best techniques are (see e.g. https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_best_practices_in_haskell/ https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_...). I spend at least some time thinking about this stuff when I write Haskell code. I spend no time thinking about it when I write go code -- I just write the same error handling boilerplate that every go programmer uses. It's not pretty, and I don't get to pat myself on the back for understanding something complicated. But does it make me less productive? Not sure. Response to edits: I think you're misunderstanding my comment. I use these features and know what they are. I'm telling you that I do not see any clear productivity benefit from them in practice. Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice.

foldr 9y ago

>certainly more [productive] than Go when used as a general purpose language. Come on, there isn't really any evidence that Haskell is more productive than Go. It's not as if anyone's run a controlled experiment. Anecdotally, I've written code in both languages and not found much difference in productivity. I think a lot depends on the size of the team, the size of the code base, the nature of the algorithms being implemented, and the amount of IO that's performed. Haskell's abstractions have saved me time in some cases. But then again, I've also spent unproductive hours figuring out the complex abstractions that someone else decided to use. Haskell's so-so tooling and culture of using unqualified imports compound this problem. And then there's the issue of compile times. Do monad transformers make me more productive? Do functional dependencies make me more productive? I'm not sure. In contrast, I have no doubt whatsoever that fast compile times make me more productive. Most go codebases compile in under a second, whereas GHC's compile times are absolutely abysmal. Go is a language without intellectual insecurity. It doesn't care if you think it's stupid, or if you think that go programmers are stupid. It focuses on features that are known to make everyone more productive (e.g. fast compile times) at the expense of features that make you feel smart.

willtim 9y ago
> There isn't really any evidence that Haskell is more productive than Go. Go appears to be a network services language. Although Haskell has equally good for-loops and channels, it does not have an incremental garbage collector or fast build times. So Go has its place. For general purpose programming, Go is lacking so many features and provides such verbose syntax for what little it does have (worse than modern Java, e.g Lambdas and conditionals), that one can certainly say it is starting from a disadvantaged point with regard to productivity. It sounds like you've had some bad experiences with some of Haskells libraries and tooling. The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. With regard to complex abstractions, the Haskell community usually likes to formalise and reuse them. Learning an abstraction usually results in a big payoff. EDIT: > Do monad transformers make me more productive? Monad transformers are specific to pure functional programming, but yes they aid productivity. For example, I can build an effectful streaming type with resource management and other desired features by stacking existing transformers. In Go I would be solving such problems with for loops. > Do functional dependencies make me more productive? Functional dependences are specific to Haskell type classes, but yes they can aid productivity. For example, you want to express arithmetic ops on matrices and scalars and have the compiler figure out the correct dispatch and return type depending on the type of the values. In Go I can't overload operators or do multiple dispatch.
- foldr 9y ago
  >The ecosystem is certainly still rapidly evolving and good documentation and libraries may not exist in all areas. Hmm, that's what people have been telling me since I first learned Haskell in 2002. Your brush this off as if it's a minor point ("some bad experiences with Haskell's libraries and tooling"), but libraries, tooling and compile times are a major, major influence on productivity. If you're at leisure to wait for decent libraries and tools to become available, then good for you! I was kind of hoping to get stuff done now, though. Abstractions have both positive and negative payoffs. Take MTL as an example. It certainly increases code reuse and makes code more concise. On the other hand, it's also partly responsible for Haskell having a gazillion different techniques for handling errors, with little community consensus on what the best techniques are (see e.g. https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_best_practices_in_haskell/ https://www.reddit.com/r/haskell/comments/5bkqf1/exceptions_...). I spend at least some time thinking about this stuff when I write Haskell code. I spend no time thinking about it when I write go code -- I just write the same error handling boilerplate that every go programmer uses. It's not pretty, and I don't get to pat myself on the back for understanding something complicated. But does it make me less productive? Not sure. Response to edits: I think you're misunderstanding my comment. I use these features and know what they are. I'm telling you that I do not see any clear productivity benefit from them in practice. Haskell advocates do have a maddening habit of assuming that anyone who criticises any aspect of the language must be a complete novice.