from Hacker News

Go: Don't Change the Libraries in 1.18

by dbattaglia on 10/17/21, 10:41 AM with 122 comments

• by nine_k on 10/17/21, 11:22 AM

  A good call, and probably the most reasonable decision in their situation.

  OTOH this removes much of the point to use generics, and makes working with stdlib from type-parametric code more painful.

  Still great to see things improving. It took mere 11 years.

• by kubb on 10/17/21, 1:37 PM

  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.

• by dathinab on 10/17/21, 12:52 PM

  Hm, shouldn't they first update the (most important/interesting) libraries in a fork before stabilizing generics?

  I mean designing a feature in a clean room is one think, but using it a the standard library would be a good way to know if they messed up the design in some way.

• by cube2222 on 10/17/21, 11:43 AM

  Also think this is a good call.

  Though the second comment has merit too, I think it would be good to have some common abstraction right away, like we had io.Writer, io.Reader, etc. so everybody doesn't define their own, as it'll take time to crawl out of that.

  Although in practice it did work out well with error wrapping which was first in libraries and then the stdlib defined an interface for them, which resulted in all libraries adopting that.

  > Similarly, if constraints isn’t part of 1.18, there will be a lot of independent redefinitions of orderable types. I don’t think we’re going to learn from experience much that could change that package now.

• by 1_player on 10/17/21, 11:14 AM

  tl;dr: We're shipping generics in 1.18, it's a huge release so let's wait a little bit until they stabilise and they're used in production before changing our stdlib.

  Good call in my book, and I'm extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better!

  It's cool to hate on Go, it's taken over the system programming space for a reason, like it or not, and after working full time on Elixir it's hard not to think in map/reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the "if err != nil" statement to pile on the language — though to be fair I'll expect some ergonomic improvement on that aspect as well, eventually.

  With generics, Go will be my new Python, but with a decent dependency and deployment story, and I'll just need Zig for my low-level manual memory management needs. What's Rust?

  EDIT: indeed being a bit cheeky with HN's favourite language isn't well received in this place.

• by olingern on 10/17/21, 1:57 PM

  JavaScript/TypeScript changes so much that a codebase will look very different from one year to the next. JS/TS has come a long way and needed to make substantial change, but I appreciate the slow moving, methodical nature in which the Go team moves the language and environment forward.

• by crnkofe on 10/17/21, 2:07 PM

  I was really looking forward to getting some basic generic standard library funcs. Guess what I'm getting now is a a ton of std libraries each with a slightly different approach, slightly different bugs and update cycles which will nicely inflate the amount of tech debt in existing codebases.

  I guess from the standpoint of a language designer it makes life a bit easier not to do anything and just cherry pick the winners of the various generic attempts that the community will create but as an app. developer I find this disturbing. Also I question the rush to a release all of a sudden. Generics took years to come to fruition. Another year for a decent stdlib won't really hurt anyone and for those that really really want it they can enable it through build constraints.

• by nyanpasu64 on 10/17/21, 2:56 PM

  C++17 introduced std::optional and std::variant, but they're not used by the standard library in 2021, as far as I've seen (unlike Rust which is better off for using them). It feels quite like a missed opportunity to produce more ergonomic APIs (though the inability to produce an optional<T&> is limiting, and std::variant is inefficient at compile and possibly runtime and apparently can't be fixed because ABI). I'm not a Go user, but I dislike multiple competing approaches to problems without clear guidance or fully embracing newer approaches.