In Go, errors are just values, and `error` is just an interface. If some data (e.g. stack traces) is helpful to you then make it part of your error implementati

In Go, errors are just values, and `error` is just an interface. If some data (e.g. stack traces) is helpful to you then make it part of your error implementation. I'm not entirely opposed to Dave Cheney's errors package but in general I think it's trying to be too clever and novel. If anybody wants to unwrap the errors you return, they have to basically buy into that package and its ecosystem. It's strongly coupled to itself, and that's a bad design choice IMO. We've been fine-tuning error logging and handling for decades. We ought not reinvent the wheel solely because new language constructs are available. My opinion is that structured data and not "errors with behaviors" wins every time, especially when you're building distributed systems and you are going to need to slice/dice your logs when you investigate problems.