Isn't Go's error handling basically just a procedural version of Either? It's a tuple instead of a sum type and the Left and Right cases are flipped, but otherwise I thought the entire point was that you're dealing with values that you only need to worry about at access time.
Sure, it's not a proper functor, but for a procedurally-driven language design, I would think that the current design makes more sense for debugging.
There's a major downside to the multi-value returns compared to sum types: They can't be chained. You have to assign the two result values to two separate variables:
s, err := readFile()
There's no way to build something like this:
readFile().then(func(s string) { ... })
Well, you can build it by having readFile() return some object with a then(), but without generics you can't build anything remotely ergonomic here.
(Actually, Go has an interesting quirk where multi-value return values can be passed as arguments to a function, so this is allowed:
Unfortunately, there's no way to build a generic chaining mechanism with this, since you'd have to have a handleErrors() for every possible return type combination.)
Sure, it's not a proper functor, but for a procedurally-driven language design, I would think that the current design makes more sense for debugging.