
Rust/WinRT Brings Microsoft Closer to Adopting Rust Internally - yannikyeo
https://www.infoq.com/news/2020/05/rust-winrt-microsoft/
======
0x0
Imagine a world wide web where Microsoft buys Mozilla because of a programming
language they happened to develop.

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

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

~~~
ashtonkem
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?

------
pjmlp
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...](https://mybuild.microsoft.com/sessions?t=%257B%2522from%2522%253A%25222020-05-19T00%253A00%253A00%252B02%253A00%2522%252C%2522to%2522%253A%25222020-05-21T23%253A59%253A00%252B02%253A00%2522%257D&q=rust&s=%257B%2522name%2522%253A%2522translate.refine.label.sort.relevance%2522%252C%2522type%2522%253A0%257D)

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

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

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

~~~
yodon
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...](https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/)

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

------
dang
See also
[https://news.ycombinator.com/item?id=23033451](https://news.ycombinator.com/item?id=23033451)
from a couple weeks ago.

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

~~~
smt88
Just to be clear, you think that _adding support for another language_ is
Microsoft's attempt to _constrain_ Win32 developers?

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

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

~~~
FpUser
_" 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.

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

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

