In Go, you're not returning a sum type, so it's down to the programmer to remember that the "real" return value is likely toxic waste when its copassenger the error return value is non-nil.
What's the practical problem of this, though? The (varname, err := thing) pattern is sprinkled all throughout the language, enough to where it should be instinctive for a coder to check the err value when doing anything that could fail.
Of course we can put up with anything. The topic of the subthread is that it's halfassed and has a better alternative.
A major hit to readability. Every call site where you want to check for an error requires adding another level of nesting.
That's a different issue. Pattern-matching a sum-type value, though safer, would be "noise" too.
Correct me if I'm wrong, but I believe with sum types you can chain together multiple calls then pattern match once at the end. In Go you have to check at each call.
If you have an unusual amount of error handling cluttering up your code in Go, then you can use `panic` (with `defer` and `recover` to convert panics to errors in the public interface).
I've been programming without if statements. It feels a lot better using pattern matching instead of if statements.
Wait, that's it? The difference between bad (with italics!) and awesome is being able to reference the garbage half of a multiple return?
I'm not the GP. Ask them for their full story.
You can embed metadata with sum types on a return object. You can then use the metadata programmatically to increase correctness, enhance readability, and reduce boilerplate. This blog post goes into more details:
> You're not returning a sum type so it's down to convention to remember that the "real" return value is effectively garbage when the error return value is non-nil.