I'd say either resort to code generation or pick another language that fits better your use-case.
It's perfectly fine for Go's answer to be, "Go doesn't have generics because generics aren't needed to solve the kinds of problems Go is designed for solving, and we are not trying to be a kitchen sink language here. If generics are something you need, please pick a language that's designed to solve the problems that you're trying to solve."
But that's a far cry from what TFA said. TFA read more to me as, "Go doesn't have generics because generic programming is a half-baked idea that isn't ready for prime time."
For example, it's why F# continues not to have ad-hoc polymorphism, despite many users clamoring for it. I'm inclined to agree with the project's maintainers on the subject. As useful a thing as it is, and as glaring as it is for a modern descendant of ML not to have it, it's hard to see how it could be added without creating all sorts of language warts.
[1] https://github.com/louthy/language-ext#ad-hoc-polymorphism
is a quote from the article, and seems to say exactly what you're saying?