I agree with the feeling, but I also see this being a debate between an opt-in approach (choose to use an error value with gradually more information enclosed) vs opt-out (throw an Exception, a la C#/Java, that by default stores everything you may or may not need, then maybe figure out a way to stop storing what you don't need). The use cases are not going to magically go away though, which explains why we need the solution to be somewhere in the middle.
> then maybe figure out a way to stop storing what you don't need
I'm not sure I understand why this is something you need to do. "Figure out a way to stop storing what you don't need." Who cares if you don't need it, or at least don't need it now, storage is cheap.
Exactly. Plus, code that uses exceptions but does not encounter any throws should be faster than code that uses error checks. In the latter, there's always a cost even if there aren't any errors returned. However, the former can optimize for the (hopefully more common path) of no exceptions being thrown and avoid checks altogether.
Source: I worked for Microsoft on C# projects where GC was constantly the bottleneck. Reducing number of exceptions (especially those used for control flow) helped.
Weirdly enough this perspective might suggest that the problem is not actually with Go, but with object oriented programming. Which wasn't considered thoroughly by original authors, because they were not OO programmers.
No other paradigm appears to be able to handle the complexity required to build the systems of today. Objects are very natural way to organize complexity. It's what let UNIX succeed where Multics failed.
