6 ms·
Sadly, the mailing list debates often don't contain much more than linking to this article and repeating unsubstantiated claims. The points brought up in the c
by happy_dino 14y ago
Sadly, the mailing list debates often don't contain much more than linking to this article and repeating unsubstantiated claims.
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 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⁎
- pjmlp 14y agoThat is a common reaction, see this Plan9 response to a user that wanted more functionality out from ACME. http://9fans.net/archive/2008/08/134 http://9fans.net/archive/2008/08/134
- mseepgood 14y agoThe user didn't ask for more functionality, he asked what the ACME way is.
- mseepgood 14y agoI 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."
- happy_dino 14y agoThat's pretty much wrong on all accounts. I recommend getting a basic grasp of the topic before trying to defend Go in such an awkward way.
- vanderZwan 14y agoI 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!
- happy_dino 14y agoCould you please identify the ad hominem? I don't see it.
- vanderZwan 14y agoThere'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.
- mseepgood 14y agoNo, 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).
- quatrevingts 14y agoAnd since it's at runtime, strike out the "much of it redundant, requiring a good linker.." bits. Which leaves it sounding pretty good.