3 ms·
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
by cy_hauser 5y ago
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.
- chrsig 5y agoI 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).