Hacker News Reader

Comment by srean | Hacker News Reader

Just to put it out there: If you like C# the language but rue the fact that it will execute on a VM layer, you might want to take a look at D. Especially if you are into number crunching with small memory footprint, it seems C# is not a good language for that. Otherwise, there is really a lot to like about C#

View on HN

Coming from using D for personal projects and now working in C# at work (in .NET 2.0 as well because of Unity) I find myself constantly missing D features. Especially given one of the main requirements of the work I'm doing is performance.

Things like array slices being first class in D while ArraySegment<> looks like a hack in C#, D templates beating the hell out of C# generics, functional programming in D is actually inlined almost 100% at compile-time while LINQ adds noticeable overhead, and the list goes on :)

Templating is one of the strongest features of D IMO, and the only reason I would ever consider using it over C#.

No decent IDE/debugging story though, so overall C# still wins for me at the moment. Especially for large projects.

I use Emacs as an IDE and gdb for debugging and it works like a charm.

Array slicing is likely to come in the next few versions. Templates and generics are simply different things.

C# doesn't "execute on a VM layer". It's compiled to native code before execution, in a process known as JIT.

http://www.telerik.com/blogs/understanding-net-just-in-time-...

Given the scarcity of non-scripting language VMs that do not use JIT, this is what I mean by VM layer nowadays.

There is whole lotta difference between execution of a "AOT compiled to machine code, potentially profile guided if need be" program and a "selectively compiled under severe time pressure that precludes deep compiler optimizations" one, much that JIT camp would like to brush under.

There is still a substantial gap between the pregnant promise of a JIT and its delivered performance. The gap that needs to be bridge does gets narrower by the year though. [Mono does have AOT compilation, but I had given up on a then buggy Mono and haven't found enough motivation to go back. Should I ? A non bugged F# on Linux would be really sweet.]

Under circumstances JIT can, and do outperform, but those are not nearly the common enough cases and configurations, at least not in the number crunching world. And some of the scenarios that get held up in JIT's defense are plain hypothetical, 'for arguments sake only'.

C# is much better than Java about interoperating across the managed - non-managed bridge, D is significantly better still. The poverty of the C# eco-system in number crunching libraries, or even production quality glues to native number crunching libraries, is really stark. I guess it was never an area they wanted C# to venture in. For example their standard math library does not work on float32. WTF! The first time I realized this, I couldn't believe it.

By the way the author of the article you linked has this to say:

   JIT can generate faster code, because it targets the
   current platform of execution. AOT compilation must
   target the lowest common denominator among all possible
   execution platforms.

This points to another bridge that needs crossing (the one between the AOT and JIT communities). Had there been a garbage collector for the web, that should have been history by now. Command line options for compilers have been a thing for quite a while.

Actually you can AOT compile C# down to machine code. I haven't tried it, but they've been pushing it pretty heavily for a while now.

https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

Technically it's an ahead-of-time compiler, unlike Java's Hotspot which actually does just-in-time compilation.

Or target Core CLR with C# and build with .NET Native...

That's no longer true with Windows 10 where .Net Native compiles everything into native code directly

For desktop apps. As far a I know, you can't run in IIS native apps.

True, and I'm not sure there would be much point. .Net native is mainly to reduce startup times and reduce memory footprint

For anything outside massively scaled web applications, I'm not sure IIS is worth bothering with anymore, now that self-hosted OWIN is more stable, and there is a version of ASP.NET MVC that runs on OWIN.

So, you are saying I could run a .Net Native app in a OWIN ?

Apparently I misspoke, and OWIN is not totally compatible with .NET Core yet. Still, I've found that developing and, moreover, deploying, OWIN self-hosted apps is much more pain-free than using IIS. App pool idle timeouts and recycling are a huge pain for anything that utilizes long-term background services, which happens to be the case with most of the stuff I work on. And ensuring that the appropriate IIS role services are installed is much more of a pain for customer deployments than building what you need into an OWIN app.

Does anyone happen to know what the AOT cross-platform story is? Can I build executables that targets eg: Linux/x86_64, OS X in addition to Windows 10 (I mean as three separate binaries -- having one monster, multi-target binary might be interesting, but that would be something else...)?

You mean AOT and with good optimization passes ? That would be quite awesome, any pointers (no pun intended) ? Please have one upvote already,

Now if you were to say that they are going to merge in a float32 math library, I will probably throw a party.

yes, .Net Native runs the managed code through a modified version of the c++ compiler and gains some benefits from it's optimization, not sure how much of a difference that does however. Good talk here: https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native

"You get highly optimized binaries that load and run faster than .NET code ever has before. Yes, my friends, .NET has gone native! :)"

It would be funny to review older "almost as native speed" claims from .NET JIT "overlords" vs current ".NET native is as fast as native" new claims :-)

Reply on news.ycombinator.com