But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.

If the choice is between badly implemented generics, and having the problem manifested as userland code, I'll take the latter. I've actually had to debug C++ production code produced by the confluence of templates that had no source code of it's own. At least with boilerplate, you can simply see what's going on right there.

If language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed.

This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.

If you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.