I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.
http://research.swtch.com/generic
They do believe it's a useful feature, they just don't think the tradeoffs justify it yet. (People who loudly clamor for generics tend to ignore these tradeoffs.)
Go devs made it clear that Go won't get Generics, and it's fine.
With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sane programmer would create by hand.
(I wish I had it at hand, but there was an excellent post from a .NET/CLR guy a while back that went into all the crazy stuff that got instantiated just by creating one specialization of List<T>, the associated performance overheads, and the things the compiler and runtime tried to do to avoid those.)
Personally I like Go a lot and don't miss generics much, but for some things I'd love to use generics some day. It's basically about trade-offs eventually. To quote the FAQ about it:
> enerics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
> Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
There's definitely work to be done in the details.
This is my general read on where I think the community and developers are going... that's all.
Who needs generics? 'Need' in it's dictionary sense. i.e. is there an algorithm you can't write in a language because the language lacks generics? Great to have? Yes. Need? No.