Hacker News Reader

Comment by happy_dino | Hacker News Reader

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 talks about the .Net Generic implementation in a bit more detail.”

Russ Cox: ⁎crickets⁎

View on HN

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."

That'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.

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!

Could you please identify the ad hominem? I don't see it.

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.

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).

And since it's at runtime, strike out the "much of it redundant, requiring a good linker.." bits. Which leaves it sounding pretty good.

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.

.NET is as well, ever heard of NGEN, Bartok compiler, mono -aot or the native compilation when targeting Windows Phone 8?

http://my.safaribooksonline.com/book/programming/microsoft-d...

"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."

Except that is .NET 2.0. Do you also want to compare Go with K&R C compilers for that matter?

Do you have any indication that this has changed? If yes, how, without runtime code generation?

I don't have information, but by focusing on NGEN for .NET 2.0 you forgot all the other implementations I mentioned.

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.

I didn't find anything useful about generics in any of your links.

That 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

The user didn't ask for more functionality, he asked what the ACME way is.

Reply on news.ycombinator.com