[iheartmemcache]

To be fair, most of the benchmarks I've seen from end-users don't have .NET Native outperforming the CLR except in huge number crunching situations[1,2]. As one would imagine in those scenarios using your standard stack of C++ with the GNU GSL[3] (which includes your BLAS, GMP, PDE, and standard lin. alg. stuff) is still pretty much king with MPL (based on MPI) with some (often modest, sometimes incredible OpenCL gains). In numerical methods, Fortran w/ a modern Intel MKL and MPI still reign for SIMD. I guess what I'm saying is, for your day to day Rapid App Dev (which Borland Delphi + the VCL was absolutely king at up until MS put out Lightswitch) you weren't really crunching away. Likewise, especially with modern JIT'ing if you _do_ crunch with a language that hit's the CLR hard, you still get performance similar to .NET Native (contrary to MS claims of "performance similar to C++). I've been a MS advocate for ages and admire what they've been doing since ~2005 at MSR all the way to the production cash cows[MS SQL Standard gives you a ~LOT~ of bang for your buck with SSDT/SSAS/SSRS] (check my 8 year post history - when everyone was rails rails! iOS! MBP!! I was silently C#3'ing along); I say all this as a long preface to pose this question - what exactly did .NET Native bring that presumably made it catch up to TP/Delphi?

[1] http://code4k.blogspot.com/2014/06/micro-benchmarking-net-na... [2] https://dzone.com/articles/net-native-performance-and [3] http://www.gnu.org/software/gsl/

[pjmlp]

30 years ago I was discussing these arguments between those using Assembly and those that dared to use C, Pascal, Basic and Modula-2 in home computers.

20 years ago I was discussing these arguments between those using C, Turbo Pascal and those that dared to use C++, Object Pascal features in Turbo Pascal/Delphi.

So I still envision the day managed languages get to the next discussion cycle.

> what exactly did .NET Native bring that presumably made it catch up to TP/Delphi?

Static binaries, integration with the Visual C++ backed (it is not used in JIT/RyuJIT/NGEN).

Pushing C# for more use cases where they still make use of C++. If you look at the C# 7 roadmap there are still more features coming into that direction.

One of the reasons they made .NET Native, which came from Singularity actually, was that the C++/CX uptake is not take big. Most developers only reach out to C++/CX instead of C#/VB.NET for the APIs not exposed to .NET, like DirectX.

I was a big fan of TP and eventually made the jump to C++, which is also very dear to my heart.

But I would rather have a full stack language that offers me the safety of Algol languages, without C underpinnings.

With .NET Native and the integration of System C# features into .NET, it is becoming quite appealing.

[iheartmemcache]

I apologize if I came off snarky; my intention wasn't to be argumentative. All of my questions were posed with genuine curiosity rather than with the passive-aggressive tone I may have unintentionally conveyed. I certainly am not in that group of language warriors. I don't have any allegiances to languages, platforms, styles of languages, or even architectures (I'll use a Harvard based over von Neumann if it gets the job done better).

Most of the people I know choosing C++ over C# are using it for the ability to get soft-real-time guarantees w/r/t performance. E.g. the gaming development guys have a "this next framebuffer ~must~ be done within 16.6 or 33.3 ms" or "I need a deterministic 'buy/sell/hold/not-enough-information-to-say-with-a-high-confidence-factor, defer-to-safety-net-policy'". At CppCon '15 most of the people I spoke to fell into a similar camp. I don't think I even spoke with one engineer who's day job involved using C++ because <insert CLR language here> failed to have interop capabilities w/ DX or what not. Of course, those who attend conferences will bias in a certain way so I'm not making an appeal to that demographic as in any way representative of the C++ user-body.

My assertion was simply : those who are using C++ are using it out of the benefits of predictable behavior. They can't afford that situaiton of: your GC won't decide this is the appropriate time to move all those marked as Gen0->1 over and oh by the way they're all a few bits big and fragmented so no pre-fetching help for you. What makes those guys different from the guys who were ASM guys who refused to use C back in the day is that the compiler eventually outperformed the hand-rolled stuff - but even then the ASM guys were steadfast. You make some real interesting points though and you're right - I haven't looked at the C#7 roadmap. Hell, to be honest I haven't even written enough code to take advantage of Roslyn's introspective capabilities. Thanks though, insightful comment as always. (Please keep on posting and don't disappear like the good posters of yesteryear (edw519, grellas, etc)).

[edw519]

(Please keep on posting and don't disappear like the good posters of yesteryear (edw519, grellas, etc))

Thanks, Andrew. I didn't disappear. Just spending more time building and less time posting.

[nickpsecurity]

"30 years ago I was discussing these arguments between those using Assembly and those that dared to use C, Pascal, Basic and Modula-2 in home computers.

20 years ago I was discussing these arguments between those using C, Turbo Pascal and those that dared to use C++, Object Pascal features in Turbo Pascal/Delphi."

Nice take on it. :)

"But I would rather have a full stack language that offers me the safety of Algol languages, without C underpinnings."

Exactly. That's always a Pascal advantage. You can be clear on exactly what it does and it's probably safe by default.