Microsoft to explore Rust?

btw, it’s awesome that MIRI catches this particular UB:


I’d say yes and no, unsafe Rust is most of the time safer than C but it can be more dangerous. The good thing is that you know where to look for when there is a problem.

Immutable to mutable reference:
see @AndrewGaspar’s example

Clippy and Miri catch it but the compiler doesn’t complain.

Borrow checker taking a nap:

unsafe fn into_static<'a, T>(input: &'a T) -> &'static T {
    &*(input as *const _)

You can also make out-of-bounds access, use after free,…


Jinx! :slight_smile:

1 Like

Oh definitely! I forgot about Poe’s Law there for a bit! :blush: Clarifying R.E.S.F. approved joke alert applied!

1 Like

FWIW, Microsoft is already using Rust in production.


More on this:

I sure do hope Microsoft adopts Rust on a major scale.

This could carry Rust into a main-stream adoption sphere and firmly establish it as a credible C++ alternative for all future systems software development.
I have been waiting for a long time for this.

I do wonder if Google and AWS are interested in Rust on a major scale, they also have an awful lot of C++ in their software stack.


Good point (although that repo's build badge says it's failing.., which doesn't inspire immediate confidence on how critical they treat it...)
Let's also not forget that Visual Studio Code's search is powered by ripgrep.

Still, these kinds of usage are still very.. conservative.. Small aspects or experiments, not going anywhere near the "crown jewels".

I'm dreaming of something like "here is the officially supported Rust kernel binding, please write your next printer driver or network stack in Rust", or "we got sick of all the exploits in our font-handling, so we rewrote that core part of Windows with Rust"

Firefox Quantum shows that these kinds of gradual, but impactful, oxidations are doable, if you really go all-in.

That is the kind of things I'm hoping Microsoft will realise too.
Such a vote of confidence by such an influential player would firmly catapult rust into the "majority" section of the innovation adoption curve".
The need for this has been on my mind ever since this particular "imagine Rust failed" scenario embedded itself in my brain's fear-cortex. :fearful:

Yes, it is possible. But you have to do all of it very much explicit. You may also literally put inline assembly in Rust, but it doesn't make rust "Asm with some fancy features".

All big companies that I know of which adopted Rust, did so for new projects or rewrites of crufty components in existing projects.

In Google's case, for example, Rust is used in the Fuschia R&D (among many other languages). I assume that the way this R&D will pan out will, at least in part, determine the wider future of Rust in this company.

Firecracker was developed at Amazon Web Services to accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate. Firecracker is open sourced under Apache version 2.0.


This made me want to take a step back and look at the timeline of "company uses Rust in production"-related milestones I could remember off the top of my head:

May 2015 - Rust 1.0
Jul 2016 - Firefox's first Rust code in production
Sep 2016 - the "ripgrep is faster than..." blog post
Mar 2017 - VSCode adopts ripgrep for search
Aug 2017 - Firefox ships Stylo
Oct 2017 - Chucklefish uses Rust and does an AMA (and yes, I'm aware they no longer use Rust for staffing reasons)
Feb 2019 - npm rewrites authorization service in Rust
May 2019 - Firefox ships WebRender MVP
July 2019 - Microsoft strongly implies interest in oxidizing Windows

My mind is just blown by how far Rust has come in so little time. :heart_eyes:

We've been stable for just over four years and "are they actually going to rewrite the Windows kernel in Rust?" is officially not even a crazy question to ask now (even if that probably is slightly overhyping this blog post).


That would have been a great place for it, but they already re-wrote that part in one of their other safe languages.

1 Like

part 3 of the blog

part 3 of the series FYI

Interesting comment:

While researching Rust, we found some issues that gave and continue to give us pause. Some of these concerns include how to regulate the usage of the “unsafe” superset of Rust at scale, lack of first-class interoperability with C++, and interoperability with existing Microsoft tooling. We’ll be blogging about many of these in the future as they do pose challenges for adoption at the scale of Microsoft, and we want to involve the Rust and wider software communities in helping us find solutions that work for everyone.

But we’re excited about the possibilities. While there are many questions still left to figure out about how Rust fits into the overall Microsoft engineering story, we encourage others to join us in taking a serious look at the language for their systems programming needs.

I agree that C++ library-ecosystem-interop is critical for Rust future adoption if it is to become C++ replacement (a question: is plain ANSI C ecosystem interop from Rust good at present time?).

Let me mention Kotlin as an example. Kotlin JVM offers 100% Java JVM ecosystem interop, which allows very easily to code in Kotlin and re-use all existing Java JAR libraries.
It also allows Java coders to call Kotlin JAR libraries.

I realize Rust is very different to Kotlin but the success of the language today is about peaceful/easy coexistence with the dominant ecosystem.
For Kolin JVM this is Java world.
For Rust is must be C++ and C world.


In the reddit thread for this post, someone mentioned something important, not even C++ has complete C++ interop. This is due to different compilers/versions using different ABIs. This means that the entire C++ project must be built all at once, and dylibs must be built with the exact same compiler. This makes it very hard for even C++ to interop with C++. Introduce a new language, Rust, and it becomes nigh impossible. (Rust has the exact same issues regarding ABI, different versions of the compiler may have different ABIs)

Going through C is the best way to interop with other languages, and Rust's C interop story is very good. So I think we are good enough with regards to FFI for a while.


re this:

Going through C is the best way to interop with other languages, and Rust's C interop story is very good. So I think we are good enough with regards to FFI for a while.

This is very good to know, thank you!

As a (very new) big fan of Rust.
I would say that Rust community should get the giants like Microsoft, Google, Amazon, Facebook etc to work on these issues. I am far from a language lawyer, just a humble programmer.
I do realize that C++ interop is super-hard but I also suspect things could still be improved to allow some sort of C++ interop, even if it's via a C-ABI-API gateway/bridge or via some other technique yet to be invented.
Where there is a will, there is a way. I always try to remember that "perfect is the enemy of good".
There may never be a perfect C++ interop solution but perhaps Rust could have a good-enough solution to solve a significant proportion of the use cases?

Microsoft appears to have extended their arm of friendship to Rust, a significant new step to help Rust well deserved adoption in mainstream. I see Google and Facebook starting to use Rust too, I am sure there is a lot of brain power there to help improve the current situation.

1 Like

For Windows programming, I'd be more concerned about COM interop than C++ interop. COM has a stable ABI, works between many languages including C++ and C#, and it's used for a bunch of stuff in the OS.

Fortunately, there are efforts to implement good COM interop in Rust, like bindings generation.


100% C++ interop (probably even 20%) would drag all the serious issues C++ has, which are reason people look into replacing it. In my opinion this is not a goal worth pursuing.
Kotlin is nice, but it can't be anything more than nicer syntax for Java. The need of compatibility prevents it from fixing anything else. Sometimes you have to start with clean slate.


The only hiccup is this issue. Basically MSVC++ uses a slightly different calling convention for some methods.

1 Like

It's unlikely, especially in Windows which is famous for being bug-compatible 30+ years back, that any major component is going to get from-the-ground-up total rewrite. This is a huge old codebase.

In such places the easiest way to adopt Rust is to do it gradually. Keeping existing project exactly as-is, and using Rust only for new functions and refactoring of the old code bit by bit.

It does mean that the project initially retains 100% of C++'s problems, but at least it can start using Rust right away, reduce risk for new code, and maybe eventually refactor C++ out.

For C that has been done successfully for librsvg. I've also done it for lodepng.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.