I'm wondering how long it will take until people will either stop linking to blatantly false articles or start reading more than the first 5 paragraphs of it.
Apologies, I quickly Googled and pasted the link like you implied I did. I remember a longer, more deeply reasoned article than this one, and by quickly skimming I mistook this for that - it probably was somewhere on the go-nuts mailing list.
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?
I don't see how this solves the generics dilemma. From the MSDN article:
"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."
No, it's not wrong. The .NET JIT generates specialized code once for each value type that some code is used with, which is pretty much what C++ does, although not at compile time, but at runtime (JIT compile time).
Even if one thinks that it's okay. Go is a statically-natively compiled language without an intermediate language and without runtime code generation. I don't think it would fit Go's design very well.
"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."
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.
I have no idea whether you or the person you responded to is right (note that my earlier comment just stated the Go developer stance without any value judgement of my own), but please let's not allow ad hominems to muddy the discussion!
There's only two sentences, should be pretty obvious... but ok: the second one is a thinly veiled - to give the benefit of doubt, probably not on purpose - ad hominem.
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.
