Go errors are actually less useful in this case since they do not capture backtraces by default (if I remember well), and invite gratuitous re-wrapping. Most times I had to troubleshoot something it was useful to know the lowest level where the error happened, not the arbitrary level the application/library author decided to be appropriate and missed.
Agreed, there are tradeoffs, but at least Go’s approach has more potential—there’s nothing stopping Go from capturing stack traces and returning them on the error object. On the other hand, exceptions always have the confusing control flow problem.
