Program management update — August 2025

Sept. 11, 2025 · Tomas Sedovic on behalf of Edition & Goals teams

Program management update — August 2025

Quite a lot has happened in August. Let's dive in!

Leadership Council

Representatives are now being selected for the Rust Leadership Council, and this is as good a time as any to remind everyone what it does.

The Council is composed of Project members, one for each top-level team and its subteams. They represent the interests of their teams and support the long-term success of the Project as a whole.

They also coordinate with the Foundation and elect the Project Directors on the Foundation's board (more on this later).

Their work largely happens publicly in the Council's repository.

The representatives meet every other Friday and link these issues in their agenda. When they make a decision, they summarize the discussion and propose an FCP (final comment period) on the relevant issue. As with all FCPs in the Project, they're interested in any feedback people have until the comment period is closed. They review it all.

If you want to see what the Council is up to, these issues are a great complement to the Council meeting minutes I'm taking and publishing on their behalf.

To see this in practice, here is a proposal to send me to the annual Rust for Linux workshop (Kangrejos):

https://github.com/rust-lang/leadership-council/issues/217

Representative selections

Every six month, half of the Council's term ends. For this round, the Infra, Lang, Libs, and Mods teams are selecting representatives, and the nominations are now open.

If you want to learn more or you're interested in representing your team, please read Eric Huss's post announcing the selection.

Rust Foundation Project Directors 2025

This fall, we're also looking for new Project Directors.

The Directors have staggered terms as well and half are up for election every year.

This time it's Santiago Pastorino, Scott McMurray, and Jakob Degen's. None are seeking reelection.

These are seats directly on the Rust Foundation board. The Project directors serve the interest of the Rust Project as a whole and sit alongside the Member Directors who represent companies funding the Foundation.

Each resolution the Foundation passes must be approved by both Member and Project Directors separately. That means regardless of the size of the board, the Project has an equal voice in Foundation matters.

You can nominate yourself or another person until 2025-09-18. Please read the blog post for more information. The Project is always looking for fresh faces and diverse voices.

I am the facilitator of the selection process this time around. That means I've authored the blog post above, proposed the timeline, and I'll seek out consent and statements from the nominees. I've also announced the election on Zulip as well as an email that should reach all Project members. I'll see it all through, including facilitating the actual election process.

Bevy/gamedev followup

A month ago, the Lang team invited the Bevy game engine folks to talk about issues faced by their new users as well as any pain points their project is facing.

There were two big topics they mentioned: reflection and variadic generics.

Both have been requested for a long time, and the interest is much broader than just Bevy or even just the game development space.

Reflection

Reflection is a mechanism that lets your program look at any type and understand it: getting its name, fields, and their names and types while your program is running. This is in contrast to the derive macro or trait bounds that are processed at compile time.

Projects like Bevy currently rely on derive macros. For example, pretty much all its types have derive(Reflect) to provide dynamic field access and type inspection, serialization/deserialization, and scripting. While the usage is simple, these macros are difficult to write and debug. And the language has limitations on where they can be applied.

You can only implement a trait for a type (which is what derive does, under the hood) if either the trait or type is defined in the crate you're implementing it in (this is the orphan rule).

So if you want to implement Reflect (defined in bevy_reflect, not your crate), you could derive it for your custom type, but not e.g. for Duration or [f32; 2] because they're defined in the standard library.

You have to create a new enum/struct that wraps that type and implement the trait yourself. This all gets very complex very quickly and no good solution exists right now.

In practice, projects like serde and Bevy often provide implementations for common standard library types (including tuples up to a limited size). But when a new crate comes along, it either has to implement all the useful traits in the ecosystem, convince everyone in the ecosystem to provide the implementations for its types, or accept being less useful than the existing crates. This can lead to ecosystem stagnation.

With reflection, a lot of this machinery would be available on every type everywhere and everyone could use it.

Oli opened the reflection and comptime goal for the 2025H2 period that will build the initial functionality and extend it later on.

