Quick searches turn up slow compile times as a definite issue with generics. Which means papsosouid's premise is wrong: there IS an issue, and it's one of the ones the Go team considers important. EDIT: read name wrong.
It has been claimed by the D people that D compiles faster than Go. D has a very powerful generic/template system -- even more powerful than C++. Yet, they seem to have solved the compile speed problem, while preserving runtime types (it is a systems language after all).
As I mentioned in another comment in this thread, I have a feeling that the issue with generics in Go is how some language features interact with each other (and not in a good way). Mainly interfaces and object composition. I think this is a good indication that the authors were not aware of several developments in language design at the time of making Go. Not everything is a tradeoff all the time. Certain problems have been solved.
>Quick searches turn up slow compile times as a definite issue with generics
Where? I can find nothing of the sort. And given that we have proof otherwise (compare D to go for example) it seems likely that you are choosing to interpret "some languages made their compilers slower" with "parametric polymorphism must make a compiler slower".
As I mentioned in another comment in this thread, I have a feeling that the issue with generics in Go is how some language features interact with each other (and not in a good way). Mainly interfaces and object composition. I think this is a good indication that the authors were not aware of several developments in language design at the time of making Go. Not everything is a tradeoff all the time. Certain problems have been solved.