Next will be the operating system that everyone runs their stuff on. Doesn't WSL already default to Ubuntu anyway?

Edit: also isn't Shutteworth still funding Canonical out of his pocket? The last I checked it wasn't nearly profitable.

Under what theory would the justice department interfere?

https://news.ycombinator.com/item?id=23205763

Microsoft buying Mozilla would only buy developer time, not Rust itself (and then only if the developers don't jump ship).

- Expert Q&A: C#/C++/Rust WinRT Team

- The 30 Min Beginner Rust Coding Challenge

- Intro to Rust

- Microsoft's Safe Systems Programming Languages Effort

More info at:

https://mybuild.microsoft.com/sessions?t=%257B%2522from%2522...

So if the designers have drawn up the UI for the next major refresh, Office doesn't need to wait for the shell team to have implemented the controls, or for development to have them wrapped up in MFC.

If the dependencies already exist, you're on safer ground. Though team culture may choose otherwise; I understood Excel didn't like having any external dependencies.

[0] https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...

Also many WinUI components have come from Office's experience adopting UWP APIs.

My personal view/situation is a bit different. I think this is nothing more but yet another attempt by Microsoft to woo customers into a set of technologies/runtimes/APIs that are way more constrained that good ole Win32. On windows desktop GUI front I was using Delphi since 90s and barring few easily fixable hick ups what did work then works as a charm even now. So instead of wasting my time on their infinite ever changing set of front end tech I stayed on a proven path and that saved me a ton of money. And my desktop development is still the same with extra niceties as added multi platform ability and free and open source Delphi's alternative Lazarus/FreePascal combo.

The winrt APIs can be used from traditional desktop apps just fine, and mixed with win32 from within the same executable. They don't constrain anything. UWP, however...

Most and all are 2 different things. I've discovered limits immediately after investigating possibility of porting one of my apps.

The winrt APIs can be used from traditional desktop apps just fine

WinRT based applications run in sandbox and have their own limits.

None of what you say has any relation to my original POV.

Now that they have Github, NPM, Azure, WSL2 and WinUI its no surprise why they would want to allow other languages such as Rust to be easily used on Windows. Better support for Rust means more developers will hop on supporting Windows.

I rather have the warm feeling that random app X won't snoop my user data files.

More seriously. Windows does not prevent me from using Win32 so no need to use ReactOS and I did not ever have a single customer complaint about not using UWP/.NET/WinRT/Whatever tech. So in my areas of business where it concerns desktop apps that "warm feeling" means zilch fro a practical standpoint.

https://blogs.windows.com/windowsexperience/2020/05/04/accel...

Apparently you aren't using OpenGL then,

https://devblogs.microsoft.com/directx/in-the-works-opencl-a...

My desktop apps that use hardware acceleration and I still care about are DirectX.

In any way keep reading news and adjust your stack and rewrite your applications every time MS sneezes. Good luck. I am pretty happy so far investing in features rather then rewriting.

Unlike Apple, Microsoft is dead serious on maintaining compatibility with minimal hassle.

Or OpenGL/Vulkan in Win32 or UWP sandboxes for that matter.

The only way to run Win32 on Windows 10X and possibly in future Windows 10 versions as well, even if it takes a couple of years more, just like it is happening with Apple and Google's platforms.

I can get around the fact that using rust sometimes feels like programming with one arm tied behind my back. The real problem is the ecosystem. I've hardly used rust enough to feel like I've got a really broad feel for the ecosystem, but the feeling I have at the moment is that its quite possible to hit deal breaker levels of problems when attempting to combine differing libraries into the same application. Particularity when one is using threads in an application. I needed to pass one libraries reference into a thread, where another library needed to have the instance used in a closure. It turned out to be impossible without either using unsafe code or adding additional traits to both libraries. A trick made much harder because I then had to wrangle cargo to pick up internally maintained versions of libraries instead of the main cargo repos.

So, I get the distinct feeling that rust is great if you can stick to a single threaded programs, or you don't rely on 3rd party libraries. Mix the two, and your in deep trouble.