I'm not arguing against generics at all (I wish Go had it), but I'm also not sympathizing with this response.
For practical issues you have things like compile time, extra tool dependencies and up front setup time to enable a given type.
It makes c++ templates look down right elegant in comparison.
Go missing generics except for built-in containers; and then not having anything but the bare minimum for those built-ins is a critical defect of the language. The fact that you can work around that defect doesn't make it any less of a defect.
It means it's a hackish kludge that's only a solution for the non-discerning programmer.
Not everything that takes care of a problem is a proper solution.
Let's make an analogy. Suppose a language didn't have tail recursion, but by using goto you could "roll your own." So we're on the same page, right? you get what I'm saying, and how rolling your own might look and work, right?
Now suppose I said that without goto, it is literally impossible to roll your own tail recursion. (ignore whether this is true it's just an analogy.) You are saying, no it's not: you can patch the generated executable, so as long as it is possible to patch executables using go (i.e. if it can read and write binary files), then you can roll your own tail recursion even without goto, through binary patching post compilation. It might just be tedious or special-cased to one specific file but you can do it (you're saying)
See the difference? It's not that patching an executable is "cheating." It's just that it's outside of the definition of rolling your own tail recursion.
Likewise it's not that source code generation is "cheating." It's just outside the definition of rolling your own container. it's simply not what rolling your own means. after you've done it, you don't have a container.
my analogy is a bit leaky but I think it gives insight, and I hope you see what I mean.
For example, you could write a Vec<T> and instantiate it for Vec<string>, which is fine, but then a different package may want to declare func sort<T>(values Vec<T>). Maybe one is an app and the other is a library. How do you now fit the two together? If the tool is smart enough and both of them are generated at the same time using the same tool and module files, it might work, but I don't think there's anything like this for Go right now, and either way, you have the "same tool" problem.