Going Native

... or not so much.

What's about Microsoft initiative named: Going Native? This is Microsoft's attempt to promote C++ 11 standard and future Visual Studio version that will improve the broken C++/.Net bridges.
Which are the reasons? Basically: using VNext (the "codename" for the next version), you will have outline of your code like you were able to do for some time in Eclipse CDT plugin.
The problem is in my understanding not the marketing part, which is cool (as is presented in the first part), like you can get the ultimate performance as you can get the ultimate control, you can map in shared memory, so another process can reuse your data and other "cool stuff like that". In fact I've got it, you can get huge performance using those constructs, yet the problem is after how many years, after how much testing. The reason that I was sold out for .Net languages is the service part: language have rich support for type information (named reflection or RTTI), which makes that the compiler to rarely fail on code completion, have saner defaults for memory management and decent performance. Where in NaroCAD performance was the issue, was because of the wrong algorithms, or not profiling the code.
The last days I was working with wrappers for OpenCascade 6.5.x. I was fairly surprised of how fast the compilation of C++ code works (as machines are much powerful as they were some years ago) and even I did not finish to port them, I've noticed some parts that were overall slow: disk access, the number of frameworks that NaroCAD use (by default NaroCAD uses WPF which is DirectX wrapped by a framework CodeCLR, .Net, OpenGL and OpenCascade, GDI+ (to host OpenGL/Occ window)). If it would be no framework, or Windows would have a way that frameworks will be always up-and-running, I think that NaroCAD would start (close-to) instantly.
So at the end I felt that this is why people do not tend to go native: is all about how many things you get for granted with high level languages/platforms: tools to make fast an UI, a great debugger, no chance (excluding a VM bug) to get "Invalid address" errors or like. And at the end a person that would want to extend NaroCAD, would not care at the ultimate performance you may get using a compiler as GCC that would inline differently some parts of the code based on your constants flow, but it would want to have a way to inspect the API, a way to script it (maybe using Boo), a way to import Step files and to export them back.
If and when NaroCAD will be performance bound, I do think that the way to improve it is: be multi-threaded (to be able to use the AMD's 8 cores, by using parallel extensions), be multi-process and distribute over the network (as WCF permit that much easily than any C++ framework I know it would be able to).
At the end the trend of using native is true for phones, and I agree that there are "native" ways to improve your performance for limited hardware, but NaroCAD as it stands, I don't see it that to happen any time soon. And if (ever) NaroCAD would work on an Android or IPad class hardware, it would take at least 1-2 years to complete it, so maybe it would address the hardware that would exist at that time, and it would be likely at least an ARM dual core (as is iPad 2) or ARM quad core (as is NVidia Tegra 3), where the stated arguments (multi-core and maybe multi-process) remain the way to improve. And the framework to use? Maybe Mono Touch and Mono for Android.