Surely you don't mean the Go team, which has had this in the language FAQ since 2009 [1]:
Why does Go not have generic types?
Generics may well come at some point. We don't feel an urgency for
them, although we understand some programmers do.
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.
Surely you don't mean the Go team, which has had this in the language FAQ since 2009 [1]:
Why does Go not have generic types?
Generics may well come at some point. We don't feel an urgency for them, although we understand some programmers do.
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.
[1] https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713...