[alharith]

This is the lazy answer I know, but I wanted to at least answer your genuine curiosity: There is ample research available online on the subject that explains it in depth and far better than I ever could. However, I will leave you with a few quotes that help at least paint the picture.

From the Golang FAQ:

> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven’t yet found a design that gives value proportionate to the complexity

Quote from Russ Cox:

> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

Finally, one of the reasons the C++ or Java approach has never been palatable to Go core devs is summarized from this Rob Pike quote from his famous "Less is Exponentially More" blog post:

> If C++ and Java are about type hierarchies and the taxonomy of types, Go is about composition

So therefore it really is also a matter of finding a generics approach that lives up to that spirit as well. Contracts I think are approaching that.

All that said, user defined generics (since technically speaking, Go has many generic capabilities today already) are coming to Go, they just aren't being rushed. I think we will be happy with the generics implementation in Go within the next year.