You aren't going to see any radical changes to the language in the 1.x series.
If/when they find a solution that fits their strict criteria, it in all likelihood will require breaking changes to the Go language, and the point of having the 1.x series was a promise that this would not happen.
The problem is that the topic of generics has come up so many times on that mailing list it will require quite a bit of digging to find that again.
That said, the discussion below the article does get across the standpoint of the Go developers on the topic, doesn't it?
The points brought up in the comment section below the article were not answered at all.
Russ Cox: “I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes [...]”
First comment: “How about C# implementation? It lets you use primitive types.”
Second comment: “The massive gaping hole in your list of approaches is .NET: reified generics, but in a reference-type oriented language. [...]”
Third comment: “http://msdn.microsoft.com/en-us/library/ms379564(VS.80).aspx talks about the .Net Generic implementation in a bit more detail.”
Russ Cox: ⁎crickets⁎
"If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating."
So .NET has chosen number 2 with duplicate elimination:
"This slows compilation. It generates a lot of code, much of it redundant, and needs a good linker to eliminate duplicate copies. The individual specializations may be efficient but the program as a whole can suffer due to poor use of the instruction cache."
"With NGen, there can't be anything "lazy" about how generics are instantiated. Instead, NGen must create representations of every generics instance it could encounter. The CLR won't be around to JIT anything. So, after all the discussion of avoiding code bloat and taking advantage of CLR's run-time optimizations, NGen takes all those values and turns them on their collective heads."
Bartok compiler for Singularity uses another approach of code generation.
http://en.wikipedia.org/wiki/Bartok_%28compiler%29
http://singularity.codeplex.com/SourceControl/changeset/view...
Windows Phone 8 only runs native code. .NET IL gets compiled down to native code when uploaded to the Windows App Store, by making use of an optimizing IL to native compiler.
http://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and...
http://channel9.msdn.com/Events/Build/2012/3-005
Mono also compiles to native code on iOS and other systems as well
http://docs.xamarin.com/guides/ios/advanced_topics/compilati...
The IL2CPU compiler used in the Cosmos project, which is still not fully implemented
http://www.codeproject.com/Articles/220071/Csharp-Open-Sourc... http://cosmos.codeplex.com/SourceControl/changeset/view/1011... http://cosmos.codeplex.com/SourceControl/changeset/view/1011...
Going back to the runtime code generation (JIT), there is also SPUR being used at Microsoft Research
http://research.microsoft.com/en-us/projects/spur/
Don't mix languages with their implementations.
You're putting yourself into an authority position where you write him off as incompetent:
"Do your homework! What you say is wrong and awkward!"
That's an attack at him personally, and completely unnecessary. Simply providing the facts showing that he's wrong would have sufficed. You haven't done that, btw.