That's fine, you won't have to use them, or even use code that depends on generics.
And I won't have to remember a dozens of silly slice tricks each time I have to implement complex data pipelines with different struct types.
https://github.com/golang/go/wiki/SliceTricks
Everybody is happy.
No because C++ still requires some amount of manual memory management, unlike the rest of languages you listed.
I'm not sure how the generics implementation in Swift has any bearing on how generics will work in Go.
No, it's just people complaining about generics for the sake of it at that point.
* Camp 1: generics will always be horrible, Go is right not to include it, it's too complex, Go is meant to be simple, etc.
* Camp 2: I will never use Go because it doesn't have generics, serious languages have generics, etc.
When in reality, both camps are pretty much wrong. Yes, generics are useful in a lot of places. But they also add no value in a lot of places. It's really on you to pick the tool you want to use. If you really want generics, pick C++ or Java instead. If you couldn't care less, Go is an option. It's much more fluid than this binarization of the topic has made it out to be.
I didn't take the time to really read the spec for go generics, but i really hope the gray beards didn't compromise on letting developers shoot themselves in the foot with overly complex design.
Nowaday i would recommend every developer to go through a 3-month coding session with go, solving real problem, to really appreciate how much one can do with just basic tools and an elegant design (with a few diving session in the stdlib codebase, which is just a pure gem).
This is by far the most important aspect of the language.