[kgeist]

The main use case of generics is generic containers, and the two most popular generic containers - lists and maps - have always been part of the language (including their built-in generic functions). So in most cases, in a typical web project, you could indeed get away without generics entirely. Only in a few cases you'd be forced to use codegen/reflection/duplication - when you have to use complex algorithms which lists/maps can't satisfy. However, the Go team and the community had always been open to the idea of adding generics to the language (the official FAQ already in 2013 talked about potentially adding generics in the future), they just weren't sure how to implement them properly without overcomplicating the language (which is advertized as being simple), and generics can easily add a ton of complexity. So the introduction of generics was postponed because there were other more important features to iron out, considering that slices/maps already covered most cases. I think the breakthrough happened with the realization that code is more often read than written, so it's OK to make the language a little more complex for a library's author, most users won't see a considerable increase in complexity.