Hacker News Reader

This isn’t a new proposal. Go’s maintainers have always been clear that they weren’t against generics per se but we’re against rushing into implementing something without giving sufficient time to consider the options.

Personally I don’t think their time spent considering has resulting in anything better than if they had rushed into a solution (I’m not a fan of this proposal). But that’s just my personal opinion.

View on HN

I'm not sure what you're comparing to, but there were previous proposals that were pretty different (and worse in my opinion), and there were changes along the way in the drafts that eventually turned into the accepted proposal.

Yea basically they're implementing Java-lite generics. I'm not sure what they have been waiting for exactly...

Java generics do type erasure, this proposal does not. Java generics do not work on primitive types or with operators, this proposal does. Java generics require unbounded parser look-ahead by using <>, this proposal avoids it by using []. These are just from the top of my head, I'm pretty sure there are more differences.

Reply on news.ycombinator.com