This comment isn't very kind to the Go developers, and it makes a lot of assumptions about what they know. The Go developers understand what generics are, and w

This comment isn't very kind to the Go developers, and it makes a lot of assumptions about what they know. The Go developers understand what generics are, and why people want them. They realize that generics would enable programmers to write less code, and in some cases keep them from relying on reflection. Something else that's well understood are the tradeoffs necessary to implement generics. All of the facets of this are discussed here: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... Anyways, it seems like all of the comment's stated use cases are accounted for. Arrays and slices are already generic. Queues are available in blocking and non-blocking flavours via channels, which are generic. Sets are available via maps, which are generic. The builtins get you 99% of the way there. The developers decided that the remaining 1% of use cases were not worth the trade-offs of implementing generics. Go consistently makes trade-offs that favour simplicity, compilation speed, and not hiding runtime costs. Depending who you are, you may or may not value that more than the ability to write code that uses generics. I agree that people who want generics should not use Go, but I don't agree with painting the Go team in the way that this comment does.