I think it's funny that you mention a bigger change but sum-types are 80% of what Go already has here. While it's true that it solves the ambiguity issue of rep

I think it's funny that you mention a bigger change but sum-types are 80% of what Go already has here. While it's true that it solves the ambiguity issue of representing `Either Result or an Error But Not Both` instead of the `Result or Error or Both`; that doesn't solve the issue that anyone actually has, which is that most errors are handled with if err != Nil { return err; } after every other line sometimes. It's verbose, manual, and doing the helpful thing like adding context for the error is repetitive and often omitted. As I've mentioned elsewhere, you essentially want an exception system. Some care still needs to be taken with how other language features interact with it. You'll probably want a sum-type-y way to catch exceptions as an expression eventually. What happens if exceptions are thrown from functions in defers, etc. But unlike more FP languages where error propagation is much easier in a soup of composed functions, Go is much more Java/C#-like. Most functions have much more important names and meaning which make stacktraces much more valuable.