> I don't even get the vitriol against generics - the designers have only taken a "not now" approach to the subject and everyone acts as if Go is a social experiment to get everyone mad about generics.
I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems like a strange thing to say when many languages are happily using them.
Implicit interfaces make generics a lot less trivial to implement. They also don't want to simply add an existing approach with bad trade-offs (see C++ templates). Likewise, adding a runtime based multi-dispatch based generic system is not much better than what we already have.
Lot's of languages have generics, but they have trade-offs, so they aren't free, even if they can implement them using existing generics implementations. Picking what they're willing to sacrifice can be hard, even if it's something like slower compile times.
Anything backwards compatible has to be in Go 2 or later, because generics are hard to make backwards compatible, we'll have to wait.
After hacking Rust, I got the feeling that generics are hard. They are so hard that a language should consider them from the beginning to fully take advantage of them. That might be the reason why the Go team says generics are hard to implement in the current Go type system. They can also choose either C++-like code generation based on templates, or external code generating tools, but both are not perfect in my opinion.
I don't use Go so I don't really care about their generics or lack thereof. What I found ... odd ... is how the Go team has apparently said they can't go generics because there's no good way to implement them. Seems like a strange thing to say when many languages are happily using them.