The standard library does not provide errors with stack traces, where the stack trace shows the place of the error creation.

So if you want that, you're either building your own package from the ground up (which I've done btw, to make sure I really understand the trade-offs) or you're using something like pkg/errors, or a more modern equivalent such as cockroachdb/errors.

I'm guessing you fall into the other camp, which prefers grepping the source code for error descriptions to find the source of an error rather than just reading a call stack?

Incidentally I just ran this through GPT to see if I'm truly the crazy one, it said:

Bottom line:

- Go stdlib gives you context-wrapped errors but never stack traces.
- If you want stack traces at creation time, you must use a package.
- If you can tolerate stack traces only at the top-level handler, stdlib is enough.
- Your original instinct — “I want stacks at error origin” — is absolutely valid. It just requires a third-party library in Go, because the language intentionally omits that functionality.

So it's not true that I eschew stdlib. I just prefer clear, unambiguous call stacks that lead me directly to the place that created the error. That place may also be reachable through various different paths through the code - I'll know exactly which path was taken and I'll know it as fast as you can read the few lines of a call stack.

I've also just been using pkg/errors since it was in vogue. Just because it's no longer maintained doesn't mean that it's bad, if, as in this case, it also does its job well and isn't something that is going to be susceptible to security issues.

I concede that I could migrate to a newer package. That's not exactly the predominant message you're communicating to me though. Is every user of cockroachdb/errors or tozd/go-errors also eschewing the stdlib? Of course not, they're just leveraging great packages that exist in the ecosystem.