Point me to a successful statically typed language born after 2005 that doesn't have some form of generics. Go has generics by the way, you just can define your own in user land, which is a stupid limitation.

Class hierarchies, for example, got heavily overused before people discovered that composition most of the time is the better option, exceptions got overused before people learnt to only use them in exceptional cases, and dependency injection and XML (one of the first environments with strong support for it) got overused in Java programs.

Generics are going the same way, if they haven't already (JavaScript modules will get there, too, but that seems at least a generation of programmers away)

Also, the only difference I see between generics (with a bit of 'compile-time reflection') and go generate is that the former may be too magical for some, while the latter requires programmers to do more work (writing special comments to use existing functionality, and writing AST manipulation code to write new ones) and that it generates files only because the compiler wants to see them.

Backing away from specific suggestions, I think it's healthy to recognize that Go has a boilerplate/DRY problem--not just with error handling!--, and it would be nice to address it in some way. If not with generics, then with something.

I'm having a hard time understanding where using generics would cause problems.

C++ templates, sure, but those are much more powerful than just having parametric polymorphism.

C++ templates! I keep on running into places where I'm debugging, then I find myself in a maze formed by template overuse, then debug around that instead.

just having parametric polymorphism

I think that could be workable in Go. I can imagine how debugging that would be straightforward.