Matthias: Welcome back to a fresh season of Rust in Production, a podcast about companies
Matthias: who use Rust to shape the future of infrastructure.
Matthias: My name is Matthias Endler from corrode, and today we talk to Victor Ciura about
Matthias: large-scale Rust adoption at Microsoft.
Matthias: Victor, thanks so much for joining us today. Can you say a few words about yourself
Matthias: and about Microsoft, the company you work for?
Victor: Hey, thanks for inviting me. I'm a principal engineer on the developer division at Microsoft.
Victor: Before coming to Rust, I spent over 20 years doing C++ exclusively systems programming
Victor: in general and developer tools, worked on various projects, including being
Victor: part of the Visual C++ team at Microsoft.
Victor: And in recent years, I transitioned to work on Rust tooling in developer division.
Matthias: We both met at Eurorost in 2024, and I really had a pleasant experience listening to your talk.
Matthias: It was very honest, brutally honest, let me say.
Matthias: And I really appreciated that. And at the same time, one could see that you're
Matthias: a very experienced engineer.
Matthias: So I'm really looking forward to that conversation today, because I think that
Matthias: we will not only talk about the highlights of using Rust in production,
Matthias: but also maybe some of the downsides.
Matthias: But before we start, there's probably a lot to talk about, but before we start,
Matthias: can you give us an overview and maybe an update of what happened since Eurorust 2024?
Victor: Yeah, definitely. So things in Microsoft, across all organizations in Microsoft,
Victor: Microsoft is a very big place, but things in terms of Rust have moved a lot in the past year.
Victor: And there's so many things brewing. Many of the projects are publicly facing,
Victor: so there's public knowledge, but many of the things we're working on are not
Victor: yet ready to be shared. So stay tuned.
Victor: More stuff is going to be made public this calendar year. But definitely a lot
Victor: of stuff has been going on.
Victor: So back then, we talked about a few of these early efforts with Rust across
Victor: the company, but I have a few more sort of that I wish I could spotlight here. There's,
Victor: All sorts of interesting projects, in my opinion, in my position in the developer division,
Victor: because we are tasked to improve the lives of Rust developers in the company
Victor: and improve developer tooling and sort of unblock them and make sure they're
Victor: productive and doing their best work across all the products and services we have.
Victor: But you can imagine, I hear from all teams across the company and they're either
Victor: telling us how they're using Rust and what they love about it,
Victor: but also complaining about stuff that doesn't work for them.
Victor: And, oh, they're so loud.
Victor: So my team specifically is tasked to make them productive and improve their lives.
Victor: So in this role and in this team, I hear about a lot of interesting projects.
Victor: So they all sort of fascinate me. So, and they're areas that I've never worked
Victor: in and they're so diverse in nature from firmware,
Victor: hardware stuff related to services and SDKs and all sorts of interesting things
Victor: that I've never worked with.
Victor: And now I get to sort of meet these projects and see how they're using Rust
Victor: and the kinds of challenges they're facing and their successes along the way.
Victor: So I wanted to maybe share some of these with you. yeah sure.
Matthias: Let's kick it off by highlighting some of the projects.
Victor: So there's there's work we've been
Victor: doing for example with TockOS
Victor: i don't know if people are familiar with probably your audience is
Victor: familiar with TockOS kernel which is written in in rust we've used this in
Victor: a project for what we call the microsoft pluton security processor we've done
Victor: some collaboration in open source here because we're using this and we've bet
Victor: on this one-source project.
Victor: And it's used in Surface PCs, and we're using this in collaboration with our
Victor: OEM partners as well as how we're building laptops and PCs.
Matthias: Just for the people who might not be familiar with TockOS,
Matthias: as far as I'm aware, and I'm not an expert on the topic,
Matthias: but I think it is a real-time operating system that is very low level,
Matthias: very close to the hardware and it's perfect for when you might need a very,
Matthias: lean runtime and you want to run certain,
Matthias: processes or certain tasks on top of that operating system, which more or less
Matthias: have to react to real-time data.
Victor: Exactly. And it's, for example, in the case of these Copilot PCs
Victor: where we need it, we're using the Intel Partner Security Engine there,
Victor: which is a specialized hardware for security on these devices.
Victor: And we bet on TockOS as a good fit for this.
Victor: And sort of that's how we ended up collaborating on this existing project,
Victor: which was an amazing project and was deemed as a good fit for this.
Matthias: And by collaborating, you mean contributing actual code to the project?
Victor: I can give you, it's a funny story. People think that 32-bit is by all means dead.
Victor: So many, many people don't even think in terms of, oh, do I need 32-bit or something?
Victor: So for this particular Intel chip that we use for this security thing,
Victor: it's actually, it needs 32-bit, right?
Victor: So we did work to port TockOS to 32-bit architecture. That's just one example.
Matthias: Is that already merged into mainline or what's the status on that?
Victor: I don't know. The PR is there, but I don't know if it's merged yet or not.
Victor: But it's definitely public.
Matthias: Wow. Okay.
Victor: I think it should be merged by now.
Matthias: Yeah, I don't know how many 32-bit devices are out there, but I would say there
Matthias: must be millions, probably billions of these devices.
Victor: Yeah, when you think about these specialized cards or specialized hardware that's
Victor: sort of connected to various other more complex infrastructure,
Victor: there's definitely still a need for 32-bit in some places, which people don't actually expect.
Victor: They like to think just in terms of ARM64 or ARM64.
Victor: Intel 64-bit architecture so.
Matthias: It's funny because if if
Matthias: i think of big tech like very large organizations
Matthias: sometimes i hear that it's easier for them to build their own little you know
Matthias: solution or proper solution for example google used that as an excuse to build
Matthias: fuchsia which is also written in rust they could also have contributed to an
Matthias: existing project but in your case for TockOS,
Matthias: you very much contributed to an existing open source project.
Matthias: Can you elaborate on that? Like what was the decision making process behind that?
Victor: So I think for many decades, Microsoft has suffered the not invented here thing syndrome.
Victor: And we tended to think we're the smartest and do everything from scratch because
Victor: we can do it better than anyone else. I think we're cured of that.
Victor: So right now we're very much in the process of looking
Victor: for what's best out there and if
Victor: that best in class in open source fits our needs and aligns in terms of roadmap
Victor: and what we want from it with our project needs and our roadmaps and if it if
Victor: we have this alignment then we're gonna bet on on open source very much the
Victor: the microsoft of today is about,
Victor: doing work in the open and leveraging work that is in the open source so both
Victor: consuming good quality libraries and projects and contributing back.
Victor: So if we don't find such a thing, we will start it, of course.
Victor: But in many cases, we find good projects out there that,
Victor: almost align perfectly with what we need, and then what's the point in reinventing the wheel, right?
Matthias: Yeah, true.
Victor: When we can improve it for everyone.
Matthias: Yeah, absolutely. You said TockOS was used in Surface devices,
Matthias: but isn't Surface a 64-bit device?
Victor: No, this is a specialized chip that's for the security processor.
Matthias: Ah, okay.
Victor: It's not the main integrated CPU.
Matthias: Okay, perfect. Yeah, so we already covered one very...
Matthias: Low-level project, one that is close to the hardware.
Victor: Another one was, and I think we did this a while back, is Project Moo,
Victor: where we did a Wifi implementation that's actually used in Surface laptops and even in Azure boxes.
Victor: So there's a custom Wifi implementation in Rust. And this is,
Victor: again, an open-source project.
Victor: People can actually Google for the GitHub repo for it.
Victor: We can probably.
Matthias: Link to it in the show notes i will.
Victor: Yeah i can provide you with a bunch of links to these
Victor: things then again if we're thinking about these kinds of things with we have
Victor: the calyptra project which is about harder root of trust foundation for building
Victor: more advanced security capabilities so again this is a fully transparent industry
Victor: collaboration effort where We're sort of contributing to this space.
Victor: And again, Azure integrated HSMs, this is Microsoft's new in-house security chip.
Victor: This is meant for isolating cryptographic keys in dedicated vaults. It's FIPS compliant.
Victor: It's about securing key exchange between Azure VMs and all these things.
Victor: So again, we're using Rust in all these security sensitive areas of our cloud
Victor: infrastructure, right?
Victor: If we're talking about hardware that supports the cloud and devices,
Victor: if we're talking about the hypervisors and the services themselves and sort
Victor: of how we're securing this trusted compute platform in the cloud.
Victor: So all across the board, from firmware and hardware and dedicated cards up the
Victor: software stack at all levels, right?
Victor: If we're talking about Azure Post Agents, where we offload on hardware cards
Victor: for managing Azure VM workloads and manage virtualization for storage and networking in Azure.
Victor: Even Hyper-V, right? Which Hyper-V underpins the whole Azure infrastructure for all the VMs, right?
Victor: If you think about classic Hyper-V has been written, I don't know.
Victor: 25 years now. I don't even remember. It was written in C++, right?
Victor: And still the bulk of it is C++.
Victor: But we're rewriting parts of it in Rust right now.
Victor: Either parts that we want to secure, so we want to sort of harden various parts
Victor: of the hypervisor, or we're rewriting new parts of it.
Victor: For example, the instruction emulation for ARM64 in Hyper-V is written completely in Rust.
Victor: So the whole hypervisor virtual stack and
Victor: even more and more components in hype or vr rewritten from
Victor: c++ to rust because we want to sort
Victor: of harden those components and and i think that's a
Victor: sort of a theme across microsoft
Victor: not just in azure but maybe azure
Victor: would be the most aggressive such organization in
Victor: microsoft was doing these rust rewrites but
Victor: in general we're we're on
Victor: the one hand trying to harden c++ because we
Victor: have a lot of c++ at microsoft
Victor: as you can like might imagine right the billions
Victor: of lines of code of c++ and and we need to harden c++ because it's not going
Victor: to go away anytime soon so we're investing a lot on on securing c++ both in
Victor: terms of tooling and how we're methodologies around writing c++ but especially
Victor: in terms of tooling and at the same time.
Victor: We're doing these tactical Rust migrations or Rust rewrites,
Victor: where we're identifying pieces of code or components that have been traditionally
Victor: targeted for vulnerabilities over the years,
Victor: sort of the most sensitive parts or things that have most CVEs or exploits that
Victor: were sort of memory caused by memory exploitations.
Victor: And we're just rewriting them in Rust to
Victor: secure them and to be able to prove their security as in not just oh oh it's
Victor: rust it must be secure right rewriting them in rust gives us ways to reason
Victor: about proving their their safety and and do all sorts of better analysis on it can you.
Matthias: Share any internal metrics about how security improved after rewriting parts of it in rust.
Victor: I don't have numbers on hand
Victor: but i've i've seen plenty of presentations coming out
Victor: of we have dedicated security teams in the companies that sort of analyze these
Victor: kinds of patterns across multiple organizations and projects and they regularly
Victor: post statistics so I've seen such presentations internally but I don't have numbers of them but it's.
Victor: People, in general, people tend to think, oh, this is anecdotal.
Victor: As you know, you're rewriting it in Rust and it will just magically be better.
Victor: And they sort of deride this thing. But we have hard data that shows that components
Victor: that have been rewritten are much more solid.
Victor: And we can actually even formally prove some of them to be memory safe,
Victor: both in terms of spatial and temporal safety.
Victor: And I've seen similar studies out of Google on their security blog as well about
Victor: providing statistical information to prove that these rights are improving the
Victor: overall security of systems.
Victor: And more interesting, what I've seen from the Google security study that I read
Victor: last year is that they noticed the incidents,
Victor: the security memory vulnerabilities decreasing just out of writing new components
Victor: in Rust without even needing to touch existing components.
Victor: Because the vast majority of exploits and bugs tend to be in recent code,
Victor: not in code that has been tested and tried and patched for decades, right?
Victor: Most vulnerable code tends to be the most recent code because it has been less
Victor: tested or less battle-hardened, let's say.
Matthias: Do you see the same pattern at Microsoft?
Victor: Yeah, we're seeing similar things. We're not sort of madly going across the
Victor: board and just like for the fun of it, Let's rewrite everything in Rust.
Victor: We're doing these sort of tactical choices where we say, okay,
Victor: this new component, it's better if we write it in Rust.
Victor: Or this component, we feel that by rewriting it in Rust, it will give us a chance
Victor: to rethink it, re-architect it, prove...
Victor: Different sort of pre and post conditions about
Victor: it sort of be be more deliberate and more precise about what we can prove about
Victor: this particular piece of code that we're rewriting so it's it's not sort of
Victor: a blanket statement that oh if we're rewriting everything everything will be
Victor: magically better right we're we're doing sort of very tactical choices here.
Matthias: Google came forward and I said 70% of their issues with code in general were memory safety issues.
Matthias: And I would assume that it's similar across different organizations.
Matthias: I might even remember that there was a similar study from Microsoft.
Victor: Yeah, I think I presented the slide on that at one or two of the conferences last year.
Victor: So it definitely we're seeing the
Victor: same thing as in memory safety dominates
Victor: all cvs across the microsoft so it's
Victor: definitely over 70 percent in microsoft the majority
Victor: so the majority are memory safety issues and all across the board from heap
Victor: corruption heap out of bounds step corruptions type confusions uninitialized
Victor: variables use after freeze all sorts of things so definitely we're seeing the
Victor: same kinds of things, right?
Victor: And in terms of mitigations, yes, like I told you, we're constantly developing
Victor: newer and newer technologies for C++ to address this.
Victor: But with Rust, you get most of these things out of the box, right?
Victor: Again, there's challenges even there,
Victor: but definitely in terms of memory vulnerabilities, we can do a lot better.
Matthias: Was Azure the first Rust project at Microsoft?
Matthias: Was Azure the first to adopt Microsoft?
Victor: I don't know for sure at this point. So very much when Rust started at Microsoft several years ago,
Victor: it was very much a sort of bottom-up thing where various teams or various enthusiastic
Victor: engineers tried out things, tried to rewrite various components,
Victor: for various reasons and claimed some results on them, as in, did it work?
Victor: What were the challenges? what didn't work, and so on. So it was very much sort
Victor: of an experimentation phase.
Victor: And then the following years, based on early successes, there's been a bunch
Victor: of incubation projects across the company in all organizations, not just Azure.
Victor: In Windows, in Office, in Azure, in M365, all across the company, really.
Victor: And I think we did this for a couple of years and sort of had various degrees
Victor: of successes and teams were,
Victor: I think the most impressive thing is that teams were super enthusiastic and
Victor: they felt the experience was,
Victor: in general, a win, right?
Victor: Even if maybe a particular project didn't get the green light to go forward, right?
Victor: If it was just maybe proving something or prototyping something or,
Victor: you know, not all projects get the green light to go ahead, right? For various reasons.
Victor: But even in cases where we just learned from a particular such instance or such
Victor: experience, teams were super enthusiastic and they felt like this could really
Victor: change something at Microsoft, right, in how we do software.
Victor: So after that incubation phase, we're sort of more and more projects started doing Rust seriously.
Victor: We have internal hackathons, right, a couple of times a year.
Victor: And we've long passed the phase where people enthusiastically,
Victor: let's try something or let's incubate this and see how it goes, right?
Victor: Right now, we're in a phase where Rust at Microsoft is taking really seriously.
Victor: And that comes with... So it's both good and scary at the same time, right?
Victor: It's good because that means more teams and developers are empowered to use Rust.
Victor: So it's no longer like sort of covert pirate operation to do something in Rust.
Victor: It's sort of applauded and encouraged when it's appropriate but it also presents
Victor: sort of a very high bar in terms of in terms of expectations right because very
Victor: very much across the company people are feeling that rust is,
Victor: has graduated to be a sort of a premier programming language, right?
Victor: And that means they have the same kinds of expectations from Rust that they
Victor: have from C++ and C Sharp and TypeScript internally,
Victor: as in those used to be traditionally the tier one, the premier languages in the company, right?
Victor: And now as Rust is becoming to be seen as a tier one language at the company,
Victor: all these developers who are getting more and more ambitious in building cool
Victor: stuff with Rust, they sort of have these high expectations as in because they
Victor: come from these worlds, they come from C++, from C Sharp,
Victor: and they expect developer tools to be the same kind of maturity, right?
Victor: So they expect their developer experience, their debugging experience,
Victor: their tooling, their infrastructure to be ready. So they have sort of all these
Victor: expectations in terms of where Rust should be, at least internally.
Matthias: I would assume that also very much depends on the project they are working on.
Matthias: For example, if I work on the Windows kernel, I have different expectations
Matthias: about my tooling than, let's say, if I work with cloud providers or cloud services.
Victor: Definitely, yes.
Matthias: Or do you see similar patterns even across low level and high level?
Matthias: Does it even matter where people use Rust?
Matthias: It has the same deficiencies across the board.
Victor: There are definitely things that are universal.
Victor: I mentioned this. Microsoft is very much a big place and various organizations
Victor: have sort of various internal protocols and specific compliance rules and specific
Victor: infrastructure needs and so on.
Victor: So while there are many commonalities, there's also very specific needs based on project, right?
Victor: And I would say if the Rust likes or sort of,
Victor: let's say, enthusiasm for Rust is maybe the universal thing across Microsoft organizations,
Victor: like everyone loves fast dev compile time iterations, as in if it compiles,
Victor: it most likely works to that kind of feel.
Victor: Or if it's easier to write tests, people will write more tests, right?
Victor: Or be more encouraged to write a lot of tests.
Victor: And the richness of the ecosystems and libraries out there, memory safety guarantees
Victor: that we talked about earlier, and even data race-related concurrency bugs that
Victor: you can reduce with this.
Victor: So sort of the things they love seem to be sort of universal. Yeah.
Victor: And performance, right? Let's not forget that many of the people who are coming
Victor: across in the company are coming from garbage-collected programming languages like C-sharp, right?
Victor: So they like the native systems programming language feel and deterministic
Victor: distraction and snappiness of Rust CodeGen.
Victor: Although the likes are almost universal across the company, the dislikes are
Victor: very much specific on whichever team, what problem they face most, right?
Victor: Or what they struggle with. For
Victor: example, in terms of infrastructure and compliance and security promises.
Victor: There's sort of a common bar across the company, but some organizations have
Victor: more stringent rules in terms of what they need to prove about the compliance
Victor: and security of software issue, right?
Victor: So this is where engineering systems need to work to fill in the gaps,
Victor: as in we've worked for decades to implement all sorts of workflows and engineering
Victor: systems to deal with C++ codebases and C Sharp codebases or TypeScript codebases.
Victor: And we built all sorts of tools from static analysis to checkers to binary tools
Victor: that check various promises and guarantees about the produced binary artifacts
Victor: or binary hardening tools or all sorts of,
Victor: we have a plethora of tools internal that we use online.
Victor: In gen engineering systems. And as you can imagine, a lot of these are sort
Victor: of not there for Rust, right?
Victor: They either don't exist altogether or they just fall flat on their face with
Victor: Rust-generated code, right?
Victor: So we sort of need to fill in these gaps or improve existing tools if there are any, right?
Victor: For example, let's see, static analysis, right?
Victor: But there's also lots of tools at binary level.
Matthias: So do the different teams even share that feedback with one another?
Matthias: Say, for example, someone at Azure finds a great tool.
Matthias: How do you share that internally? You probably have some sort of Microsoft Teams
Matthias: channel or multiple even about tooling for Rust.
Victor: So there's two things that run back.
Victor: So yeah, definitely we have a thriving Rust-Aceans community inside.
Victor: So we actually have internal forums and Teams channels for Rustasians across
Victor: the company where we share sort of learnings from each other. We ask questions.
Victor: We sort of discover things we share. So that's sort of a community sort of things.
Victor: We have many, many, many Rust developers internally who are discussing all sorts
Victor: of interesting stuff there from sharing pieces of code or asking for help or
Victor: sharing a tool or asking about something.
Matthias: Just roughly how many people are in these channels?
Victor: It's it's it's in the thousands i think i haven't
Victor: looked in a while but it's a lot of people it's like
Victor: always generates a lot of noise
Victor: in those channels a lot of discussions every day but going back to your original
Victor: question so that's sort of for for sharing and guidance and asking and discovery
Victor: so there's sort of these internal communities are amazing right and i've learned
Victor: so much from just being in those threads.
Victor: But going back to your original question in terms of tooling and engineering
Victor: systems, that's a totally different story.
Victor: That's not where something happens randomly.
Victor: So we have dedicated engineering systems teams inside the company,
Victor: and we have policies across the board where a team cannot just build something
Victor: the way they like to build it, right?
Victor: There's there's policies and
Victor: and specific rules about how you
Victor: set up infrastructure how you set up pipelines how
Victor: what kind of tools and tasks you run and
Victor: how you do all sorts of processing and audits on on on the build systems so
Victor: there's there's a big branch of engineering systems in the company who's responsible
Victor: in supporting all the programming languages that are used in all projects across
Victor: the company regardless of the organization right so.
Matthias: Can you share a few of the best practices that might be helpful for people outside
Matthias: of microsoft maybe general things that you found out about how to set up a project in rust.
Victor: Oh, there's a, that's a, I think we need more than an hour just for that.
Victor: So there's, hopefully, what we are doing internally is that we're setting what
Victor: we call paved paths for various programming languages, right?
Victor: There's paved path for C++ projects, paved path for C Sharp,
Victor: paved path for Rust. We're building one right now, right?
Victor: Where we're setting up workflows and templates so that people don't have to
Victor: do these kinds of setups manually for each project, right?
Victor: Because you don't want to end up with snowflakes across the company that are
Victor: slightly configured slightly differently, or they're using slightly different things, right?
Victor: So we want very much to standardize best practices.
Victor: So we have pipeline templates, we have
Victor: project templates, we have sort of infrastructure tasks that are shared.
Victor: So it's not a manual bring up process.
Victor: And that's why sort of it's such a high bar to make Rust a sort of a tier one
Victor: supported language in the company because there's so many of these things that
Victor: we need to make sure they're right for prime time and they satisfy the needs
Victor: for all the projects, right?
Victor: Because this is very much a unified rollout, right?
Victor: Regardless if we're talking about secret scanning or static analysis or.
Victor: Any kind of SDL requirement in terms of security analysis or any kind of binary
Victor: checks that we're doing on software and so on.
Victor: So there's lots of such tools and policies, and they all need to be uniformly applied.
Victor: As in, when a new Rust project becomes online in the company,
Victor: it needs to have this proper setup, these pipelines, these templates in place
Victor: in terms of engineering systems and infrastructure.
Victor: It's one thing to start something sort of as a hackathon project and sort of
Victor: build something and share it with a few other colleagues in a team, right?
Victor: As proof of concept, when you build it, that's sort of a different story.
Victor: But when you sort of promote it to this is now a project that is proper project
Victor: in the company, then it needs to be sort of integrated in this engineering system.
Matthias: I can see how this can work for a microservice environment where,
Matthias: for example, you build a new Azure component or so.
Matthias: You have a bootstrapping system for that. But I wonder how it works on the lower level layers.
Matthias: For example, in one of your talks, you mentioned that you chose direct write
Matthias: as one of your first Rust experiments.
Matthias: Experiments and direct write is like a text layout and rendering component that's
Matthias: that's used across windows and office and you mentioned that it has a com-like
Matthias: interface so it has this component object model interface and i wonder if you
Matthias: can even have some sort of bootstrapping pipeline for this when when you start such a project yeah.
Victor: That that's actually a very good segue, I wanted to mention this,
Victor: not all of these things happen as greenfield projects or some perfectly isolated
Victor: thing like, oh, I'm going to extract this new functionality or this new component.
Victor: And it's so nice and pristine and I can, it's self-contained and it has everything
Victor: you need and I can test it.
Victor: It's rarely the case that something is so nicely cut away from everything else, right?
Victor: Sometimes you need to work on something that's highly intertwined or has tight
Victor: integrations into something bigger, right?
Victor: So then it becomes more challenging how you're doing this bridge,
Victor: how you're doing these migrations becomes challenging how you're testing it,
Victor: how you're doing infrastructure for it, definitely, right?
Victor: So just for for your audience
Victor: here in case they don't know you mentioned earlier
Victor: direct write this is a sort of a full stack text
Victor: analysis framework it handles layout and rendering for text textual output right
Victor: so it does font shaping and all those things and it it's it ships in windows
Victor: so it's a it's a dll in windows it it's even cross-platform part of it which is direct write core.
Victor: And this is the part that was rewritten in Rust. It's actually cross-platform, right?
Victor: For example, Office components depend on direct write core and Office is cross-platform, as you know.
Victor: So, and I believe we did this rewrite about four, maybe five years ago,
Victor: maybe four, if I remember correctly.
Victor: So indeed, this component uses com-like interfaces. You mentioned this earlier.
Victor: And this sounds potentially like a scary thing, but it actually can be very
Victor: helpful in terms of when you're doing these gradual rewrites.
Victor: Because one of the biggest challenges we're seeing for gradual Rust adoption
Victor: in Microsoft is challenges around interop, and specifically interop with C++.
Victor: And I sort of wanted specifically to spend
Victor: some time to talk about this because it's such a such a
Victor: big and challenging topic and and but in
Victor: terms of components that have these nice com-like
Victor: boundaries it's actually although it
Victor: might sound scary it's actually a blessing because it provides the natural surface
Victor: separation between worlds that you want to bridge right and and com is sort
Victor: of the grandfather of all interop technologies so it's it's been
Victor: solving interrupt problems for, I don't know, 40-plus years now.
Victor: So it actually allows for gradual rewrites and gradual migration and how you're
Victor: doing this carving out, like, to do incremental porting.
Victor: So that actually turned out to be a good thing, right?
Victor: And Rust code is directly callable from app code through home interfaces.
Victor: And you have this sort of almost natural separation that was provided architecturally beforehand.
Victor: But testing is not easy, right?
Victor: And specifically for this component, for the direct write, I can give you some numbers here.
Victor: I was looking now. So the ported code was about 150,000 lines.
Victor: And it was pretty much a sort of natural translation, like from C and C++ to Rust.
Victor: It didn't require a major re-architecting or rethinking of the component.
Victor: It was fairly straightforward.
Matthias: Work that's nice because one thing that
Matthias: a lot of people cherish about microsoft and
Matthias: windows is that there's such a long guarantee
Matthias: for backwards compatibility so you basically don't ever break apis if possible
Matthias: and i i imagine that might be super hard if you do a translation from c++ to
Matthias: rust for example you need to make sure that all of the invariants are upheld
Matthias: while you do the sensation it's.
Victor: It's very hard and i
Victor: would say the bar is even higher than people
Victor: expect because in general people expect that the contract is the api that you
Victor: provide and say okay this is the api and if the api offers the same guarantees
Victor: we can change the implementation however we want right and nobody will be affected.
Victor: In reality, sometimes, not always, but sometimes it's even worse than that.
Victor: As in, even when there's detectable change in behavior, even if it's not enforced
Victor: by an API contract, some people get angry, right?
Victor: And when I say some people, I don't mean people outside the company,
Victor: as in even internal consumers, right, of various components,
Victor: right? If there's a behavior change that they ended up depending on,
Victor: even if it was sort of out of contract, right?
Victor: But if, you know, Hiram's law, as in if somebody, someone somewhere can take
Victor: a dependency on some observable behavior from your component,
Victor: they will, right? It's a statistical fact, right?
Victor: And by the sheer scale of Microsoft and Windows in general, you will end up
Victor: with components that will rely on out-of-contract behavior from various other components.
Victor: And if you change slightly that behavior, they will complain.
Matthias: Do you have an example for that?
Victor: Not on top of my head, but it's not just isolated cases, right?
Victor: There's many such cases where,
Victor: you end up making a change and somebody gets mad at you.
Matthias: Yeah, I would assume, for example, if you have a library like DirectWrite or
Matthias: GDI, which is the graphics device interface, which goes back to the 80s and
Matthias: early 90s, you also mentioned that in your EuroRust talk if you have such an old components,
Matthias: the side effects even become part of your ABI.
Matthias: Exactly. Yeah, even just the runtime of a certain function might have an impact
Matthias: on your call, on your system. Yeah.
Victor: When we're talking about this, and for GDI, we're talking sort of late 80s,
Victor: early 90s kind of thing, right? It was designed for 286.
Victor: That kind of time thing. So when you're talking about these kinds of components,
Victor: and if you imagine how many
Victor: millions of lines of code use those those
Victor: apis and in in what weird
Victor: ways they've been used and abused because i think
Victor: the word means sometimes abused not used you will
Victor: end up breaking someone so yeah it's it's
Victor: highly critical to make sure that these changes
Victor: do not sort of upset the existing ecosystem and
Victor: for windows there's a very high bar in
Victor: terms of how they're testing stuff not just oh
Victor: we can do test units on this functionality and
Victor: all test units passed and
Victor: we're good ship it it's not like
Victor: that so building the whole like every change
Victor: sort of you need to build the whole operating system you need to pass a enormous
Victor: stress test suite of stuff so it's like it might be sort of record-breaking
Victor: stuff in terms of the amount of tests and stuff that that you need to wait for
Victor: to make sure that Everything just works.
Victor: All sorts of high-level, low-level integration tests, real workloads, all sorts of apps.
Victor: Windows tests tons of apps, and they automate all sorts of workflows through
Victor: those apps, even apps that are super old.
Victor: So you wouldn't believe the high bar of what it means to change something in Windows.
Victor: And especially in a component such low-level as GDI, for example.
Victor: You can break so many things.
Matthias: Especially with those old components like GDI, people will probably find new
Matthias: ways to make unsafe calls and maybe try to break it.
Matthias: Maybe sometimes intentionally, sometimes not intentionally, but just trying to achieve their goal.
Matthias: And they make calls which maybe...
Matthias: Original authors haven't anticipated and i'm thinking
Matthias: this is probably where rust can help you and you allured to that in in a talk
Matthias: where you said the more code you ported to rust the less unsafe code you need
Matthias: could you walk us through that journey like why is that a thing well.
Victor: Yeah because when you when you start sort
Victor: of cutting up pieces that you start rewriting
Victor: you need to interact with the old code because you
Victor: it's a sort of a sometimes even
Victor: catch-22 problem but anyway even if it's
Victor: not a circular thing you still need to call the old
Victor: code let's say c old c code or old
Victor: c++ code and that is sort of on the
Victor: untrusted boundary so when you have like a little
Victor: bit of rust and 98 is
Victor: still the old code sort of your your your unsafe surface is ginormous So you
Victor: need to have a lot of sort of sprinkling unsafe and sort of crossing the FFI
Victor: boundary and doing some really unsafe interrupting because most of your surface is unsafe.
Victor: But as you're doing this gradual process of rewriting more and more code in
Victor: Rust, then this unsafe boundary reduces over time.
Victor: So you sort of have it less and less and less unsafe parts until you sort of
Victor: ideally achieve the total rewrite of that component.
Victor: And then you sort of have these.
Victor: And even if you end up consuming some unsafe bits, you can at least provide
Victor: the safe wrapper around it.
Victor: If let's say maybe there's a last 2% that you can't get rid of for some reason.
Victor: I don't know. You can at least wrap a safe projection around the unsafe part
Victor: that still remains and provide some precondition or sort of assertions about
Victor: how it should supposed to be used in contract so that it still is sound, right?
Victor: Even if underneath is unsafe in some way. So, yeah, this is sort of a general
Victor: trend you see when you're doing this kind of C or C++ to Rust migrations,
Victor: as in the more you do, the less unsafe you need.
Victor: And since you mentioned unsafe, sort of a common misconception that people have
Victor: is that, oh, in many situations, because we're now talking about sort of low-level
Victor: code and you want to sort of have...
Victor: Access, sort of intimate access to hardware and high performance and all this
Victor: good stuff as in close to the metal kind of thing in systems programming.
Victor: They just assume like, of course,
Victor: that's why they've been using C and C++ because that's what you get.
Victor: You get the sharpest tool, the closest to the metal, the highest there is, right?
Victor: And when you're doing this in Rust, then the expectation is that, oh,
Victor: I'm going to need to do a lot of unsafe rust because i
Victor: need to talk to hardware i need to do a lot
Victor: of unsafe things i'm clever here and
Victor: systems engineer and do all sorts of dangerous things so it's expectation that
Victor: you're going to write unsafe rust which is not the case or they expect that
Victor: oh you're going to need to write a lot of unsafe rust to be as performant as
Victor: c or as performant as c++ on when And you're doing that rewrite and say,
Victor: I need to touch pointers.
Victor: I need to do the unchecked thing because it's faster.
Victor: This is a misconception in most cases.
Victor: What we've seen is totally the other case, as in many situations,
Victor: we're getting actually better code gen out of the compiler when we're writing
Victor: safe abstractions, the equivalent safe abstractions.
Victor: Because the compiler can have more guarantees about what's going on in your
Victor: code in terms of aliasing, in terms of interf, in terms of how that code is structured.
Victor: Whereas if you're writing a lot of unsafe, all bets are off,
Victor: as in the compiler needs to be conservative and not as aggressive in what it
Victor: can do in terms of code movement and optimization.
Victor: So in many situations, the preconception of let's throw a lot of unsafe here
Victor: because we're coming from C++ anyway, and we want to have the raw hardware performance,
Victor: we've seen the total opposite. Yeah.
Victor: We're very much recommending that people are using safe Rust and not reach out
Victor: for unsafe because it's an easily available escape hatch, right?
Victor: Because sometimes it's actually worse.
Matthias: Well, there's another large project that is very close to the hardware,
Matthias: which is currently trying to adopt Rust.
Matthias: And that is the Linux kernel. And, you know, on the mailing list,
Matthias: you can see this play out a little bit nowadays, where you have a lot of infighting
Matthias: between very experienced, longstanding developers.
Matthias: And on the other side, you have these people who want to try the new,
Matthias: who want to have safer interfaces.
Matthias: Do you see similar patterns at Microsoft?
Matthias: We have a lot of infighting between older, more senior kernel developers and
Matthias: people that maybe want to introduce Rust just because they think,
Matthias: you know, it will improve the situation in the future.
Matthias: But I guess short-term will also incur a maintenance overhead because you have
Matthias: to keep the Rust interface and the C or C++ interface in sync.
Victor: So I'll preface this with the fact that
Victor: I'm not directly involved in the Linux and Rust
Victor: in Linux project but in terms of what I'm seeing in
Victor: Microsoft I would say there's no such polarization that I'm perceiving again
Victor: I'm not part of the Windows team I just collaborate with a lot of people from
Victor: there because I'm in the developer division and they use our stuff so I'm not
Victor: in I'm not a kernel developer there.
Victor: So again, it's sort of semi-outsider opinion, right?
Victor: But definitely what I'm seeing internally, I don't see this strong polarization and,
Victor: Yes, you have in the company, you have your Rust enthusiasts and evangelists
Victor: who are sort of trying to convince everyone that they should do everything in
Victor: Rust because they're so enthusiastic and it's been so successful for them and their projects.
Victor: So they're genuinely trying to help everyone.
Victor: And sometimes they can be a bit overwhelming.
Victor: Thing and what i see is in general when you reply a lot of pressure automatically
Victor: you get some resistance right from people even if they don't have sort of strong
Victor: counters they don't like that you're coming off strong so they would just naturally
Victor: resist so but i definitely don't see.
Victor: Polarization as such as in people are
Victor: genuinely looking at stuff on face
Victor: value as in does this thing help me right does
Victor: it make the component better does it improve security
Victor: of this thing does it if we're
Victor: talking about coming from c and c++ to
Victor: rust it's really the case that they're after extra performance right because
Victor: they already have the performance side of the story they're mostly interested
Victor: in can i improve the ergonomics of the code can i improve the security of the
Victor: code so it's very much about can i secure this component can i reduce my headaches right Let's.
Matthias: Say I wanted to start a new project in C++ in 2025 at Microsoft,
Matthias: would that raise some eyebrows?
Victor: There is no company-wide mandate of banning new projects using C++ or even C for that matter.
Victor: It's maybe frowned upon if I were to put a label on it,
Victor: but there's no sort of mandate as in if you're starting something new,
Victor: you better not touch C++. There's no such thing in the company.
Victor: There is a strong mandate of that in Azure and in highly security-critical areas, right?
Victor: If you're thinking maybe security modules cryptography those sorts of things and.
Victor: Hypervisor things highly sensitive areas of of cloud infrastructure right on
Victor: those areas yes there is sort of a mandate for memory safe languages right and
Victor: in many situations rust is the only one that fits the bill in terms of being
Victor: memory safe and performant in other the situation,
Victor: C-sharp fits the bill just fine, right?
Victor: So depending on the kind of workload, but there's no such thing as in across
Victor: the company, you're not supposed to write new stuff in C and C++.
Victor: And there's statistically, because just of the size of the stuff around,
Victor: as in there's more C++ code being written every day than Rust code.
Victor: Just imagine the scale of Microsoft product. So...
Victor: The quantity of Rust code increases exponentially in the company,
Victor: there's so much C++ in the company that a new code that is written or fixed
Victor: or improved in those components will need to be C++, right?
Victor: So, and it will take a while between this will ever change, right?
Victor: Just imagine the billions of lines of C++ there in the company.
Matthias: It's kind of crazy to think that Rust's growth is exponential at Microsoft.
Matthias: That's kind of a positive.
Victor: I'm not casually calling it that way. So being in the developer division,
Victor: I'm sort of, my team is in a unique position to see this firsthand because everyone
Victor: sort of comes to us when they have a problem.
Victor: So developer division is tasked to prove the tools and create the tools to help
Victor: developers across the company be successful.
Victor: So based on how I see requests coming in and the conversations I'm part of and
Victor: the investments that I'm seeing across the board in terms of supporting these
Victor: tools and infrastructures,
Victor: this is the only natural conclusion you can draw, right?
Victor: Because I think we reached an inflection point in the company where we're all in on Rust, as in,
Victor: we're committed to making Rust succeed at Microsoft because we've seen so many
Victor: successes in various projects and teams are no longer sort of treating it as a hobby experiment,
Victor: a happy accident that this thing works great in Rust. No, they're seeing it as...
Victor: On this thing. We're betting on technology, on this technology,
Victor: we're betting on this language, we're betting on the community of libraries out there and so on.
Matthias: So your team has to make sure that Rust projects at Microsoft are set up to
Matthias: be a success, at least from an infrastructure perspective.
Matthias: What are the top three things, or tooling perspective, sorry,
Matthias: what are the top three let's say issues that people come and approach you with
Matthias: and why is number one compile times?
Victor: Well, yeah. Well, people coming from C++ don't complain about compile times.
Victor: Let me put it this way.
Victor: So only people coming from C Sharp and the net complain about compile times.
Victor: C++ people are used to getting their coffee or reading the Reddits where they compile.
Victor: No i would say top things
Victor: number one meeting compliance and
Victor: security promises and that ties into our earlier conversation about engineering
Victor: systems and missing tools and improving the guidance improving the templates
Victor: improving the security checks there's a lot of things that are missing i can't
Victor: talk about the details of many of those things because they don't make sense outside of Microsoft.
Victor: And also, they're not public tools, many of them. They're used in internal infrastructure.
Victor: But we are leveraging external tools when they make sense inside the company, right?
Victor: Even, for example, for static analysis, we're using Clippy and compiler links.
Victor: We're investing in CodeQL for Rust and so on.
Victor: So there's many, I would say, in the engineering systems and compliance area.
Victor: That's sort of top concern because many projects are sort of ready to go into
Victor: production and they're blocked in such sort of compliance stages where they
Victor: need to check some boxes so that they can go in production, right?
Victor: And so maybe number two would be interop.
Victor: I would say, again, I mentioned this earlier, in order for us to succeed,
Victor: you need to have a good bridge for C++ developers.
Victor: But even for C-sharp developers, we're not talking just interrupt with C++,
Victor: we're talking even interrupt with C-sharp in some scenarios. So...
Victor: Story the interop story needs to be ergonomic needs to
Victor: be low cost and needs
Victor: to so in interop it's many things again if you
Victor: tend to talk to a particular kind of project you will find sort of maybe some
Victor: requirements that they have for interop but again at at the scale of microsoft
Victor: and how diverse the projects are across the board depending on who you talk
Victor: to they will tell you different things when they mean interop, right?
Victor: Some teams care a lot about high fidelity language interop, right?
Victor: And some teams care a lot about sort of the glue code and the automation of
Victor: generating the glue code for the interop.
Victor: Other teams will say, oh, I have this enormous API surface and I just don't
Victor: want to duplicate these 10,000 functions that I have in C++.
Victor: I don't want to have them on the Rust side as well to check in two versions
Victor: of the functions in the repo, right?
Victor: So I want some compiler magics or metadata to generate those stuff for me without
Victor: me having to check them in.
Victor: So other teams care less about the language interop part and more about the binary interop aspect.
Victor: Because again, depending on the kind of project you're talking about,
Victor: some projects are big monoliths that compile everything from source.
Victor: So we have just one ginormous binary at the end.
Victor: Other projects are very much a mix of multiple shared libraries, right?
Victor: And many, many projects in the company are very much in this...
Victor: Bucket of DLLs kind of thing, right? And there you need to properly handle interop,
Victor: even as you might have a DLL written in C++ and a DLL written in Rust and the
Victor: process written in Rust and they need to talk to each other, right?
Victor: And they're not always sort of leaf dependencies.
Victor: Sometimes there may be more complex interactions between them.
Victor: So very complicated challenges around dynamic linking, right?
Victor: Challenges around ABI stability and the fact that it's clunky for Rust to provide
Victor: any kind of ABI stability and resilience.
Victor: `repr(c)` just isn't an ABI story, let's face it.
Matthias: What's missing? I'm not an expert in that area, but what else do we need other than `repr(c)`?
Victor: I did a talk at Rust Nation UK last week. an hour long talk about ABI resilience
Victor: okay I will listen to that one if I can use this opportunity to plug that of
Victor: course whenever it becomes available on YouTube yeah we will link to it in the show notes,
Victor: so I guess I don't want to do it injustice here in just five minutes awesome
Victor: but in general sort of going down to C as your,
Victor: FFI thing in many situations is fine as in,
Victor: dumbing down your interfaces and your intro player to just C and C-like types,
Victor: it might be fine for many projects.
Victor: But in some scenarios, when you have fancier vocabulary types and you're actually
Victor: using C++ and you're not in the bucket of saying,
Victor: oh, it's a C++ project, but it's actually a C project with some C++ constructs in it, right?
Victor: So if you're actually using vocabulary types that are sort of richer from the
Victor: C++ language or on the other side from the Rust language,
Victor: you don't want to sort of have a sort of common denominator and go through C
Victor: and sort of dumb down your interface and make them way less expressive and ergonomic.
Victor: So that's why it matters.
Matthias: When I think of interop, I also think of the OS interop side of things.
Matthias: For example, path handling or string handling and so on.
Victor: That's another business, string handling. You mentioned that.
Victor: Oh, that's such a big can of worms in Windows.
Victor: It's a bit more civilized on the Linux side of things, but on Windows, it's a nightmare.
Victor: And just the plethora of types of strings and how they're represented and their
Victor: encodings and what APIs expect,
Victor: it's just bites people a
Victor: lot and and sometimes they even attribute string
Victor: handling to interrupt costs because they don't
Victor: realize that crossing these intro boundaries sometimes you require that you
Victor: represent strings differently and then you're paying a cost for this translation
Victor: so they're not sort of zero cost interrupt abstractions so it is it's it is
Victor: painful and again it depends on your project.
Victor: If your project is very much sort of low needs in terms of boundary interaction,
Victor: your interfaces are sort of low levels C-like things and,
Victor: you might get away with simple automation and simple tools like BindGen,
Victor: C-BindGen and do your FFI even manually. I've seen people do manual FFI and
Victor: be just happy with it, right?
Victor: But if you have fancier things and more complex APIs and your interrupt surface
Victor: is larger, then even tools like CXX will not cut it.
Victor: People struggle. So we need to do better.
Victor: Not just in Microsoft. As a community, we need to do better.
Victor: We need to sort of build better tools here.
Victor: Because I believe the success of Rust very much depends on if we can build these
Victor: bridges that are easy to cross from C++ or from C Sharp in our case.
Victor: And I didn't even talk about build systems. As in another thing,
Victor: sort of top problem here is fitting cargo in existing build systems.
Victor: Right how do you fit cargo in let's say
Victor: you have an an a cmake project that has
Victor: all sorts of components and you want to fit in some rust component in
Victor: there and fit the cargo build with the cmake build or
Victor: you might have in our case we have a lot of ms build based projects right that
Victor: are building c++ or c sharp solutions and you want to fit in cargo with the
Victor: build system make sure that everything works properly dependencies cleanup caching
Victor: infrastructure everything that entails from that and that people expect to just work, right?
Victor: It's a big challenge and i think making rust
Victor: succeed we need to check all these boxes not just developers
Victor: are already sort of enthusiastic about the language itself and
Victor: the problem it solves from them right we just
Victor: need to solve the tuning right because there's
Victor: sort of it's a it's it's an enthusiasm ramp
Victor: as in they're super excited and they do they
Victor: want to do stuff and they build their prototypes and they they
Victor: they show some wins either performance
Victor: or security or whatever they're super excited and then they face this roadblock
Victor: of oh now i need to make it work for real as in i need official pipelines i
Victor: need tooling i need checks i need whatever and then frustration starts just staying up.
Matthias: To date with that incoming stream of changes is even hard.
Matthias: That's also why you need intro, why you need code generation and so on,
Matthias: because a lot of people, they don't really know how large Microsoft is.
Matthias: For example, I think we talked earlier that Windows, the operating system,
Matthias: gets around 1,000 pull requests a day, and that's like a huge scale that you're
Matthias: operating on, so you cannot manually do all of these things.
Matthias: You kind of need tooling for that.
Matthias: I wonder, so if there was someone listening right now and they were thinking
Matthias: about how to help you in an let's say in a product kind of way would there even be,
Matthias: a chance for them to sell microsoft a tool for example i don't know a private
Matthias: registry or a better code generator or a better search engine for Rust code
Matthias: would you even be interested in any of these products or do you have a product
Matthias: in mind that you would encourage people to build that could be useful outside of Microsoft as well?
Victor: So I believe in, and it's not just my opinion, it's how we see things for Rust in Microsoft.
Victor: Sure, we're building, I mentioned earlier, we're building a lot of sort of stuff
Victor: in terms of tooling that makes sense for engineering systems and sort of solve
Victor: our particular needs internally and they don't make much sense for everyone else.
Victor: But when we see an opportunity that something that we're building for internal
Victor: needs makes sense for other teams as well as which are outside of our engineering
Victor: systems, outside of our company, we very much contribute to those projects.
Victor: Like I mentioned earlier with some of the examples I gave in when I highlighted projects,
Victor: think the key here is not building products and and sort of building better products that we can,
Victor: license or leverage or whatever i think we need to move the bar in terms of
Victor: the community as in each company when it sees an opportunity to improve something
Victor: if it makes sense to improve it for everyone that's what should be doing and
Victor: that's what we're doing whenever we see a gap in an open source tool,
Victor: we do the work in open source to improve it.
Victor: When we see a gap in the compiler and in Rust Projects itself,
Victor: we have a lot of Rust Project contributors working in Microsoft.
Victor: And we love to do all that work in upstream because who would want to maintain a private fork, right?
Victor: So everyone benefits if we're doing this. And we're not the only ones, right?
Victor: All the big companies who are betting on Rust and they need a lot of similar
Victor: things internally for their engineering systems, they end up doing the work in open source, right?
Victor: Either spinning off new projects or new open source things or contributing to
Victor: existing open source projects. And that's what we're doing as well.
Victor: So I think the secret sauce here is pulling resources together and sort of working
Victor: so that everyone can take them further.
Matthias: Is the opposite also true where you adopt a product that might be mature and
Matthias: you integrate it into your build process if it makes sense?
Matthias: Do you have examples of maybe tools that are missing right now that people could
Matthias: build and maybe productize in the Rust space?
Victor: I think we need more investment in static analysis for Rust,
Victor: And I'm seeing an opportunity there. And we have good stuff already,
Victor: but I see an opportunity to invest more.
Matthias: Shouldn't Clippy solve that?
Victor: Yes, but we need more checks. Yeah.
Matthias: More checks.
Victor: So it's, and again, it's a perfect example where it's an open source project. Everyone benefits.
Victor: Checks are opt-in, so you're not disturbing anyone, right? So anyone who can
Victor: contribute more stuff there, I think it's a win for everyone.
Victor: And dynamic analysis and projects like Miri, for example, it's another area
Victor: where I think we can invest more and everyone would benefit.
Matthias: I truly believe that Miri also has potential to be maybe a part of a larger product.
Matthias: You say that this is a great feature, but again,
Matthias: you probably want to have a thing that takes care of this, a platform that you
Matthias: can point people to and say, look, we degraded in that certain metric,
Matthias: or can you take a look at this specific thing?
Matthias: And when people use Tokyo in production, that might also be an issue where,
Matthias: you know, maybe you have a race condition that is very hard to find.
Matthias: Maybe there's a tool out there that could analyze that and highlight that issue for you.
Matthias: There are tools like this for the Go ecosystem, for example,
Matthias: which just don't really have them in Rust.
Victor: And another thing where we're actively trying to drive community work is the
Victor: language itself and stabilizing things.
Victor: We see a lot of internal teams who are enthusiastic about particular functionality,
Victor: either a tool or some language or library thing, but it takes a long time to stabilize them.
Victor: So in general, we want to discourage people internally to be on nightlies,
Victor: aside from experimentation, of course.
Victor: So anything production needs to be on stable Rust.
Victor: But we see a lot of things and sort of themes
Victor: excited about either something in library space or some particular tool,
Victor: sometimes even language constructs, but mostly tooling and library stuff.
Victor: And they say, oh, this is only nightly and I can't go in production with it.
Victor: And maybe we're actively working here to drive some of the stuff that we care about.
Victor: But I think in general, as a community, is more deliberate paths to moving proposals
Victor: along and sort of stabilizing stuff that's been true or stuff that has been
Victor: vetted in industry that works,
Victor: not just on our side, but many other companies were sort of vetting the stuff
Victor: and say, okay, this works for us.
Victor: Sort of making, maybe making more deliberate push to stabilize stuff.
Victor: Because there are some things that have been in Nightly for years and nowhere near stabilized.
Matthias: I completely understand what you mean here. A lot of, let's say,
Matthias: really helpful features are stuck in Nightly or even in the RFC stage or somewhere
Matthias: in between. So, yeah, I fully understand.
Victor: But work doesn't get done by itself. So we need volunteers to drive these things.
Victor: And we're trying to do our part as best as we can.
Victor: But the more people are reviewing PRs and RFCs, the better.
Victor: So it's a community effort. It truly is.
Matthias: True. Anyhow, we're getting close to the end. So it's not all flowers and roses, obviously.
Matthias: But it feels like, in general, what would you say? How would you summarize Rosted
Matthias: Microsoft in the beginning of 2025?
Matthias: What would be the mantra?
Victor: It's the, no bullshit about it.
Victor: It's literally what we're calling it inside, at least on my team,
Victor: who's responsible to drive this, is 2025 is the year of Microsoft,
Victor: the year of Rusted Microsoft.
Victor: So literally this is what we're calling it.
Victor: It's the year where we need to solve enablement across the board for Rusted Microsoft.
Victor: So we're all in on making that happen and providing all the tools and filling all the gaps.
Victor: So although it's a lot of work and not to lie, it's not easy and a lot of moving
Victor: pieces, people are very excited about this.
Victor: Both teams who are waiting on us to deliver the stuff that we promised.
Victor: But even on our side, we're super excited to unblock all these teams because
Victor: I'm looking at the projects and I'm seeing internally using Rust.
Victor: I can't but get excited I see all this interesting stuff going on and it's just
Victor: a shame to see them block on some missing tool or something that just doesn't
Victor: really work for them and I want to solve that problem,
Victor: I very much see myself as unblocking them to do really cool stuff Can you give.
Matthias: Us a quick teaser maybe of a thing that is on the midterm horizon that people
Matthias: might be looking forward to?
Victor: Debugging Rust on Windows will become really better.
Matthias: Wow, that's good to hear.
Victor: And maybe that's because it really sucks right now.
Matthias: That's what I meant with honesty in the beginning. Yeah, I appreciate it.
Matthias: So it feels like Microsoft is all in when it comes to Rust.
Matthias: Definitely. So you're kind of making it succeed.
Matthias: Or I would say, could you say Microsoft devs love Rust? could you say that.
Victor: All the devs that
Victor: i talk to love rust because they they come to
Victor: us for rusty things so they
Victor: they're all super excited and they love it there's there's no rust haters at
Victor: least not that i'm seeing everyone that comes to us they they come with passion
Victor: and they want they want us to help them so.
Matthias: Traditionally our last question is what's your
Matthias: message to the rust community could be anything about the community about technology
Matthias: i mean you have a very strong c++ background you told me that you go to cpp
Matthias: conf almost like since the very beginning if i'm.
Victor: Not mistaken so.
Matthias: Maybe maybe this would be an interesting angle to come from to say okay from
Matthias: your personal perspective as someone who is very involved in c++ and has a lot
Matthias: of experience what would be your message to the rust community it's.
Victor: A message both for rust community and for c++
Victor: community it's in order for us
Victor: to succeed c++ does not
Victor: mean it has to die so it's not
Victor: a zero-sum game it's very much about many many
Victor: years from now where we need to learn to coexist both
Victor: in terms of software interop and
Victor: in terms of community interop so i think
Victor: my message would be let's spend more time on improving these bridges and and
Victor: making sure the languages work well together so that we can successfully have
Victor: this and as communities learn to collaborate better. Awesome.
Matthias: Yeah, I would love to see that. Victor, thanks so much. I really appreciate
Matthias: you taking the time today. Thank you so much.
Victor: Thanks for having me. Bye-bye.
Matthias: Rust in Production is a podcast by corrode. It is hosted by me,
Matthias: Matthias Endler, and produced by Simon Brüggen.
Matthias: For show notes, transcripts, and to learn more about how we can help your company
Matthias: make the most of Rust, visit corrode.dev.
Matthias: Thanks for listening to Rust in Production.