I've read that before. I do regard the conservatism here as carrying a cost: specifically, great rafts of code will be written without generics and the absence of generics will influence other parts of the language.

I'm not an expert in generics by any stretch of the imagination; I timidly implement the occasional template function, happily use STL/BGL where I can, and am amazed at the sort of data structures this lets me get away with.

I do find myself puzzled that apparently no generics system in common use was deemed 'good enough' by the Go team to just clag before an entire language and its aforementioned 'rafts of code' sprang up around the absence of such features... there may be good reason.

But a language that doesn't let me do what I happily do in C++, with type safety, using language features that are over a decade old, is a total non-starter for me. The language may be all the simpler for this, but the code I would have to write would bear the cost of this instead. It's not a win for me, and vague threats that I'll get a vomitous compiler message when I bugger up "make_pair" and hints that the "princess is in another castle" aren't going to browbeat me into accepting a throwback of a language. My guess is that g++'s template error messages are going to be acceptable long before I see generics in Go, if I ever do.