Not the OP, but here are my 2ยข. Introducing generics in a language implies a deep revision of the type system, which risks to become much more complex to understand. Moreover, this might have a bad impact on compilation performance (compare C++ compilation times with Go compilation times and you'll understand what I mean).
It sounds like you're saying Java's generics are somehow superior to C++ templates.
For those who don't know, C++ generates a separate instance of the code for each type which means that it can operate directly on a value instead of through a reference/pointer and it also makes it possible for the compiler to inline the type-specific code in many cases. Ie., it has the potential to be much more efficient. That is why it works the way it does. The downside is that the code generation slows down compile times, as you noted.
Java simply casts a reference to an instance of Object to the type on behalf of the user. So you effectively have generic code the way it's done in C (void*) and Go (interface{}) but without the explicit casts.
Maybe the JIT offsets many of these inefficiencies but making that comparison is beyond me. I only bring this up because you made it sound like Java got generics completely right and C++ got it all wrong, and with the amount of flak C++ gets these days I think it deserves a little help now and then.
I didn't intend it to come across like that. C++ is how you have to do aggressive type specialisations and optimisations in the absence of a JITC. Java's JITC is able to do many of the same things at runtime as C++ does at compile time, but it's less predictable.
I was not referring to templates only, but to the overall complexity of the C++ language. Examples: syntactic ambiguities, the preprocessor... Templates are a big part of the problem, but not the only one for sure. Languages like Free Pascal have outstanding compilation times because they privileged language simplicity, and IMHO Go falls in the same ballpark.
To be clear I prefer generics. The cases for why other Go developers don't want generics seem to mostly fall on "it will change the language / encourage people to write stupidly complex code" to "it's too hard to implement". The first one is valid--Go's constraints give it this nice property that there is (more or less) one obvious way to write most programs, and that will go away with generics; however, I think that cost is worth the gain. The other criticism seems like a cop-out; the Go team has far and away more than enough talent to slap generics onto the language.
Not OP, and this is only one aspect to consider, but it's from experience - when generics were added to C# the language became nicer to use, but it caused a lot of churn and added complexity. The base libraries have the original non-generic classes as well as newer generic ones.
As I've written above, there's huge potential to be the language that doesn't churn, when just about everything else does these days.