Rust Is Tier-1 Language at Microsoft
62 points by mmastrac
62 points by mmastrac
Rust still isn’t widely used at Microsoft from what I’ve seen, but hopefully that changes. I am in Azure Storage and write C++ every day. It would be nice to start using Rust within that giant C++ project but the FFI part of things was fairly complicated last time I tried it. Especially when interacting with old Microsoft-isms like COM.
I was a coauthor on Microsoft's technical strategy document that recommended Rust. Our actual recommendation was:
So hopefully adding new Rust bits to your project will be easier in the future a result of C++/COM interop work. But the 'is your team happy with Rust?' check may still be an obstacle. There was concern that experienced C++ programmers writing C++ would probably produce better code than experienced C++ programmers writing Rust, but that's a slow transition.
The thing I really, really wanted was to stop people writing high-level application code in systems-programming languages. Please just don't do that. Application-programming languages are really good now. Using a systems-programming language to write applications doesn't make you a Real Man™, it makes you a person who uses a screwdriver to hammer in a nail.
The thing I really, really wanted was to stop people writing high-level application code in systems-programming languages. Please just don't do that. Application-programming languages are really good now.
Please point me at an "application programming language" that has all of
I don't love systems-programming-as-machoism either, but I think the counterreaction to it is also largely a C-ism.
I honestly don't know any high-level language that I'd consider even competitive with Rust from a pure programmer happiness/joy perspective. Maybe one day C#/.NET will catch up with cargo/rustdoc/rust-std, but given that they have a quarter century of not even trying… I don't see why anyone would get their hopes up now.
I honestly don't know any high-level language that I'd consider even competitive with Rust from a pure programmer happiness/joy perspective
yeah, for my projects, the "systemness" of Rust is often a bad match. But even aside from cargo, everything else about Rust makes it such a joy to use (types, concurrency, good compiler errors, great docs, etc.) that I will happily use it even if it is not intended for what I'm using it for, like high level application code.
Rust's systemsy focus does sometimes get in the way, too, and I have dreamed about "Rust, but with a GC" (and no other weird caveats, like bad docs, small ecosystem, or rough tooling). But the systems focus of Rust has also nerdsniped me (prior to Rust mostly writing Python) into being more interested in systems programming in general.
I'm not even sure Rust-with-a-GC makes sense, honestly. A lot of Rust's more unique features that app code also benefits from (controlled mutation, thread safety) are built on the borrow checker, and if you need to satisfy the borrow checker anyway then you've already paid the costs of RAII so you might as well use it.
*nod* I'm always reminded of boats's Notes on a Smaller Rust:
Here are the necessary components of Rust to make imperative programming work as a paradigm. Shockling few other production-ready imperative languages have the first of these, and none of them have the others at all (at least, none have them implemented correctly; C++ has unsafe analogs). Unsurprisingly, the common names for these concepts are all opaque nonsense:
- “Algebraic data types”: Having both “product types” (in Rust structs) and “sum types” (in Rust enums) is crucial. The language must not have null, it must instead use an Option wrapper. It must have strong pattern matching and destructuring facilities, and never insert implicit crashing branches.
- Resource acquisition is initialization: Objects should manage conceptual resources like file descriptors and sockets, and have destructors which clean up resource state when the object goes out of scope. It should be trivial to be confident the destructor will run when the object goes out of scope. This necesitates most of ownership, moving, and borrowing.
- Aliasable XOR mutable: The default should be that values can be mutated only if they are not aliased, and there should be no way to introduce unsynchronized aliased mutation. However, the language should support mutating values. The only way to get this is the rest of ownership and borrowing, the distinction between borrows and mutable borrows and the aliasing rules between them.
In other words, the core, commonly identified “hard part” of Rust - ownership and borrowing - is essentially applicable for any attempt to make checking the correctness of an imperative program tractable. So trying to get rid of it would be missing the real insight of Rust, and not building on the foundations Rust has laid out.
-- https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/
...plus, as someone who's still in an "I was using an AMD Athlon II X2 270 from 2011 until the end of 2023" mindset, I don't even like current efforts to make use of Rc/Arc more ergonomic, because I worry it'll lead to a "D is de-facto GCed because too much of the ecosystem relies on the optional GC"-style rise in inefficiency in dependencies I need. (Just because the only known way to achieve certain tasks currently is a code smell doesn't mean you should desensitize people to the smell across the board.)
Aliasable XOR mutable: ... The only way to get this is the rest of ownership and borrowing
That post seems not to consider that references (and thus aliasing) could be omitted from a language, as in "mutable value semantics". (I use Rust far more than any mutable value semantics language.)
I think that only post-Cargo languages (Elixir, Gleam, Zig) do even try.
On the other hand, Python (uv), Ruby (rv) also got the niceties in… Maybe it's cultural, yeah.
I'm aware I'm in a small minority but to me, Rust tooling feels kinda immature whenever I get into non-trivial scenarios while .NET tooling works great for me and seems quite a bit more flexible than Cargo et al.
I think Cargo largely-intentionally deprioritizes flexibility in favor of polishing what is intended to be the common case, and I think that common-case polish is what its admirers tend to be appreciating.
At least in my experience there are very few working programmers in my org that know rust. I want that to change! (I also want them all to know TLA+!)
Difficult problem to solve, but at least pointing to directives from higher-ups like Mark Russinovich can help.
Whoa, now. Just because they write buggy code is no reason to sic the Three Letter Agencies on them. ;P
What's your take for people (me) who have to maintain large legacy codebases? Lots of people use NumPy and it continues to be written mostly in C. We have vague plans to use C++ more but even then not modern C++. Is it even possible to modernize at that scale?
It is, we’ve seen modern C++ adopted in code bases that are primarily C, adding type-safe APIs alongside the legacy ones (which become wrappers for the new ones), incrementally. Doing the same with Rust is a bit harder, but the long term payoff may be higher.
Rust<>C interop is pretty good, and it's relatively easy to start writing Rust inside a C codebase.
After thinking about it a fair bit, I still think good C is possible. Despite the tooling and the culture encouraging all the wrong defaults, with the right tooling and attitude, quality C without UB or memory bugs is, I think, not impossible.
Obviously, I don't think Microsoft can pull it off, but that's besides my point.
I suspect that this becomes impractical once your program reaches a certain size.
The truth is, the whole approach is impractical in general. The easy way out is Regehr's proposal for a "friendly C". And I like the idea. It could solve a lot of problems.
Since that's not a thing yet, doing it by discipline is tedious, logic-bug prone, and unperformant. It's UB-free, but the code is neither fast nor pretty.
But hey, it's C. It compiles everywhere, it's well standardized, its memory footprint is still small, and my personal favorite, you can learn and internalize all of it.
It'd also be interesting to see how much can be achieved with rigorous use of splint. It's had a lot of Rust-like checks sitting behind a suite of increasingly gnarly annotation comments since the early 2000s.
I haven't reached the bottom of its rabbit hole, but it looks like they might have implemented some kind of formal specification language in C comments. (So far, I mostly use it to implement the newtype pattern in one of my on-hold Open Watcom C/C++ DOS retro-hobby projects with careful use of preprocessor directives to hide near/far from it.)
At the moment, it's primarily for new projects or for rewriting specific self-contained parts of a larger system. I suspect first-class FFI with C++ (and C#) is the next big thing for Rust to tackle to see wider usage in existing systems, in or out of Microsoft.
As for COM, in my limited experience, consuming COM from Rust is surprisingly easy, unlike direct interop with C++.
Hey it’s the hackathon next week, maybe I can convince some people to try rewriting a small component in rust!
Am I missing something or is there no link to more information about this new codegen? It's not so much "Introducing rustc_codegen_utc" as "Announcing rustc_codegen_utc".
Yeah, I was wondering this too. Searching "rustc_codegen_utc" doesn't result in anything relevant other than this blog post, too. I wonder if and how this will be released to the public.
In the Rust Zulip discussion for this blog post they said they have no plans to open source rustc_codegen_utc.
This is not exactly accurate, original Zulip comment from Radim (manager on the codegen_utc project):
Announcing the work on the backend is the first step. There are no concrete plans what and when will be open sourced. However, the work we'd start with upstreaming is shared test and backend-infrastructure work.
I left the team a few months ago so my info might not be up to date but at the time, the team was generally in favor of open-sourcing the project, both for practical (less downstream churn) and philosophical (giving back to the community) reasons, but we did not have a specific timeline. Can't promise anything specific since there's a non-trivial cost to open-sourcing but it's something that was somewhat actively discussed.
That’s disappointing. It would be an interesting target for other compilers that want Windows support and native tooling like debuggers and linkers.
Does it address the linking speed issues one typically has in large Rust projects?
Not surprising, given that msvc itself isn't open source. But r_c_utc could get "released to the public" without being made opensource, just like msvc is.
I guess there isn't much point unless they're also going to open source MSVC (which, IMO, is something they should do too but I'm sure its a lot easier said than done)
Not necessarily:
I recall Rust MSVC codegen being mentioned a year or so ago, but nothing since until this post.
It's tragic, but illustrative of a serious problem in our industry, that there's a "Help Fund the Maintainers Behind Rust" banner sitting atop an announcement that Rust is a tier-1 language at a company with > $70 billion cash on hand.
I wonder how they got a react element in the start menu. https://winaero.com/windows-11-start-menu-revealed-as-resource-heavy-react-native-app-sparks-performance-concerns/