Among the first things that once drove me to try Go was a video by Rob Pike, called "Simplicity is Complicated." In it, he describes at length that one of Go's unique differentiating features is its core team's obstinance to conform to community pressure and adding new features.
A couple of days ago, in a similar fashion, Pike proposed that the core team splits the release of type parameters (area. generics) and the overhaul of the standard library.
In his view, releasing both the feature and the supporting primitives to back it up is simply too much commitment for the core team.
I agree; it’s a lot of work. Much of the Go developer community on Twitter did so too. And yet, I’m a tiny bit skeptical about this decision. In my view, the only way to prevent people from shooting themselves in the foot with generics is by providing a solid base that they can use right away.
I’m sure there’s a lot of pressure to deliver everything right now, but getting the feature out without good standard library support to back it up will lead to a hundred different libraries getting released overnight. That’s a hundred dependencies that will need to get cleaned off of people’s code later on (if ever).
Same as with goroutines and channels, I believe that the best place of generics is in the standard library. If the team doesn’t come up with a solid set of primitives at the start, every “expert” out there will start selling their vision of how those should be used everywhere, the way they did with channels and goroutines a few years ago.
If that’s the state of things, I’d much rather have generics get released 1.8 with a safeguard command option that would at least discourage people from using it in production code (yet).