2. Why does the struct need a zero value? If it does, why not wrap it in an option/Maybe? 3. So that means you might get both a success and error value at the

2. Why does the struct need a zero value? If it does, why not wrap it in an option/Maybe? 3. So that means you might get both a success and error value at the same time? And ignore one of them? As for concurrent problems being worse than nullability, that sounds very plausible -- as Go also messed up concurrency by making any guarantee about immutability of shared state impossible. 4. That means the threshold for using sum types is pretty high -- which means you end up not using them when you ought to (e.g: error products rather than sums). Sum types would make error handling significantly cleaner, but are not used that way in Go. 5. I think C++ programmers rather like const. Maybe you are confused with C programmers? C just got const all wrong. Java got checked exceptions wrong, too. Haskell logging is not a serious problem in my experience. Debug logging is done the same impure way as in other languages. Production logging is easy to add as a feature to your monad stack. Some bad type systems become cages -- and then people hate all type systems. Ironically, Go also has a type system, and since it is a rather poor one, it is a cage as well. 5.1: I'm sorry but this point of yours shows rather extreme ignorance about Haskell. Haskell can statically prevent race conditions. The facilities for writing concurrent code in Haskell are far more advanced than those of Go. > But there isn't nearly as much evidence that it is a smart choice for production code. I use a bunch of languages for production code, including Haskell. In my experience, Haskell is the best choice for production code of most kinds. There is likely a selection bias in Haskell. That isn't why Haskell code tends to be good. As an example of a measure of quality: Haskell makes it easy to verify there are no runtime crashes in your program. Even excellent programmers will not be able to make that guarantee in Python, Java or Go. This is a pretty huge thing -- having a guarantee of no runtime crashes. The same Haskellers who can give this guarantee for Haskell code would have no hope of giving this guarantee in these other languages. I'm not talking about a big "try: except:" clause -- but about a compiler exhaustiveness check that verifies all functions are total, and a cursory check that all recursions are well-founded.