> Generics were always planned, of course ...
This is provably incorrect.
The position held for many years by the language authors was[0]:
Generics may well be added 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.
Once the community could no longer be held back, the golang FAQ presented a very different position[1]: The Go 1.18 release added type parameters to the language.
This permits a form of polymorphic or generic programming.
0 - https://web.archive.org/web/20170102202940/http://golang.org...> Generics are convenient but they come at a cost in complexity in the type system and run-time.
By run-time they mean compile-time? There shouldn't be a run-time penalty right?
Also, is there some measure of the additional compilation cost now that generics has been added?
Considering that Ian was already working on them before 1.0, and never stopped until a solution was found, we know for certain they were planned by at least one person on the Go team. If you are struggling to say that Go people are not a single monolith then sure. Nobody has ever thought people are a single monolith.
However, the original announcement makes the intent of the project clear: "Not yet", not "never". They were always planned to be accepted into Go. But not before an acceptable solution was found.
"May well be added at some point" it said and added they were at some point.