[tavoe]

This article seems to break down into 3 parts - why multiple return values are bad, why go error handling is bad, and opinions about what to do about it.

The part that feels wrong to me is their issue with multiple return values. They argue that multiple return values are a special case in the type system, so they don't compose well. But, as far as I can figure, function arguments are also a special case, in the exact same way. I think if the author wants to argue go should only have one return value, then use tuple destructuring to simulate multiple return values, they should also argue functions should only take one argument, and use tuple destructuring to break it apart within the function.

I don't think having a special case for either the input or output of a function is particularly weird, and I can't think of any language (except haskell?) that limits you to one argument.

I don't know. I don't think they're particularly wrong about multiple return types being ugly, but it also doesn't feel like some great tragedy to me the way it does to the author.

[debugnik]

> they should also argue functions should only take one argument, and use tuple destructuring to break it apart within the function

You say that as an hypothetical, but that's exactly how code is written in Standard ML; and the rest of the ML language family supports it to some degree, although they lean more on currying, like Haskell.