This happened with little intervention on my part, but I made sure that the Bevy folks were aware (they were!), and I'll be keeping an eye on this to help move it forward and be on the lookout for other projects that may find this useful.

Variadic generics

Remember how I said crates implement traits for tuples up to a certain size? That's a limitation of Rust that is -- again -- felt in many different areas.

The basic idea is: suppose you have a tuple of types that all implement a given trait. You want the tuple to be able to implement that trait too.

For example, if all the elements of a tuple implement the Debug trait, you should be able to dbg!() or println!("{:?}", ...) such a tuple.

And you can!

fn main() {
    let tuple = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);
    println!("{tuple:?}");
}

// (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)

(playground)

...sort of:

fn main() {
    let tuple = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13);
    println!("{tuple:?}");
}

// error[E0277]: `({integer}, [...], {integer})` doesn't implement `Debug`
// --> src/main.rs:3:16
// [...]

(playground)

Even in the Rust standard library, traits like this are only implemented for tuples up to 12 elements.

This is, again, keenly felt by anyone writing an entity component system (ECS) or object-relational mapping (ORM) and in particular their query systems.

Some time ago, Olivier Faure took up the mantle and drove the discussions at the last two RustWeek conferences (read the 2024 and 2025 reports).

Olivier also wrote "Variadic Generics ideas that won't work for Rust" which highlights the many pitfals even the simplest "why don't we just..." ideas inevitably run into. This is a complex feature that touches a lot of Rust's machinery, and it can't be added in easily.

But we still want it!

Some of the things blocking this in the past have either been resolved or are going to be resolved soon (e.g. the new trait type solver). And the Lang team is interested in reviewing a proposal.

I've done a lot of background reading (which made me appreciate the complexity), talked to Olivier and Alice Cecile, and opened a design meeting on the Lang side as there is a way forward now.

The next steps are getting an RFC written and scheduling the design meeting. I'm again on the lookout for other people interested in the space (either with proposals of their own or usecases we want to make sure are heard) so I can point them to this space.

Lori Lorusso: Foundation Director of Outreach

Earlier this month, Lori joined the Rust Foundation.

She'll be overseeing the grants program as well as the external outreach and internal inreach and communication. She'll also look at bringing in communities and people from areas that we haven't reached yet.

As our roles overlap a bit (and can definitely benefit from our collaboration -- e.g. on the communication between the Project and Foundation), we've set up a regular check-in.

One of the near-term things I'll do is get her onboarded on the Rust blog system so she can publish posts there.

Content team

This month also saw a formation of a new team focused on producing audio/video/text content about Rust and people working on it and with it. These can be interviews, podcasts, etc.

TC and Pete LeVasseur are the leads, and we also have Cameron Dershem, Xander Cesari, Tyler Mandry, Lori, and yours truly.

We already have a few interviews planned for RustConf 2025.

Here's the Content Team's charter. Forming a new "pseudo top-level team" like this is something you propose to the Leadership Council in their repo's issues. It then gets discussed at their meeting and decided on using the FCP process.

build-std

build-std is an ongoing initiative to provide a blessed, stable process for building the Rust standard library you can use instead of the one we provide.

There are many different motivations for this, for example supporting platforms where Rust doesn't ship a precompiled library, optimizing it to known hardware or reducing its size (by e.g. removing features that are not necessary). This is of interest to the Rust for Linux project, among others.

David Wood and Adam Gemmell wrote a comprehensive document describing its history, motivations, and past experiments, and they made a proposal for a minimal solution that they can start building.

This has been regularly reviewed by a handful of people across the relevant teams. After many rounds of feedback, David feels the proposal is solid enough to open to a broader group.

He's shared it with more representatives from the Libs, crates.io, bootstrap, infra, compiler, and Cargo teams, as well as with members of the embedded working group. He's also shared it with non-Cargo users e.g. the Rust for Linux folks (who are interested in building std without Cargo).

Once this next round settles down, he will open the RFC (it will likely be several documents each focusing on a different stage of the effort).

Rust for Linux

