@rab36: I agree. Microsoft has pulled off unifying it's previously fractured platform again with WinRT, and looks to have positioned itself well into the future. Unfortunately for .NET that unification revolves around native code and C++, and not .NET. Sure there is nothing preventing anyone from writing apps in .NET, but it is not at the core of the platform, and it will not offer either the performance, nor easy interoperability with traditional C++ libraries. The platform is built on C++. The reason for this is simple: performance and interoperability with existing C and C++ code.
As a comparison, take a look at the iOS/OSX platform, which revolves around Objective C. Objective C is somewhat hobbled by it's reliance on selectors, which use a form of optimized dynamic dispatch. However Objective C actually "is" C and C++. C and C++ code can be intermixed freely in Objective C, you do not pay a penalty for JIT compilation, and code that does not use Objective C selectors runs with the same performance as any C/C++ function, and there is no GC penalty.
Contrast the strategy. In the mid 200x's Microsoft introduced Win/FX with WPF, WCF, and other major .NET based replacements for the native level Windows platform. Apple introduced Cocoa and the other NS based "kit" libraries for OSX. The .NET Windows platform is now deprecated on on it's way out in favor of the native Win 8 platform, while Cocoa became the standard platform across all apple devices.
Native performance and tight interop with C and C++ won on both platforms. Java has been deprecated on iOS, and .NET has been put in 2nd place (though certainly it is NOT deprecated) on Windows 8.
My post and original point was that it really didn't have to be this way.
posted by bcooley
