I understand that Go gets compiled to one binary, but still, if some library I’m depending on adds an error code and I don’t notice it, I’ll simply never see it, and there’s no obvious way to tell in auditing the code either.

I’m a very cautious programmer, so I already spend probably 15% of my programmer’s life on error handling. With Go, I would spend far more.

Nearly all my error handling is very close to the top of my code — because that’s where I can handle it best for my user. But nearly all my errors are generated close to the bottom of my code, because it’s at the bottom I discover that the file is missing or malformed or the URL is unreachable.

In Go, that means just a huge amount of “is this an error code? then return it” over and over and over. Every single Go codebase is full of this stuff, something you never see in any other language.

It helps the reader not at all in understanding what’s going on. It’s semantic cruft for no value.

Worse, when reviewing the code, it’s an extra step — you have to look at each statement that doesn’t check for an error code and say, “Can I get away without an error code?”

And if you fail — if neither you nor your reviewer notice that you’ve missed an error code — then there’s no way to catch it. That error will simply go unnoticed, and it might be years before you realize.

Here’s an article by a Go programmer that has specific details.

Your argument seems to be this: “It’s really easy to make invisible mistakes when doing error handling in Go, so that makes you try harder, so your program is better.”

Sounds like Stockholm Syndrome to me! :-)