> It feels like you’re constantly fighting the language

I disagree. I feel like I constantly understand precisely what the language is and is not going to do. This is more valuable to me than languages with 100 sigils that all invoke some kind of "magic path" through my code.

> forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it

How do you universally handle an inventory error? The _path_ to and from the error is more important than the error or it's handling clauses.

> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.

Isn't the point of the above that no matter which you choose the code is mostly the same? How much of an impact is this to refactor when you change your mind? For me it's almost zero. That right there is why I use go.