Rust for Linux is an ongoing initiative to be able to write Linux kernel code in Rust. The motivations include memory safety and that a modern language may help to bring in more contributors.

The focus in this second half of 2025 is to bring the unstable features RfL is using into stable Rust. Like Rust itself, Linux takes stability and backwards compatibility seriously. Building on stable Rust in the right fit.

RFC: Pass pointers to const

Rust has support for inline assembly. This lets you do things the language doesn't have direct support for such as accessing CPU registers or reading/writing values to device-specific segments in memory to control their behavior (this is often used when writing drivers).

The asm! macro lets you interpolate constant values into the assembly code you've written, similar to how you can interpolate values into a format string:

println!("The meaning of life, universe and everything: {}", 42);

But constant values only get you so far. A common thing when writing assembly is to be able to pass pointer values (e.g. pointer to a specific field of a struct you want to manipulate) around. But currently, only integer constant expressions are allowed.

Alice Ryhl opened an RFC that allows specifying pointers in the const operand too. Conceptually (and in assembly specifically) pointers could be thought of as just numbers that are interpreted as addresses to memory (although in Rust, the story is far more complex and pointers are not the same thing as integers).

This is now ready for feedback from the Lang team, so I opened a design meeting issue, and got it scheduled for review and discussion.

Field projections

We also had a design meeting on field projections. When you have a type behind a & or &mut reference, you can access its field "directly" as if the pointer type weren't there:

struct Position {
    x: f32,
    y: f32,
}

impl Position {
    fn get_x(&self) -> &f32 {
        &self.x
    }
}

The language understands Position is behind a pointer, calculates an offset to the field x, and gives you that pointer back.

There's a long list of wrapper types where field access makes sense but where it's not implemented because the semantics are different from the regular Deref/DerefMut traits. For example: MaybeUninit<T>, Pin<P>, Cell<T>, or the raw pointers *const T/*mut T. And of course custom types.

Linux uses pinned values (Pin<P> -- values that can't move around in memory), raw pointers, and MaybeUninit all over the place in addition to many custom fields that would greatly benefit from field projections.

Benno Lossin, who owns the field projection goal, prepared a design to move this forward as a lang experiment. This was approved; we now have a field projection tracking issue as well as an initial implementation.

Reducing codegen size

The last Rust for Linux meeting got into a fascinating discussion about an ongoing need to reduce the size of the binary generated by rustc. There is functionality in the Rust standard library that is not used in the kernel but that still takes up space, e.g. support for 128-bit integer types, the alloc crate, and the floating point formatting code. Some are not relevant while others (like alloc) are reimplemented by Rust for Linux.

There's an interest in being able to compile certain features out (using cfg) and/or having a minimal core that projects can build on top of.

This is something I plan to gather more information about and follow-up on.

Kangrejos 2025

Due to their warm invitation, and supported by the council and funding from the Project Priorities budget, I'll be joining the Rust for Linux team at their Kangrejos workshop in Spain in September. I hope to get to know the Rust for Linux people better in a less formal environment, get more hand-on experience with what they're doing and the challenges they're facing, and be the conduit for even more collaboration between them and the Rust Project.

Conferences

September is going to be an eventful (if you pardon the pun) month!

First up, RustConf 2025 took place in Seattle, Washington, USA (from 2025-09-02 to 2025-09-05). RustConf offered virtual tickets so people could attend online as well.

Second is the RustGlobal China and RustChinaConf 2025 in Hangzhou, China (from 2025-09-13 to 2025-09-14)

And finally the aforementioned Rust for Linux workshop, Kangrejos in Oviedo, Spain (from from 2025-09-17 to 2025-09-18).

If nothing else, look forward to a good batch of talks being posted online in the coming weeks and months!

Stats

Total words of meeting minutes written: 138.6k (June - August).

Meetings attended: 31

Total words written: 46k

Average (mean) word count per team meeting:

  • Cargo: 1.9k
  • Lang triage: 2.5k
  • Libs: 5.9k
  • Leadership council: 2.9k

You can see the June and July stats in the previous update.