> If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that

> If you follow the history of that particular issue, you'll see that the Go team's (official) view has always been that there are tradeoffs involved, and that none of the existing proposals for implementing generics are sufficient improvements over the status quo They should have thought about it at the very beginning of Go design. it's easy to say now "We didn't find a good way to implement generics" when their design choices made implementing generics insanely hard at first place. Well actually,they thought about it, where does append,delete,make and co come from? how do these functions know their arguments and return types at compile time? generics. Furthermore it's not all or nothing. Go could have supported parametric functions in user land just like append,make or delete without implementing full-on generics. They just don't want to bother with that, because it's impossible to retrofit generics now without breaking the reflect package. The rest is just excuses to evade the issue. > Generics are not free Creating a modern statically typed language WITHOUT generics isn't free either. Just like implicit interfaces are not free, just like the reflect package is not free, just like using interface{} somewhere isn't free, just like telling people to use code generators isn't free.