C++/CX is not a replacement for .NET.
You are technically correct, but I think Daniel's tongue-in-cheek point is valid. The C++/CX project exposes a subtle shift away from the .NET principles and back to more traditional pure COM. Couple this with clear indications from Microsoft that the utopian dream of JIT compiled managed code replacing native code was a mirage, and it's not a stretch to see that .NET is losing its sheen in favor of more efficient native code like C++/CX with a tighter coupling to the underlying runtime framework.
I'm not sure who was having that utopian dream, but I never believed that managed code ever would or could replace native code entirely. It's simply not practical or well-suited for many performance-intensive tasks. That's not what managed code is about. Managed code is about productivity, leveraging and consuming a huge number of APIs (that may be partially or entirely implemented in native code), and allowing the programmer to focus more on domain problems rather than than on managing the heap and the lifetime of their program objects. Also, as computers become increasingly-faster and as JIT technology improves at the rate it has over the last 20 years, the performance advantages of purely-native code become less significant. 20 years ago, native code was the only feasible way to do most things. Today that's no longer the case, and in the future, it will become less essential than it is today. And, the fact that 99 out of 100 users are unable to distinguish between native and managed code makes that idea seem a bit silly.
I also don't think C++/CX represents a shift away from .NET principles. WinRT was designed to be consumed from both native and managed code with full language parity, and to provide complete interoperability between all supported languages. You can consume WinRT components authored in any supported language, from any other supported language. You can consume components authored in managed code from native code, and visa verse. If you ask me, that is not a shift away from .NET principles. On the contrary, that's a shift towards .NET principles.
About .NET loosing its sheen, I don't think that's the case. Ideally, the full .NET framework would be ported to other platforms, but that's not going to happen, and one of the major reasons why has nothing to do with 'more efficient native code like C++/CX', it is mostly about portability, running in a
sandbox with heavily-restricted privileges, and about Windows/Intel-specific dependencies of many .NET APIs, like for example, the dependence that WPF has on DirectX, which is inherently Windows/Intel bound, and will never be ported to any other platform.
There's also many other Windows-specific APIs in .NET that cannot be easily translated to other platforms, and the biggest reason why WinRT does not include the full desktop .NET framework is because it is a
sandbox that deliberately restricts access to the underlying system.
If you read the article I posted the link to, you'll see that the CLR is alive and well in Windows 8 and WinRT, but when you want to build WinRT sandbox applications that can be published on the app store, you must use WinRT APIs only, and you must adhere to all of the imposed restrictions.
I don't see what any of that has to do the better performance of C++, with or without the CX extensions. If performance was that important, .NET would never have become as huge as it is today. WinRT and C++/CX are mostly about Microsoft's attempts to realize some traction in the tablet/mobile device market, something they've failed miserably at to date. I predict their strategy of turning every desktop PC into an oversized smartphone will fail miserably. Why? Because Windows users aren't interested in towing Microsoft's line and constantly re-tooling their business processes and their brains, in service to Microsoft's marketing agenda and its history of abysmal failures. If Microsoft already had a major share of the small-format/mobile device market, then turning every desktop PC into a giant smartphone might make sense.
I recall your once labeling .NET a 'fad' that will pass. I think its been more than adequately shown that was simply not the case, and in fact, today, the CLR and standards-based C# are bigger than Microsoft, and they couldn't stall its momentum even if they wanted to.
