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.
> 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:
That is not added complexity IMO---particularly since it is an extraordinarily strong idiom---so I suppose we are at an impasse.