Polyglot developer with an obsession for modularity
Error values in Go seem simple at first, but the interface driven approach makes it possible to express detailed information about failure, allowing errors to be handled much more gracefully than the naive approach (e.g. sprinkling fmt.Errorf or errors.New)
Usually when teaching about Go and errors, I refer mentees to Dave Cheney's advice, as I have very little to add on top of it.
How to check error values the Go way, by relying on interfaces
A neat trick for defining comparable error constants in your package (also works nicely numerical error codes)
Very comprehensive post that expands on "Inspecting Errors", discussing composition of errors via wrapping, how they affect public APIs, and general advice about how to handle errors
Detailed explanation of how his errors package wraps errors to include stack traces, something that can be very handy for programmer errors (see next link)
Though this Joyent article is about node.js, most of the concepts and advice are universally applicable, and in particular the distinction drawn between programmer errors, operational errors, and the different kinds of operational errors is insightful and relates.
Provided mainly for reference, this post by Andrew Gerrand reviews the basics of error handling and hints at the possibilities that Dave explores much more extensively.