That's only one way to handle an error. The benefit is that it's explicit, not implicit, and it's a psychological nudge to ask yourself "oh yeah this could pro

That's only one way to handle an error. The benefit is that it's explicit, not implicit, and it's a psychological nudge to ask yourself "oh yeah this could produce an error, how should I handle it?". I can scan code and see where all the errors occur and how that particular component intends for each to be handled. And handling errors in concurrent code is consistent--still passed as values. Languages with implicit stack-unwinding exceptions have inconsistent ways to deal with the errors because, in concurrent programs, error handling doesn't end once the stack is unwound, because there are lots of concurrent stacks. You then usually catch the exception near the top of the stack and pass it to another stack...as a value. So yes, there is some boilerplate involved in that. But as a codebase grows, I appreciate that the language encourages me and others to be intentional about how errors are handled, and also provides a consistent mechanism for handling them in concurrent code (concurrency is a big reason I use Go to begin with).