Sounds like you have something in mind. All you have to do now, is: 1. Expand on your idea with some examples. 2. Show how this can be done without breaking

Sounds like you have something in mind. All you have to do now, is: 1. Expand on your idea with some examples. 2. Show how this can be done without breaking existing Go code 3. Showing where the performance hits are - runtime? compile time? binary size? memory? 4. Show how this plays along with Go's implementation of interfaces, as well as other already-generic types, such as channels and maps. If you can do all that, realistically, then I don't see why it wouldn't be taken seriously? Heck, if you can provide even an example implementation (talk is increasingly cheap) I bet you'll get lots of people on-board! You seem, like many others, to think that Go core team members don't want "generics". All they have ever said is - "we don't want bad generics". That's all. Anyone can say "I don't know what exactly Go generics are, how they look like, how they perform, how they change the syntax, all I know is - I want them". Like I said, talk is cheap.