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!
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.
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!
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.
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:
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!
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.
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.
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:
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.
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.
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:
This is a topic we will almost certainly come back to.
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.
nvptx64-nvidia-cuda targetTotal 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:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。