Hacker News Reader

Comment by cy_hauser | Hacker News Reader

Or, if history is a guide, there will be a few really nice generic libraries written and a sizable minority of developers will adopt them as pseudo standard to fill the void. Then the Go team will do what they want, fracture the community, and alienate those who expected your described path to be the one taken.

View on HN

I think they've been worse about this w.r.t. tooling (dep comes to mind. The closest thing I can think of along this path for the standard library would be how they've handled errors, and deciding to go their own way instead of adopting dave cheney's pkg/errors[0]

they do definitely seem to have some NIH syndrome at times, but I can't say that as time has progressed that I haven't come to appreciate the decisions they've made that seemed controversial at the time.

[0] https://github.com/pkg/errors

Wait, isn't Wrap and other pkg/errors proposals used in the current stdlib? I thought they officially accepted that package as the default errors package.

No, they didn't adopt pkg/errors into the stdlib. pkg/errors did get updated to work nicely with the changes that they did incorporate

https://pkg.go.dev/errors

Interesting, is there any discussion available to understand their decision?

I'm very glad they looked farther afield than pkg/errors as per https://news.ycombinator.com/item?id=28284119 .

I worked around that by adding a "dev" build tag that includes stack traces, and without for all other builds (as to differentiate between local and production environments).

Reply on news.ycombinator.com