Program management update — April 2026

May 13, 2026 · Tomáš Šedovič and Nurzhan Saken on behalf of the Program team

Greetings! This was a busy month. The Project goals RFC has been accepted, and we're officially in the 2026 goals period. At the time of writing, RustWeek is exactly one week away. Time flies!

Program management schedule

Nurzhan and Tomáš have settled on our meeting schedule. Roughly speaking, we're taking turns attending each meeting, and we've set it up to reduce the number of back-to-back meetings and long evenings. We're also getting some call-free Fridays, which is always nice.

The calendar is publicly accessible and we keep it up to date.

The 2026 RustWeek / All Hands

In the week of 18th May, Utrecht will briefly become a city with the highest per-capita Rustacean concentration. Just like last year, it will host the co-located RustWeek and Rust All Hands conferences!

The pre-registration and workshops will start on Monday, with the actual RustWeek conference on Tuesday and Wednesday, followed by three days of the All Hands.

Have a look at the speakers, schedule, check out the website for more information, and if you plan to go, don't forget to buy a ticket.

The two of us plan to be there. Feel free to say hi!

Project goals

The 2026 Project goals RFC has been accepted! This happened about a month later than we planned. We'll keep that in mind for next year, and as most of the Project goals team members are going to be at the All Hands, we plan to do a retrospective there.

All the new tracking issues have been created, and the continuing ones have been updated too. Any goals that weren't renewed for 2026 are now closed.

If you're a point of contact on a goal, you will start getting bot messages reminding you to post an update on the tracking issue. These reminders happen roughly twice a month and won't trigger for you if you've already posted an update recently.

Now that the RFC is merged, we'll publish one last 2025h2 Project goals update blog post. Then (possibly kicking things off at the All Hands again), we'll plan how we'll be doing updates going forward. People brought up several issues with the current way the posts are formatted, the information they show, and whether they're useful at all.

Outreachy

Throughout April, the Outreachy internship applicants were getting set up and started sending their contributions. A few days ago, the organizers selected four interns.

These are the projects our interns signed up for:

  • Calling overloaded C++ functions from Rust.
  • Code coverage of the Rust compiler at scale.
  • Fuzzing the a-mir-formality type system implementation.
  • Improve the security of GitHub Actions of the Rust Project.

You can read more about the projects and Outreachy in general in Jack Huey's blog post.

The interns will work on these projects over the next three months. Congratulations to the selected interns and huge thanks to Jack, the mentors, and everyone else who participated <3.

Exciting times ahead!

C++ interop update

In February 2026, the Foundation hired teor to speed up the mapping of the interop problem space, and their work continues apace.

teor has been posting monthly updates on the C++ interop Project goal tracker and weekly ones on Zulip.

We now have around 30 interop problem statements and use cases listed in the interop-initiative repo. If you're at all interested in this, do check it out. The problem statements are really well-described, include example code, and link to prior art.

Here is a string interop example.

As part of the contribution round, the Outreachy applicants provided executable code samples, e.g., calling overloaded C++ functions from Rust.

teor also started a lang experiment to implement the splat feature. This will provide a way to define function overloading and variable arguments in Rust. The initial focus is to improve interoperability with C++, which does allow both.

In addition to this work showing direct impact, Joel Marcey published an update on the Rust Foundation Interop Initiative. The post goes over the initiative's accomplishments. These include working with ISO WG21 (the committee responsible for C++ standardization). There seems to be a strong consensus for providing memory safety mechanisms to C++, but this will take multiple years.

So the Foundation is now focusing more on the immediate needs of projects with large C++ codebases who want to (or already started to) adopt Rust. This is where all the work teor's been doing comes in.

Content team

The last few months have been difficult for the team to dedicate time to producing useful content for everyone. We've published a couple of interviews (Daniel Almeida on a Rust GPU driver in Linux and Tyler Mandry on C++/Rust interop), and a Rust 1.95 changelog overview, but we have a backlog of another nine recordings in the pipeline.

A lot of the folks will also be at the All Hands, and we're planning to do more interviews there.

What became clear is that the volunteering contribution model that works for code, documentation, etc., is less successful when it comes to things like recording and editing video. We're able to do this (as demonstrated by what we already put out), but the time commitment is really high compared to what a professional could do, even at the lowest level of effort.

