> Treating errors as opaque and passing them up the stack in the general case...
...is directly contradictory to one of the most fundamental assertions of the language, which is that errors are values -- https://go.dev/blog/errors-are-values -- and therefore "can [and should] be programmed".
The reality is that the vast majority of error handling in go is to do one of two things
1) pass it up the stack
2) wrap it and pass it up the stack
The fact that you must do this explicitly in all cases is a failure of the language. Many people have pointed this out, but the go team and elite members in the community are very dedicated to the myth that every error is precious and special and must be handled in a one-off manner.
"This article" is an explanation of a property of the language, written by one of its authors. It's not a position piece, it's just an additional bit of documentation.
I mean, your position is totally valid, no argument. But it's definitely not some kind of objective fact (I certainly don't agree). And it's essentially an objection to fundamental properties of the language as it exists. Whether or not those properties represent a failure of the language is a question for the philosophers, but regardless, your code needs to respond to things as they are, not as you wish they were :)
...is directly contradictory to one of the most fundamental assertions of the language, which is that errors are values -- https://go.dev/blog/errors-are-values -- and therefore "can [and should] be programmed".