From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Ja

From an implementation perspective, generics aren't that bad. For an ahead-of-time-compiled language, you either need a uniform value representation (like ML/Java) or a monomorphization pass (like C++). The former corresponds to what Go has today if you simulate generics with interfaces. The latter corresponds to what Go has today if you simulate generics by duplicating your code (for example, if you wrote an IntTree to operate on ints, a StringTree to operate on strings, and so on). They do complicate the typechecker a little bit, largely due to the interaction with subtyping (which Go has via interfaces, I believe). You probably want definition-site variance, not use-site variance like Java, to keep things simple. Also remember that parameterized types must be invariant, not covariant, in the presence of mutability. (Additionally, if you have subtyping for function types, remember that the arguments are contravariant -- Go probably doesn't care about this, though.) None of this stuff is that complicated, though -- it's all pretty straightforward at this point. There's no reason to fear generics. Moreover, as noted above, all of the workarounds end up duplicating effort that the compiler could have done for you. If you use interfaces, you pay the tax of boxing. If you use code duplication, you pay the cost of increased compile times and increased binary size. Nothing is gained from not having generics, except maybe a simpler type system.