Program management in July–August 2026

It's been fun since the last update. Tomáš was away for a month, and I had to get my wisdom teeth pulled right after he left.

Despite everything, a lot has happened!

Project Goals

Since the previous update, we've opened seven more goals:

There's now a roadmap for Binary size reduction, which includes async future and statemachine optimization goals, build-std, and future possibilities that aren't goals yet.

One goal was completed (Stabilize Cargo's linting system), and two were discontinued (Experimental language specification and Continue Experimentation with Pin Ergonomics).

Several goals have received partial funding (Incremental Systems Rethought, Native async fn dynamic dispatch in traits, and Cargo cross workspace cache), and some are now fully funded (C interop: f80, f128, and c_longdouble, C interop: Complex<T>, and Async statemachine optimization). Don't forget to add your goal to the funding table if it needs funding (see template)!

Some goal owners and contributors have been writing about their work beyond the regular goal updates. Here are some of the places to check out:

Infrastructure

The Goals repository has been renamed to rust-lang/goals from the verbose rust-lang/rust-project-goals, and we've renamed the Zulip channels to #goals, #goals/proposed, and #goals/meta. The website now lives at goals.rust-lang.org; the old links should redirect there.

Triagebot used to ping every #goals topic twice a month, which was incredibly noisy to anyone following that channel. Many of the goal owners weren't even subscribed to it, so they never received the reminders. This was finally reworked, and now goal owners receive one private message with an aggregate of all their goals needing updates. Some wanted triagebot to ping them more often, and it's now possible to configure the reporting frequency per goal (weekly, biweekly, or the default of every four weeks). Let us know how you like it!

We've set up the automatic creation of Zulip topics for labeled goal proposals in #goals/proposed so that there's less friction in soliciting team champions and collecting feedback.

Team building

The Goals team now has a regular meeting every Thursday at 14:00 UTC. We use that time to figure out what the program should mean, how it should be implemented, and how we can communicate it better to the audiences involved.

If you have any wishes, complaints, or thoughts about the Goals program, you can join the meetings or reach out to us!

Content

Seems like we've accidentally created a rite of passage in which a program manager has to anxiously get involved in at least one t-content production :-). I've mentioned before that I got to interview Alice Cecile (Bevy Engine) at RustWeek. This and twelve other interviews are now available on YouTube, so feel free to check them out!

The content team has started publishing interviews from RustConf and Kangrejos 2025 as well.

Apart from that, the team has been producing a series about Rust release changelogs. Here's the 1.97 episode! They're hoping to involve more people from across the Project in future episodes (and other videos), so that maintainers and contributors can talk about their work directly. Be on the lookout for a call for participation if you're interested or know someone who might!

Fun fact: I actually met Chris Biscardi at RustWeek and invited him to a content team meeting about the changelog series. One thing led to another, and Chris ended up joining the team and has been bringing in a lot of valuable content-making experience since! This makes me happy.

Rust for Linux

This cycle, Rust for Linux brought up some more interesting feature requests.

The core of `core`?

One of the topics Rust for Linux has been tracking is modularization of core. This is the ability to remove parts of the core standard library that the kernel doesn't need because of semantic differences or duplication. This includes standard atomics, IO, 128-bit numbers, floating-point numbers, and Unicode tables.

There are different ways to support such modularization, each with its own caveats. Perhaps the most fundamental one is keeping every feature under its own flag, but that requires building the standard library (see the build-std goal) and introduces a combinatorial explosion that's difficult to test. The standard library could also expose a small number of "feature layers" instead, but then it becomes hard to find a partitioning that makes sense for everyone.

Another approach is to define the smallest possible subset of core that's needed for the language to work. This subset, tentatively named lang, would only include things like lang items and could lead to a stable alternative to the internal #![no_core] feature. For now, that seems most realistic, and the RfL team is willing to experiment with it and possibly develop a proposal. Can we get a Project Goal out of this?

Integer casts

There's an ongoing appetite for more intentional casting mechanisms between integers. The kernel already lints against lossless casts, and recently introduced a num::casts module for lossless conversions that are missing from the core library (e.g., u32 -> usize and usize -> u64). This leaves the non-trivial as casts that may truncate or change signedness.

One option would be to lint against cast_possible_truncation, cast_sign_loss, and cast_possible_wrap, and justify each warning with an explicit #[expect(..., reason = "...")]. This gets awkward in kernel code, though, because lint expectations may depend on configuration (see coding guidelines). Miguel has also mentioned that the reason syntax is somewhat verbose, hence the existing request for tooling support for tagged comments like // CAST: ....

We may also get a resolution to this from the API side: the libs team is actively discussing numeric casting APIs, which may address this. See this meta-ACP.

Newtype literal constructors

We also discussed improving the ergonomics of NonZero and other newtypes. Specifically, it would be nice to be able to construct such types from bare literals:

const NONZERO_OK: NonZeroU8 = 42; // works
const NONZERO_BAD: NonZeroU8 = 0; // error

There have been proposals to generalize this to user types, e.g., through a FromLiteral trait family, but nothing that's usable today. So far, the kernel developers have been working around this (and the lack of const traits) using macro hacks.

Project updates

Here are some of the recent Project updates you might have missed:

Until next time! <3