On Windows you might have C#, but WPF and UWP lower layers are actually written in C++ and based on COM.

Xamarin uses C and C++ to bind the nice .NET code into the platforms they support.

Qt Quick is just the layout engine, many important parts of the stack keep being C++.

Apple's Metal shaders are C++14.

On Android Vulkan is only exposed to the NDK and SurfaceFlinger and hardware compositor are in C++.

Plus if you compare compare Rust with Objective-C, Swift, C#, Java, the productivity story regarding GUI programming doesn't get better than when comparing with C++, on the contrary.

> Qt Quick is just the layout engine, many important parts of the stack keep being C++.

Also, Qt Widgets isn't deprecated, it's just considered pretty much complete.

And Qt Widgets won't be deprecated for a long time to come, if ever.

> On Windows you might have C#, but WPF and UWP lower layers are actually written in C++ and based on COM.

Well, this doesn't really influence the language programmers have to use to build applications, considering you can use C++, C#, VB.NET, or JavaScript to your heart's content.

Windows GDI is a C API, but not every application using it is written in C.

Still the issue stands, from my experience Rust isn't yet at the same productivity level as C++, C#, VB.NET, or JavaScript for writing Windows GUI based applications, both for Win32 and UWP set of APIs.

Yeah it will eventually get there, but it is a disservice to Rust to promote the language as it if was already possible today to do it, when most toolkits are still WIP and lifetimes aren't that friendly for the usual GUI coding patterns.

This will only lead to disillusion and shy away contributors that might otherwise enjoy using the language, if they understood the current state before diving in.

Sure, there's C++ here and there underneath, so what?

> Is GUI programming in C++ still a thing, though?

All of the new Windows 10 UI is C++ (using the UWP XAML framework, which is implemented in C++). The paper says metaclasses are a way to avoid language extensions like UWP's C++/Cx, which adds C# things like "interface" and "event" to C++.

Disclosure: I work at Microsoft.

Oh, that explains why I can't navigate in "Settings" with Alt-Left (and there's no Back button either), yet it looks like an IEView (MSWebView, Electron, etc.).

Alt-Left goes back in Settings for me, and there is a back button at the top left of the window.

Can you disclose anything about C++/WinRT?

Things went pretty silent there.

Don't know, but it's been discussed publicly rather recently:

https://github.com/Microsoft/cppwinrt

https://msdn.microsoft.com/en-us/magazine/mt745094.aspx

"Teams within Microsoft are already starting to use C++/WinRT to build WinRT components for the OS itself."

Thanks, that part I already know.

My point was more about Blend, XAML tooling support and official integration into Visual Studio.

So, all the things that C++/CX has today, but C++/WinRT was still catching up when that information was made public.