[oefrha]

It’s archived mainly because it’s been superseded by fmt.Errorf() with the %w directive. Go 1.20 also introduced errors.Join() and multi-%w which github.com/pkg/errors lack, so using for green field projects is very ill-advised.

[Groxx]

Except for the stack trace part, which is a gigantic reason why it was popular.

tbh I'm not sure what the current popular option is for wrapping with stack traces.

Re join: it isn't a joiner-error, it has no need to do anything for that. Just stdlib-join-then-wrap.

[oefrha]

It’s pretty easy to write your own Errorf() wrapper or some sort of WithStack() that stores runtime/debug.Stack() output. github.com/pkg/errors offers more flexibility in formatting though.

[Groxx]

Well, sure, but by that metric this library is even easier to build yourself since it's only gathering a single stack entry per wrap. And it has no backwards compatibility to worry about.

"You can build X by hand too" has little to do with why people choose to create or use libraries.

[healsdata]

> "You can build X by hand too" has little to do with why people choose to create or use libraries.

In my experience, "you can build X by hand" is the Go community's preferred approach.

[tubthumper8]

It's been said that "Go" stands for "Go implement it yourself"

[arp242]

My implementation is about 120 lines, plus about 100 lines of tests. It's not hard, but not trivial either. Doing that for every single project is rather tedious. Especially for prototyping I just quickly want something that 'just works' without fuss.

[pstuart]

It would be great if the internals added %W as an option that would also include the relevant trace. Shouldn't be unreasonable or impossible.