> While the lack of generic support for numeric types isn't a great thing, this is definitely not a performance issue.
Agreed. It's a nasty papercut. But issues like these really do put off native developers. I can't say that this alone had anything to do with the move back to C++, but well who knows.
>"B) they realized that native level performance really matters on mobile, and so does C and C++."
Java is pretty damn successful on Android.
Yes, and so is C++.
Lots of native apps are written on android, including Mono. Mono is also native on Android via C++. And mono can also run native on android.
i don't know anything about the internal politics of MS, but I actually do think that the internal teams would probably have preferred to use C# for both Windows components and Office.
>"Interoperability with C / C++ / headers"
I can't really comment on it, but doubt this one is gonna happen, this would mean that the future characteristics of C++ (partially) define the future characteristics of C#, and would stop C# from being an independent language.
Mono will be addC++ interop in an upcoming release (at least they've blogged about it). Their interop uses a C++ compiler to automatically generate interop assembly code that can be directly consumed from C#.
>"Optimized Code Generation"
No, the code generated by the jitter is not well optimized, simply because there is no time to optimize it. .NET's jitter does not do hotspot optimization, and NGEN does not optimize.
Mono compiles AOT using LLVM, which is apple's optimizing C++ compiler backend.
> Anyways, in C#, features that support manageability and extensibility of large code bases will always be favored over ones that improve performance but lower the first two. Performance is the secondary goal.