[mdwrigh2]

So because Russ Cox didn't respond to some comments on his blog, the Go team is trying to shield users from generics because they think they're too complicated? I don't buy that. If you follow the go-nuts mailing list, the pros and cons of various generics implementations have been argued back and forth, and they have yet to find one that meets their criteria. I don't think they disagree that it would be helpful, they just don't think that the trade-offs current implementations provide aren't worth the convenience they add.

[coldtea]

>So because Russ Cox didn't respond to some comments on his blog, the Go team is trying to shield users from generics because they think they're too complicated?

Yes. The whole "we'll do it when we find the perfect way" is bollocks. Generics are a solved problem and engineering is about compromise.

It's just that the compromise in favour of generics is not the one they wanted to take. But the official excuse is more of a way to shut people up about it, than truthful commitment to finding the best way to add them in Go.

[mdwrigh2]

I'll give you that what you say about the Go team's motivations is entirely possible (though I don't believe it to be the case), but not responding to blog post comments shouldn't be indicative of anything.

[coldtea]

Yes, I agree with your disclaimer re: blog post comments in general.

Thought it might be if not proof, maybe indicative: he specifically asked for comments on that blog post. And according to the parent, those comments were well reasoned and by a high expert on the field -- they would at least deserve a reply.

[gnuvince]

Personally, I think that generics, in whatever form, are never going to happen in Go. The designers are smart enough that if they were really interested in them, they would've studied different approaches and come up with a reasonable design. I just think that having maps, slices and channels be polymorphic is enough for the designers and they have no use for something more complex.