Program management update — February 2026

Mar. 27, 2026 · Tomas Sedovic, Nurzhan Saken on behalf of the Program team

Program management update — February 2026

Greetings! This update is brought to you by Tomas Sedovic and Nurzhan Saken \o/.

Hello from Nurzhan

I discovered the Rust Project in 2022 and quickly became obsessed. The language, the documentation, tracking issues, changelogs, blogs, talks, and user/contributor discussions — all of these scratched an itch and comforted me during a difficult period in my life. As a huge introvert, I mostly observed and didn't participate, so the job posting for a program manager felt like a wake-up call. Tomas put it well in his first update: I had to apply despite many doubts about whether I would actually do a good job; the regret of not going for it would have been devastating.

TC and Joel Marcey interviewed me in March–April 2025 and considered hiring me. This was a surprise because I felt like a total mess! Alas, you may know from the previous update that things didn't go as planned, and I didn't end up getting the position. Still, there was no going back, so I started engaging with Rust by stabilizing multiple features I was interested in. Eventually, more funds did get allocated, and I was hired.

The first month felt surreal. Suddenly, the imaginary barrier vanished, and I found myself sharing spaces (and even interacting) with the people whose work I had admired so much. Tomas had been leaving behind some impressive footprints, seemingly impossible to match. It was easy to feel like there'd been some mistake, that I didn't belong. Yet, everyone has been so welcoming. Tomas has been going out of his way to talk to me, support me, and loop me into everything happening in the Project. Thanks to that, I already feel mostly integrated, well-equipped, and really lucky that things have turned out this way.

Project goals

February was focused on getting through the proposed goals and having teams look at them. We are currently at 0 open pull requests (with huge help from Nurzhan), and we incorporated the sizing and champion feedback from the teams looking at the goals.

Each goal typically has one or more asks for Project teams (e.g., Lang, Compiler, Libs), so it is important that they review all their asks, see whether they're clearly articulated, and determine whether the proposed changes make sense in the Project.

In March, we'll do a final pass over the individual goals to make sure they have the right champions and sizes. After that, we'll open an RFC listing all the proposed goals and get feedback from the teams.

That is an important time because, until now, goals were considered mostly in isolation. But with the RFC, we'll be looking at the full picture as teams consider their overall capacity for the full year.

We aim to have the RFC reviewed in March and officially start the new goal period at the beginning of April.

We also discussed the way we do Project goal updates. The current auto-generated blog posts leave a lot to be desired, and we're interested in your feedback!

If you've read them previously, and especially if you haven't, we'd love to hear from you! What's helpful? What isn't? What would you like to see vs. what might be distracting?

We're talking to the Content team about ways to highlight specific goals in individual posts or interviews. We're also looking at making the updates more meaningful. Hearing your perspective here would be valuable! You can tell us on the Blog post thread on Zulip or DM the T-program alias.

Here are the recent blog posts we've published:

Program management tracking

Given that there are now two people taking on the program management work full time, we created places dedicated to that.

First, we have a backlog/board where we will track our work. Any issue from any rust-lang repo can be added there.

Since some topics won't fit into any of the existing repositories (things like scheduling the signing & mirroring meetings or writing the monthly PM update come to mind), we also had the program-team repository created. It can also house any documentation and tooling related to the effort.

Finally, you can now use the T-program alias on Zulip to talk to us, tag us on a thread, or make a request.

We're hoping this will make it clearer how to reach out to Program management, provide greater transparency (to show what we're actually working on), and, of course, help us (the PMs) coordinate better.

As of this writing, the repo and board are both empty. There are a few issues in other repos that we can link there, but mainly, Tomas needs to move the contents of his Rust org-mode file over.

C++/Rust interoperability

The Foundation hired teor for a short-term contract to speed up the mapping of the interop problem space, and they hit the ground running.

teor read through all the existing documents that we had, created a template for each issue / problem statement (e.g., exceptions & unwinding or incompatible allocators), immediately started documenting the known ones and filing issues for the various use cases that projects integrating these two languages have.

They're posting weekly updates on Zulip and monthly ones in the Project goal tracking issue.

These updates and the focus on mapping out the technical aspects are a result of feedback provided to the Foundation by the Project members and the wider community (directly, as well as indirectly, e.g., through Project Directors and Program managers).

If this is an area you're interested in, please take a look at the interop-initiative and the t-lang/interop Zulip channel.

Signing and mirroring

Following up from January, Walter Pearce proposed a draft of the Project goal. It focuses on building an MVP that sets up a mirror for Rustup targets. This would happen fully on the backend (and should therefore be completely transparent to any users) to look at bandwidth and logging cost reduction, stand up the security infrastructure, and get hands-on information to build the ultimate solution.

We've added a few more people to the group (e.g., Rustup folks), and the draft is under active discussion. There are still questions to resolve both on the technical and communication sides, but the proposal seems to be in a solid place, and we hope to have a PR open soon.

Style

For the last several months, a lot of the meetings ended up canceled. At the end of January, I scheduled a new time with a fortnightly cadence, and we've met two times since.

In the first one, we triaged all the nominated issues. Recognizing the capacity issues (the Style team has three members, and lately, one of them has not been able to dedicate a lot of time), TC proposed we focus on getting things unblocked while leaning on others.

So, when an issue comes in, the Style team considers it, figures out where it fits within the existing guidelines, and then asks the submitter for a concrete proposal instead of writing it all down themselves.

This practice is similar to how the Lang team operates.

