Thank god, this guy[0] can finally cut over to native generics in his code.<p>[0]: <a href="https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/" rel="nofollow">https://www.reddit.com/r/rust/comments/5penft/parallelizing_...</a>
Very reasonable caveats for a feature as big as generics.<p>Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.
Related discussion from 10 days ago:<p><i>go: don't change the libraries in 1.18</i><p><a href="https://github.com/golang/go/issues/48918" rel="nofollow">https://github.com/golang/go/issues/48918</a><p><a href="https://news.ycombinator.com/item?id=28895440" rel="nofollow">https://news.ycombinator.com/item?id=28895440</a>
If you want to get a head start, gotip makes it easy to build and run go from the development tree:<p><a href="https://pkg.go.dev/golang.org/dl/gotip" rel="nofollow">https://pkg.go.dev/golang.org/dl/gotip</a>
Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0].<p>[0] <a href="https://github.com/nim-lang/Nim/issues/3502" rel="nofollow">https://github.com/nim-lang/Nim/issues/3502</a>
> Because we will not know what the best practices are for using generics,<p>Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go.<p>But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.
From the outside, it seems like adding generics to Go seems similarly controversial and slow as the Python jump to version 3 — although Go generics haven’t even landed yet.<p>Generics have the potential to impact a decent amount of the standard library. Although I’m not surprised that they are not doing a major version bump given the isolation of the feature at this stage, it will be interesting to observe its uptake in the community and whether fragmentation occurs over what is supported and what isn’t given their recommendation of isolating generics-related code in third party libraries.
> We expect that some package authors will be eager to adopt generics. If you are updating your package to use generics, please consider isolating the new generic API into its own file, build-tagged for Go 1.18 (//go:build go1.18), so that Go 1.17 users can keep building and using the non-generic parts.<p>I have a feeling this won't happen.