Hacker News Reader

Comment by kubb | Hacker News Reader

What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess.

I'm excited about the prospect of having iterators. It will enable a different, more consistent programming style.

I'm also hoping for immutable collections, even though the lack of specialization will make it more difficult to implement them efficiently. They would enable a more robust way to build concurrent systems.

View on HN

> What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess.

Most likely yes, or as stated in the ticket, they'll take the existing proposal and implement it in golang.org/x/, where they've had some success fleshing out the design of new packages before incorporating into the standard library. It's worked out well, as early adopters can adopt and generally have a painless transition once included in the standard library.

I agree with iterators and immutable collections -- it's been painful working with trees in go, so hopefully that gets a bit easier now.

Honestly, I'm excited to see what will come of generic functions for channels. Being able to write a generic Dup(in chan T, out ...chan T), or a CtxRecv(context.Context, chan T) (T, error) to cut down on some boilerplate select statement.

+1 for channels, a simple task like duplicating a channel is surprisingly tricky, verbose and error prone

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.

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).

> What will likely happen is that the users will design generic libraries themselves

the Go team has already made the libraries, theyre just publishing them in the /x/ namespace instead of the stdlib.

/x/ has everything that's not under the Go compatibility promise, among other things from the Go project.

Reply on news.ycombinator.com