I'd really appreciate if you stopped quoting me out of context. I never said sum types were the only alternative. The second sentence of my GP was "Responding t

I'd really appreciate if you stopped quoting me out of context. I never said sum types were the only alternative. The second sentence of my GP was "Responding to inaccuracies about Go does not imply I need to exhaustively describe all alternatives in order to be even-handed." I referenced sum types specifically because it is often what people suggest should have been included in the language. > The issue in Go is that ignoring errors is the simplest thing you can do. And not only that, not ignoring them is a significant step up in complexity and amount of code. I agree that error handling requires more code, but I disagree that it increases complexity. Most error handling cases I've ever written are just passing them up to the caller: if err != nil { return nil, err } That is not added complexity IMO---particularly since it is an extraordinarily strong idiom---so I suppose we are at an impasse.