2. Re zero value: If pointers were by default not nullable, then the zero value of a struct containing pointers would have to recursively allocate objects to fi

2. Re zero value: If pointers were by default not nullable, then the zero value of a struct containing pointers would have to recursively allocate objects to fill those pointers. That's a deal-breaker for the notion of zero values. 3. Null values are almost always what result, as opposed to undefined or incorrect values. So it's a product type that is effectively a sum type. As for code smells: actually, there is a greppable equivalent in Go, and it is "... , _ := ... ". Future Go compilers might allow for a flag that treats "error" types specially in this regard. Interesting to hear about fromJust, didn't know about it. My own experience is that unchecked errors aren't where Go's 'debugging load' lies. The load is often in reasoning about concurrence, causal dependancies, and state machines. 4. If you're saying that because pattern matching isn't a core feature of Go, you wouldn't use it for everyday code, you're right. I'm a fan of pattern matching, I use it in Mathematica all the time (albiet unchecked). But my point stands: you can build sum types through interfaces, and when that makes a design significantly cleaner, a decent Go programmer will use it. 5. "Type systems don't become cages": well, a lot of people will disagree with you there. Ask C++ programmers about const. Ask Java programmers about checked exceptions. Ask Haskell programmers about logging. So I guess that's just, like, your opinion, man. :) 5.1. Go may not offer you as rich type verification as Haskell, but it does things Haskell can't: it can detect race conditions, for example, in concurrent code [I shudder to think how you even write concurrent code in Haskell]. Another closing thought: you focus a lot on Haskell. Haskell seems to be a very fecund place to devise type-theoretic patterns and techniques. And it seems to have taken the niche of "programming-language research testbed", which also results in a lot of interesting ideas. But there isn't nearly as much evidence that it is a smart choice for production code. I've been impressed by what I've seen, read, and understood about Haskell. Still, I have an unshakable impression that a lot of the quality that is associated with Haskell code is explained better by the hypothesis that the bar for writing Haskell code is very high: bad programmers can't write Haskell programs that do the things they want to do, so we see a lot of nice Haskell code and little bad Haskell code because of the base competency of the audience. But that doesn't imply that an experienced programmer would write higher quality code in Haskell than in Clojure or Go. We all have a complexity budget to spend on using tools to their full potential and doing things a certain 'proper' way. Simple languages leave more of that budget to spend on your program itself. Type-heavy languages leave less, with the promise that the cost is amortized. Calling Go a "sad language" and implying its authors are incompetent because you don't agree with their particular choice of budget demonstrates, to me, a certain arrogance and lack of imagination.