I agree that adding error checking at every possible error location and then passing up those errors is tedious, but it is a direct result of Golang essentially

I agree that adding error checking at every possible error location and then passing up those errors is tedious, but it is a direct result of Golang essentially being a "modern C". In the case you describe it sounds like it was particularly painful due to the multi-threaded nature of the software. You didn't call it out directly but I feel like the inability of Golang to do polymorphism makes it more difficult. If the result of something is simply a message, and that message can be either a normal data type or an error, then you don't need to always additionally return an optional error. This is why I prefer the idea of message passing languages over direct procedural languages. It is still possible to do this somewhat in Golang using channels and/or queues, channels can tend to get clogged and freeze up in my experience. I've had good experiences using Mangos ( Golang nanomsg implementation ). If you use inproc queues, you can do multi-threading in a language portable way. Then, if you decide to replace a processing component with something other than Golang, it is relatively easy to do so.