The last two meetings felt much more productive that way, but the capacity issue remains. We need help!

If you're interested in how the language is formatted — providing input on what rustfmt should do — we would love to have you! You can join the t-style channel or attend one of our meetings.

Rust for Linux

We discussed the Rust for Linux roadmap and went over all the other unstable features the project is tracking that are not part of a particular goal. These are to be tracked in the roadmap, and we'll be spinning up goals where that makes sense.

There is an important milestone of sorts for Rust for Linux: the upcoming Debian 14 Stable release (codename: Forky). The version of the Rust toolchain provided by Debian Stable releases is what Rust for Linux currently uses to decide which minimum version to support. For instance, assuming Debian Forky releases around Summer 2027 with, say, Rust 1.104.0, then Rust for Linux will be able to use the new (and possibly unstable) features available in that version when the kernel's MSRV is bumped some time after Debian's release.

Rust for Linux supports a range of stable toolchains, each having access to a subset of unstable features (some of which the project depends on). This creates compatibility issues whenever the same functionality appears in different forms across the supported toolchains. For example, a feature may be unavailable in the oldest version, unstable in a newer one, and stable in a later one. Some of these issues can be handled at build time (e.g., when a flag is changed from -Z... to -C...), but others require non-local conditional compilation (which means maintaining parallel codepaths). The former tends to be easier to deal with without an MSRV bump, but the latter is much harder, and raising the MSRV in those cases has the potential to eliminate a substantial compatibility burden. To avoid particularly heavy maintenance costs, the team may choose to wait for the next MSRV before adopting a new feature at all.

With that in mind, we looked at features with the most significant impact that Rust for Linux wants to start using as soon as the next MSRV upgrade becomes possible. Some of the most notable ones are:

In general, Rust for Linux wants to start using new language capabilities (especially those with new syntax) as soon as the MSRV allows, since supporting both old and new forms across the toolchains can become burdensome, and delaying adoption may also lead to large-scale refactoring later. If the new syntax can be hidden behind a macro, that is usually acceptable. Likewise, using an unstable feature is acceptable so long as there's a reasonable expectation that it will be stabilized in roughly that form or at least won't be removed. For example, immovable types could supersede Pin, leading to massive syntactic changes. A special case is in-place initialization: the team has a working solution for the underlying problem, with a potential path to integrate with the eventual language feature, so its absence is less blocking than field projections, which doesn't exist in any form yet.

Rust for CPython

At the beginning of February, we invited Miguel Ojeda (the Rust for Linux lead) to share insights from his team's experience introducing Rust into the Linux kernel.

Miguel went over the rough timeline of Rust for Linux: the effort gained traction in late 2020, leading to an RFC in early 2021. Minimal experimental support was merged into mainline in late 2022, and the experiment concluded in late 2025. Collaboration with the Rust Project began around 2021 and transitioned to regular meetings in early 2024.

When the project started, there was skepticism around introducing Rust into a mature C codebase. C had long been the main language used in the kernel, and there had been resistance to adopting additional languages (e.g., C++ was briefly experimented with in 1993 before being abandoned). There were concerns about the downsides of moving to a two-language codebase and the need for developers to learn a new language and toolchain with benefits that were not yet clear.

The team spent a lot of time discussing these concerns with maintainers and contributors on mailing lists and at conferences, as well as following public discussions and the news to understand how they could communicate better. In 2025, Miguel presented a keynote showcasing what kernel maintainers, team members, stakeholders, and companies had thought about Rust for Linux at that year's FOSDEM event.

In the RFC Miguel proposed, they were honest about the advantages and disadvantages of Rust. A lot of the kernel experts thought that memory safety was the main appeal, but the RFC highlighted benefits beyond that: a clear separation between safe and unsafe code (with the former having no undefined behavior, memory safety violations, or data races), useful language features (rich enums, pattern matching, modules, hygienic macros), and powerful integrated tooling (rustfmt, rustdoc, lints). The RFC presented a port to Rust of the Android Binder IPC mechanism as its initial use case, and the resulting feedback led to the first hardware drivers being written in Rust (such as a translation of a GPIO one with a line-by-line comparison with the C implementation).

The team prioritized raising the bar on the quality of Rust code and documentation, e.g., requiring SAFETY comments around each unsafe block, consistent code formatting, and fully documenting all public APIs. Over time, the Rust experience also benefited the C side. For example, reviewing C code to design Rust abstractions sometimes uncovered issues that had gone unnoticed. More generally, the team has observed Rust concepts starting to percolate into the C side in discussions and designs; a recent example is the discussion around Revocable for C.

All of this strongly resonated with the CPython developers, who saw very similar reactions to their proposal and are facing similar technical challenges. Emma Smith, who leads this effort along with Kirill Podoprigora, mentioned that the Rust for Linux proposal was a huge inspiration for them to start this effort for CPython.

The Rust Project is happy to see cross-pollination in this space, and we'd love to see (and help!) more projects adding Rust to existing code.

Other than that, we kept talking about build systems and linking. Compared to when we started, we got through a lot of the immediately pressing topics. So now we're only meeting when there's enough to talk about. That currently works out to about every two weeks.

Worth a look

Rust Foundation posts

Rust Project updates

Stats

Total words of meeting minutes written: 396.7k (June 2025–February 2026)

Meetings attended: 45

Total words of meeting minutes written (February): 73.7k

Average (mean) word count per team meeting:

  • Cargo: 1.6k
  • Lang triage: 2.5k
  • Libs-API: 4.8k
  • Leadership Council: 2.4k