4 ms·
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
by chrsig 5y ago
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 https://github.com/pkg/errors
- SPascareli13 5y agoWait, 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.
- chrsig 5y agoNo, 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 https://pkg.go.dev/errors
- SPascareli13 5y agoInteresting, is there any discussion available to understand their decision?
- mappu 5y agoI'm very glad they looked farther afield than pkg/errors as per https://news.ycombinator.com/item?id=28284119 https://news.ycombinator.com/item?id=28284119 .
- mariusor 5y agoI 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).