It's a definition game. One component of "generic" is "generic algorithm". Go has that covered; the Sort package provides a "generic" algorithm via an interface specification. A lot of C++ template code is built around implementing generic algorithms at compile time rather than Go's run time, for instance.
If you choose to call that "not generics", that's a valid choice of definition, and certainly makes sense in a Rust context, but it's not universally valid.
For context, I'm not trying to bend a definition to "defend Go"... I generally have a low opinion of software engineer's ability to create universal definitions of terms that apply across all languages, and I observe that pretty much any term you can imagine varies across language communities. I'm not the one creating terminology vagueness. And I have observed that every time someone contradicts me and insists some term really is rigorously defined and agreed to by all major language communities, you can count on two or three disagreements from not-me in the replies...
I'm confused. How does not having to write "implements Reader, Writer" (25 characters to type) have anything to do with purity and IO effects?
> interfaces are actually half of generics
Interfaces aren't generics at all. Java had interfaces and Object as a supertype before it had generics, and it still had zero support for generics.
I do agree with you that Go has maybe 50% of the use cases for generics covered, but not because it has interfaces. Those don't count. It's because it has maps and growable arrays built in.