I've seen this argument several times, and I'm not sure I understand it. The recommended workaround (empty interface and explicit unboxing) is, at runtime, pretty much how Java generics work: the parameter types get "erased", and the bytecode operates on Object (the closest equivalent to Go's empty interface) no matter what they are. But at compile time, the compiler infers the (obviously necessary) typecasts, so, you don't have to explicitly clutter up your source code with them. That strips away a layer of crud which obscures the underlying logic of the code, making it harder both to read and to write.
The other constant line from the Go implementers is something like "generics have proven troublesome in [unnamed] other languages, so we don't want them until we're sure we can get them right". This may be a reference to C++, in which compiling templates turns out to be a real pain. But at this point, the literature is full of better ways to do it.
The other constant line from the Go implementers is something like "generics have proven troublesome in [unnamed] other languages, so we don't want them until we're sure we can get them right". This may be a reference to C++, in which compiling templates turns out to be a real pain. But at this point, the literature is full of better ways to do it.