Although ultimately I do want generics in Go I am afraid they will make the language more difficult to use and understand. Generics in c++, c#, scala, java, etc all tend toward being very complex and change the way programs are written.
The focus moves towards a taxonomy of types and developers (myself included) sometimes get stuck on difficult type problems. There's something about trying to preserve type safety which sets the bar extremely high for bypassing the type system when there's not an easy solution and before you know it you've wasted 2 or 3 days writing code which doesn't actually do anything but placate the compiler.
And often that type-safe concoction you create is almost indecipherable when you come back to it later.
For example here's a project I worked on recently which cached a concrete version of a generated method using generics:
https://github.com/DataDog/dd-trace-dotnet/blob/develop/src/...
Used like this:
var originalMethod = DynamicMethodBuilder>
.GetOrCreateMethodCallDelegate(
redisNativeClient.GetType(),
"SendReceive",
methodGenericArguments: new[] { typeof(T) });
At least for me that was really hard to figure out how to do and I still have to squint to see what the heck its doing. The non-generic version wasn't type-safe and it wasn't as fast, but it sure was a lot easier to read and understand.
And to give some sense of the complexity involved, Rob Pike mentioned in his talk that the proposal spec for adding generics to Go is longer than the spec for the entire language.
I think the complexity is worth it, but I just hope we can be cautious about how and where generics get used in real-world code, otherwise we'll end up with gobbledy-gook that only experts can decipher... and that would be really sad, because the promise of Go was a language normal engineers could be productive with.