C++ doesn't have generics. It has templates, which is essentially a macro system—there is no type checking, and a new instance of the code is generated at the source/AST level for every combination of template parameters. If that is your only experience with "generics" then it's no wonder that you have a negative opinion of them, but that is no reason to oppose the implementation of proper generics in other languages. Java has true generics with interfaces and such but they were retrofitted into a language with a less expressive type system, so there are gaps in the implementation. A better example would be traits in Rust, or typeclasses in Haskell.
This is going to sound a bit like "no true generics" but if you think of C++ templates as macros less so than generics you might be more open to seeing how other languages do it in a way that encourages better engineering.
Generics, I would certainly be ecstatic for if it was done in a way that is novel and feels Go-like, so not Java or C# or C++'s implementations. This has certainly been the stance of the Go team since the beginning of time. It has never been "anti-generics" it's always been "we've studied all the generics implementations out there, and didn't feel like any one of them were good enough, so rather than shoehorn them in, we are being patient." This approach needs to be celebrated more.
Exceptions, OTOH, I hope never see the light of day in Go. Curse them.
What's wrong with the way that Java, C# a, and C++ handle generics? I see this complaint fairly regularly, but I was never sure why. Is it how the compiler handles it, or how the language defines it that is the reason for this dislike? Genuine curiosity.
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.
I agree 100%. I've used them both in C++. I hope Go never gets them.