As many comments point out, he neglects the .NET approach to generics, which avoids most of the drawbacks of C++'s approach and Java's.
At compile, there's one version of a generic method (say List<T>.Add). Compilation isn't slowed down like in C++.
At runtime, a generic method is compiled (on demand) into unique versions for each T encountered if T is a ValueType (int, double, etc. including user defined ValueTypes). This avoids boxing, like in Java.
Also at runtime, for all T's that are reference types a single common version is used with implicit casting as in Java.
C#'s draw back is that there is a small cost incurred on the first use of a generic method, and then an additional cost for each new ValueType used (if any). In practice this doesn't ever seem to be an issue, but it's there.
See http://stackoverflow.com/q/5342345/80572 and http://www.artima.com/intv/generics.html (which is linked from the former).
C# on CLR is a VM approach, whereas Go compiles to native code. Concepts that are easy in the first (e.g. runtime code generation) often don't map particularly nicely to the second.
I suppose debugging could go sideways in theory, but it doesn't happen in practice on .NET and I doubt the go team couldn't figure out how to make it work.
It's worth noting that .NET never interprets bytecode, it always converts a method into machine code before execution. Go has already had dynamic code generation as part of it's implementation (I don't know if it's still around in 1.2), so it's hardly like it can't do the same thing .NET is.
For .NET proper, new machine code is generated at runtime. I believe (but do not know for sure, offhand) that it basically takes the IL definition of the generic method, slots the now known type into it, and JITs it to get the machine code it needs. I do know that there are couple bits of IL that are meant to make it possible to write the same code to deal with both reference and value types, which is probably related.
Ngen (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...) let's you transforms assemblies into machine code up front, while still being .NET proper. However, if it can't find a use of generics with concrete types found at runtime (ie. you generate a List<int> via reflection) you'll still load up and use the JIT (see some discussion here: http://stackoverflow.com/q/16647568/80572).
I don't use AOT or Ngen regularly, so the particulars may be a little off in my explanations. But that's the gist of it.