I feel this way when writing business logic RPC services, because returning the error to the caller is almost always what you want to do. Recently I wrote some

I feel this way when writing business logic RPC services, because returning the error to the caller is almost always what you want to do. Recently I wrote something very different, more low level. Rather than handlers it had a number of goroutines looping, selecting, and sending to channels. In this case explicit errors were a lot more useful. If it had been a language with exceptions and I had forgotten a try/catch, it could have killed one of my loops. Not good! This is the kind of use case that fits well for Go. I think it’s a systems glue language that just happens to be friendly enough to invite abuse in mundane backend business logic tasks. But using it that way is setting yourself up for frustration.