4 ms·

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

by srean 11y ago

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#

jaked89 11y ago
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-compilation http://www.telerik.com/blogs/understanding-net-just-in-time-...
- srean 11y ago
  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.
  - breischl 11y ago
    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 https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx
- ygra 11y ago
  Technically it's an ahead-of-time compiler, unlike Java's Hotspot which actually does just-in-time compilation.
poizan42 11y ago
Or target Core CLR with C# and build with .NET Native...
jeremiep 11y ago
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 :)
- jaked89 11y ago
  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.
  - jeremiep 11y ago
    I use Emacs as an IDE and gdb for debugging and it works like a charm.
- CmonDev 11y ago
  Array slicing is likely to come in the next few versions. Templates and generics are simply different things.
mhomde 11y ago
That's no longer true with Windows 10 where .Net Native compiles everything into native code directly
- guiomie 11y ago
  For desktop apps. As far a I know, you can't run in IIS native apps.
  - mhomde 11y ago
    True, and I'm not sure there would be much point. .Net native is mainly to reduce startup times and reduce memory footprint
  - douche 11y ago
    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.
    - guiomie 11y ago
      So, you are saying I could run a .Net Native app in a OWIN ?
      - douche 11y ago
        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.
  - e12e 11y ago
    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...)?

by srean 11y ago

jaked89 11y ago

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-compilation http://www.telerik.com/blogs/understanding-net-just-in-time-...

srean 11y ago
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.
- breischl 11y ago
  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 https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx
ygra 11y ago
Technically it's an ahead-of-time compiler, unlike Java's Hotspot which actually does just-in-time compilation.

poizan42 11y ago

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

jeremiep 11y ago

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

jaked89 11y ago
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.
- jeremiep 11y ago
  I use Emacs as an IDE and gdb for debugging and it works like a charm.
CmonDev 11y ago
Array slicing is likely to come in the next few versions. Templates and generics are simply different things.

mhomde 11y ago

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

guiomie 11y ago
For desktop apps. As far a I know, you can't run in IIS native apps.
- mhomde 11y ago
  True, and I'm not sure there would be much point. .Net native is mainly to reduce startup times and reduce memory footprint
- douche 11y ago
  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.
  - guiomie 11y ago
    So, you are saying I could run a .Net Native app in a OWIN ?
    - douche 11y ago
      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.
- e12e 11y ago
  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...)?