By developing and using C++/WinRT, the Windows developers are prioritizing what's best for their systems programming work, as they should. Convenient tooling for rapid application development is the job of IDE developers, like the Visual Studio team. I think one of the mistakes of Windows 8 and Windows 10 was that the Windows team tried to directly provide conveniences for high-level application developers, built into the platform. I'm glad they've backed away from that. I know VS already has some tooling for C++/WinRT. Maybe they just need to do more work on that. Personally (as someone who no longer works in the Windows org, or at Microsoft at all), I'm glad I can use C++/WinRT, which is just standard C++, with any build system I want, and presumably even with clang rather than VC.
Well next time do a proper job, given that even ATL has better Visual Studio tooling.
The non standard extensions excuse apparently is only an issue for Microsoft compilers, as you are enjoying those clang extensions without problems.
The way management has dealt with WinRT ecosystem, it turned many of us that were hard advocates, into disgruntled developers that only wants it to implode as if it never happened.
In what concerns WinRT, "Developers, Developers, Developers" is long gone.
Short version story, a group of WinDev folks weren't happy with C++/CX and its C++/CLI extensions.
So they brought in Kenny Kerr, which was trying to create a C++ library without those extensions.
Out of that effort, C++/WinRT was born, they deprecated C++/CX (5 years ago) and told Microsoft customers to suck it up and wait for the day C++ gets reflection, because they couldn't otherwise provide the same level of tooling for C++/WinRT, as C++/CX enjoys on Visual Studio.
Nowadays they are having fun with Rust/WinRT, while every customer that has to deal with C++/WinRT enjoys editing IDL files without any VS tooling, and merging the generated C++ code manually, after every IDL change.
To the point of that even MFC has better tooling for dealing with COM.
A tiny group inside Microsoft is now happy, while all customers deal with the mess they left behind.
Clearly the timeline we deserve.
There is also the perception of what languages are favored for jobs (though freelance and independent work seems overlooked), despite that Object Pascal/Delphi is still doing quite well in the rankings (and for many years). Often floating between TIOBE's 10 to 15 rankings, and among or ahead of many notables like Go, Rust, Lua, Kotlin, D, Nim, etc... Who nobody in their right mind would claim are "dead".
One could argue that Nim had its shot, as its no spring chicken. Nim is older than Go, and has been around since 2008. So if it was going to get "the push", would think that would have already have happened.
V (vlang.io), on the other hand, comes across as a special case. Is still relatively young, so could possibly at some point make a run towards heading up the charts. It's in a sweet spot between being both a C and Go alternative, and has taken the approach of studying other languages to make itself more appealing, useful, and practical. Perhaps the sport's term, when describing a prospect, is that it has a "high ceiling" or high potential is the most appropriate.
