Rust/WinRT Brings Microsoft Closer to Adopting Rust Internally | Hacker News Reader

Rust/WinRT Brings Microsoft Closer to Adopting Rust Internally

infoq.com

106 pointsyannikyeo46 comments

Imagine a world wide web where Microsoft buys Mozilla because of a programming language they happened to develop.

Mozilla doesn't develop Rust. Mozilla developers are involved in Rust's development but that's not quite the same thing.

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

I think Canonical will be the next major "earth-shattering" acquisition that Microsoft makes. Ubuntu is so widely deployed as the defacto Linux OS everywhere from Linux CI images, AWS instances. Azure. After IBM bought Red Hat it seems like there's a run on owning the Linux "ecosystem", even if you can't own the code. Microsoft is demonstrating that they want to own the new world of development/deployment ecosystem end-to-end. Github, VS Code, NPM.

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.

What a brilliant move for Ms to acquire canonical and then fund the crap out of it

I think that would get a pretty close look from the justice department.

Would it? I don’t believe that Canonical is anywhere close to dominating the Linux space, and MS is continuing its slow slide from total market dominance.

Under what theory would the justice department interfere?

Be careful, a lot of people do not like that idea. The last time I mentioned it I was downvoted deep into the negatives.

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

If Ballmer were still in charge they would have just outbid IBM for Redhat.

BUILD 2020 is taking place this week, there are a 4 Rust related talks:

- 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...

Does Microsoft even use WinRT "internally"? Back in the day, e.g. Office would simply ignore all DevDiv and WinDiv bullshit and roll its own frameworks and even _custom controls_ libraries.

https://github.com/microsoft/calculator :) Not sure if that's RT though. There are so many Windows frameworks.

Checking out the bugs, it’s hilarious. You’d think it’s simple enough to get right. Crash on copying value, a bug waiting on triage for three months. Not exactly an endorsement

That stacktrace... https://github.com/microsoft/calculator/issues/1063#issuecom...

WinRT isn't really a framework, but more like a "shape" of API/ABI, like C calling conventions or COM. Most Windows APIs added in the last ten years or so have been WinRT based.

Office absolutely makes use of all sorts of Windows APIs including flat C APIs, COM APIs and WinRT APIs. The Office Win32 apps recently moved over to using the WinRT Windows.UI.Composition APIs for their composition layer, for example.

If you're racing to hit a deadline, you don't want dependencies on other teams.

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.

Did excel not even use any math libraries? Seems kind of silly to re-create that wheel, espically when we've proven that many of our algorithms are mathematically impossible to improve, and excel is so heavily focused on math work.

You might enjoy this [0] post on a bit of the history of Excel math libraries

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

I did enjoy that! Thanks for sharing, it was really interesting.

Better roll their own OS then. And then their own hardware and semiconductors as well.

Seems to be working for Apple.

Yes, React Native for Windows uses WinUI, and Office is their biggest customer.

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

See also https://news.ycombinator.com/item?id=23033451 from a couple weeks ago.

So they're giving another candy, this time to developers who like/want to use Rust. Not bad for them.

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.

Rust with win32 has worked for years.

Did I say it does not? I think you've completely missed my point. By the number of downvotes it seems you are not alone. So maybe I was not clear enough.

Perhaps my answer didn't even suggest you did :) I don't even know any more.

Well Microsoft has learned their lesson this time when they missed out on the smartphone industry and they are coming after winning back developers; and it seems to be working, especially when you give them "free stuff".

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.

Just to be clear, you think that adding support for another language is Microsoft's attempt to constrain Win32 developers?

I am asking you not to distort a context. That is not what I said. But just in case let me repeat it: Microsoft was for years and still is trying to move people from Win32 to a more constrained platform by using various means.

You're thinking of UWP apps, which used to only allow winrt APIs, though nowadays UWP app can also access most of win32 APIs as well. UWP is more about the distribution model than the APIs (apps must be signed, are usually installed through the store, etc...)

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...

"UWP app can also access most of win32 APIs as well"

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.

UWP apps run in a sandbox and have their own limits, e.g. most win32 api access requires special entitlements to work. WinRT is just a set of COM-based APIs, they don't inherently have any restrictioms on where or how they can be used.

Well, you are free to switch to ReactOS in that case.

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

I can donate abacus to you. Just let me know where to mail it.

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.

So I have news for your, not only is Win32 sandbox a thing, it is part of Windows 10X experience which uses sandboxes for everything, and Windows 10X is also coming to a laptop near you in the future.

That's a big if and a big when.

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

Kind of, try to run MS-DOS, Windows 3.x or some Windows 32 bit software on Windows 10 64bit Pro to see how far you will go.

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

I run OpenGL just fine in win32. Also have Vulkan based app (not my own) and runs just fine. Do not give a flying hoot whether it runs under UWP as I would not touch it with a wooden pole.

Win32 sandbox!

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.

Well, I have news for you too. Windows 10X is specialized edition of Windows and is not meant as a replacement for Windows 10. MS is not planning for it to displace regular Windows versions. Also while running win32 apps in a sandbox all the win32 API's (at least the ones I am concerned about) are still available. There will be no need to change anything. It is basically more or less analog of Linux containers. You are free to spread your "news" to other people. To me it looks like worrying about non existing issue.

Not paying attention to the news are we?

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...

The OpenGL/OpenCL to DX12 layers are for when vendors don't want to implement such a stack or to ease migration. For example, Qualcomm doesn't implement OpenGL or OpenCL on their Windows drivers at all.

Nope, there is zero support on Win32 sandbox and UWP, ICD drivers aren't allowed.

I already said Vulkan and OpenGL apps are not mine. I just use those. How their vendors going to deal with is not my concern. I am pretty sure they will have dealt with the issue by then.

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.

I might have to see if the winrt bindings are better than the generic rust ecosystem. I think the idea of rust is a good one, but the language isn't really something I would ever recommend for a professional project at this point.

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.

Reply on news.ycombinator.com