To that end, TC proposed a 2026 funding request to the Council. In it, we asked for $15,000 USD to hire an editor who would process our existing backlog as well as videographers for the events where we'll conduct the bulk of our upcoming interviews (All Hands and RustConf).

The Council has approved this request, and we're now in talks with people we might hire.

This would let us focus on utilizing our knowledge and connections to interview great people and share their thoughts with the rest of the community.

Rust for Linux

A lot of the Rust for Linux folks will attend RustWeek and/or the All Hands. The Rust Project also extended an invitation to the kernel developers, and some of them will be there too.

The project will hold a few sessions at the All Hands: In-place Initialization, Field Projections, CoccinelleForRust, Compiling Rust to BPF, and office hours.

We continued having our regular fortnightly meetings; here's what we discussed in April:

zerocopy features in std

Given the plan to include zerocopy in Linux, the team brought up the possibility of stabilizing a few unstable pieces of the standard library that zerocopy ends up re-implementing.

These are ptr_metadata and Freeze. Having these in would help with the zerocopy maintenance.

Freeze now has an open RFC as core::marker::NoCell, while ptr_metadata is blocked on Sized Hierarchy.

null-ptr-deref

The team would like to have an (optional) guarantee that the compiler will never remove null checks on raw pointers. In C, dereferencing a null pointer is undefined behavior, so the compiler may optimize away subsequent null checks against that pointer. However, the null check can still serve as a safeguard against other bugs, and in C, the kernel now disables the optimization that would remove it.

Edition migration tooling

The team wants to move to the new edition, as it would fix some existing bugs and provide nicer language and library APIs. However, they're concerned about situations where the same code has different semantics in different editions.

Making semantic changes is something that the language explicitly allows, and while we provide tooling to migrate or at least highlight these cases to prevent breakages, this tooling cannot guarantee catching 100% of the issues.

A challenge with the current approach is that when the kernel migrates to a new edition, the previous releases will stay on older editions (potentially more than one), and these situations can be really easy to miss when backporting a change. Anything that changes the drop order (e.g., the if let temporary scope change in the 2024 edition) could result in undefined behavior (UB).

Miguel Ojeda brought this up to check on what guarantees the language and tooling make. They're looking for a way to flag cases where the same code has different semantics with a zero false negative rate (i.e., it will not let something slip by).

TC explained that the current migration tooling (edition lints and cargo fix) is not set up to make this a guarantee, although we try to get as close as possible and put a lot of effort into migration testing.

Benno Lossin suggested writing tooling that would compile the code being evaluated under both editions and compare the MIR output. If they're identical, no semantic changes occurred. Otherwise, there may or may not be changes. This risks generating false positives, but at least the reviewers can be confident that nothing has been silently accepted. This seems feasible and might be something the Project would be interested in adopting and maintaining, but there's no bandwidth to do this within the edition team.

Interestingly, the edition migration itself isn't an issue—the Rust for Linux team pays attention to the edition migration guide and checks things. The main issue is with backports, which are semi-automatic. If a patch is flagged for a backport and it applies cleanly, there's little human supervision involved. When the backport patch (coming from a newer edition) uses new features, compilation fails on the older edition, flagging people to pay attention. However, when the code looks identical in both editions but behaves differently, we may run into issues.

In the end, several options were proposed, each with its own trade-offs:

  • Stay on an edition until all the stable branches move to a MSRV (minimal supported Rust version) that allows migrating to a new edition wholesale.
  • Develop an outside tool that would compile the code in both editions and check whether they produce the same MIR.
  • Develop review processes for backporting patches on the kernel side to handle these cases.
  • Develop processes and tooling within the kernel for writing all code such that it always falls within the intersection between all editions supported on all branches.

This is a topic we will almost certainly come back to.

Project Director election process update

In autumn 2025, Tomáš facilitated the Project Director election. A part of the facilitator role is to publish a retrospective, clarify the documentation, and propose changes to the election process (if relevant).

This is the 2025 PD election retrospective. The PR that clarifies the election processes is here.

Worth a look

Rust Foundation posts

Rust Project updates

Stats

Total words of meeting minutes written: 551.3k (June 2025–April 2026)

Meetings attended: 45

Total words of meeting minutes written (April): 80.8k

Average (mean) word count per team meeting:

  • Cargo: 1.9k
  • Lang triage: 3.1k
  • Libs-API: 4.7k
  • Leadership Council: 2.4k