definitely disagree with the 'Concise Error Handling section', at least without a lot of enhancements to errors first. yea, there's a lot of error handling cod

definitely disagree with the 'Concise Error Handling section', at least without a lot of enhancements to errors first. yea, there's a lot of error handling code in Go, but a lot of the time its not just "if err != nil return err". errors are a simple interface type with an 'Error() string' function. This is NOT ENOUGH METADATA for real usable errors a lot of the time. Lots of codebases are littered with stuff like 'if err != nil return errors.WithStack(err)' simply to attach a stack-trace to an error coming from an external dependency. Sure, the enhancement proposed in the article doesn't preclude you from continuing to do that, but it doesn't solve the actual shortcomings of errors either in my opinion. Errors in golang != exceptions common in other languages, I get that, but that doesn't mean I want to have to remember to attach standard metadata to every possible place an error bubbles up in my application. It's a consistency and simplicity problem too since some places you can just bubble an error up transparently, and sometimes you've got to wrap it with metadata for reasons that aren't obvious just by looking at the immediate error handling code. Thats a problem.