Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
So instead of some--very limited, as languages like ML show--complexity in the type system, go punts these difficulties to the poor programmer who is then forced to constantly dynamically cast values, simultaneously adding clearly superfluous noise to the code and subverting any compile-time safety the type system offers.
Wow, they still mention that non-sense in the FAQ?
Let me guess, they also still link to that “OMG Generics are so hard” article where they conveniently manage to ignore the comments which point out the elephant in the room?
Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in maps and slices, plus the ability to use the empty interface to construct containers (with explicit unboxing) mean in many cases it is possible to write code that does what generics would enable, if less smoothly.