• Feature Name: N/A
• Start Date: 2024-07-09
• RFC PR: rust-lang/rfcs#3672
• Rust Issue: N/A

Summary

This RFC presents the Rust project goal slate for 2024H2. The slate consists of 26 total project goals of which we have selected 3 as our “flagship goals”:

• Release the Rust 2024 edition (owner: TC)
• Bring the Async Rust experience closer to parity with sync Rust (owners: Tyler Mandry, Niko Matsakis)
• Resolve the biggest blockers to Linux building on stable Rust (owners: Josh Triplett, Niko Matsakis)

Flagship goals represent the goals expected to have the broadest overall impact.

This RFC follows an unusual ratification procedure. Team leads are asked to review the list of asks for their team and confirm that their team is aligned. Leads should feel free to consult with team members and to raise concerns on their behalf. Once all team leads have signed off, the RFC will enter FCP.

Motivation

This RFC marks the first goal slate proposed under the experimental new roadmap process described in RFC #3614. It consists of 26 project goals, of which we have selected three as flagship goals. Flagship goals represent the goals expected to have the broadest overall impact.

How the goal process works

Project goals are proposed bottom-up by an owner, somebody who is willing to commit resources (time, money, leadership) to seeing the work get done. The owner identifies the problem they want to address and sketches the solution of how they want to do so. They also identify the support they will need from the Rust teams (typically things like review bandwidth or feedback on RFCs). Teams then read the goals and provide feedback. If the goal is approved, teams are committing to support the owner in their work.

Project goals can vary in scope from an internal refactoring that affects only one team to a larger cross-cutting initiative. No matter its scope, accepting a goal should never be interpreted as a promise that the team will make any future decision (e.g., accepting an RFC that has yet to be written). Rather, it is a promise that the team are aligned on the contents of the goal thus far (including the design axioms and other notes) and will prioritize giving feedback and support as needed.

Of the proposed goals, a small subset are selected by the roadmap owner as flagship goals. Flagship goals are chosen for their high impact (many Rust users will be impacted) and their shovel-ready nature (the org is well-aligned around a concrete plan). Flagship goals are the ones that will feature most prominently in our public messaging and which should be prioritized by Rust teams where needed.

Rust’s mission

Our goals are selected to further Rust’s mission of empowering everyone to build reliable and efficient software. Rust targets programs that prioritize

• reliability and robustness;
• performance, memory usage, and resource consumption; and
• long-term maintenance and extensibility.

We consider “any two out of the three” as the right heuristic for projects where Rust is a strong contender or possibly the best option.

Axioms for selecting goals

We believe that…

• Rust must deliver on its promise of peak performance and high reliability. Rust’s maximum advantage is in applications that require peak performance or low-level systems capabilities. We must continue to innovate and support those areas above all.
• Rust’s goals require high productivity and ergonomics. Being attentive to ergonomics broadens Rust impact by making it more appealing for projects that value reliability and maintenance but which don’t have strict performance requirements.
• Slow and steady wins the race. For this first round of goals, we want a small set that can be completed without undue stress. As the Rust open source org continues to grow, the set of goals can grow in size.

Guide-level explanation

Flagship goals

The flagship goals proposed for this roadmap are as follows:

• Release the Rust 2024 edition, which will contain
  • a change in how impl Trait capture bounds work (RFC #3498 and RFC #3617)
  • reserving the gen keyword to allow for generators (RFC #3513)
  • never type fallback (#123748)
  • and a number of other potential changes that may be included if they make enough progress
• Bring the Async Rust experience closer to parity with sync Rust via:
  • resolving the “send bound problem”, thus enabling foundational, generic traits like Tower’s Service trait;
  • stabilizing async closures, thus enabling richer, combinator APIs like sync Rust’s Iterator;
  • reorganizing the async WG, so the project can benefit from a group of async rust experts with deep knowledge of the space that can align around a shared vision.
• Resolve the biggest blockers to Linux building on stable Rust via:
  • stabilizing support for arbitrary self types and unsizeable smart pointers, thus permitting ergonomic support for in-place linked lists on stable;
  • stabilizing features for labeled goto in inline assembler and extended offset_of! support, needed for various bts of low-level coding;
  • adding Rust For Linux project on Rust CI, thus ensuring we don’t accidentally cause regressions for this highly visible project (done!);
  • stabilizing support for pointers to statics in constants, permitting the construction of vtables for kernel modules;

Why these particular flagship goals?

2024 Edition. 2024 will mark the 4th Rust edition, following on the 2015, 2018, and 2021 editions. Similar to the 2021 edition, the 2024 edition is not a “major marketing push” but rather an opportunity to correct small ergonomic issues with Rust that will make it overall much easier to use. The changes planned for the 2024 edition will (1) support -> impl Trait and async fn in traits by aligning capture behavior; (2) permit (async) generators to be added in the future by reserving the gen keyword; and (3) alter fallback for the ! type.

Async. In 2024 we plan to deliver several critical async Rust building block features, most notably support for async closures and Send bounds. This is part of a multi-year program aiming to raise the experience of authoring “async Rust” to the same level of quality as “sync Rust”. Async Rust is a crucial growth area, with 52% of the respondents in the 2023 Rust survey indicating that they use Rust to build server-side or backend applications.

Rust for Linux. The experimental support for Rust development in the Linux kernel is a watershed moment for Rust, demonstrating to the world that Rust is indeed capable of targeting all manner of low-level systems applications. And yet today that support rests on a number of unstable features, blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support.

Project goals

The slate of additional project goals are as follows. These goals all have identified owners who will drive the work forward as well as a viable work plan. The goals include asks from the listed Rust teams, which are cataloged in the reference-level explanation section below. Some goals are actively looking for volunteers; these goals are tagged with .

Orphaned goals

Goals in this section are “pre-approved” by the team but lack an owner. These indicate a place where we are looking for someone to step up and help drive the goal the goal to completion. Every orphaned goal has someone who is willing and able to serve as mentor, but lacks the time or resources to truly own the goal. If you are interested in serving as the owner for one of these orphaned goals, reach out to the listed mentor to discuss. Orphaned goals may also be used as the basis of applying for grants from the Rust Foundation or elsewhere.

Goal	Owner	Team
User-wide build cache		cargo

Reference-level explanation

The following table highlights the asks from each affected team. The “owner” in the column is the person expecting to do the design/implementation work that the team will be approving.

cargo team

Goal	Owner	Notes
Approve RFC
↳ Yank crates with a reason	二手掉包工程师
Design meeting
↳ User-wide caching
Discussion and moral support
↳ Explore sandboxed build scripts	Weihang Lo
↳ Extend pubgrub to match cargo’s dependency resolution	Jacob Finkelman
↳ Begin resolving cargo-semver-checks blockers for merging into cargo	Predrag Gruevski
Stabilization decision
↳ Stabilize cargo-script	Ed Page
↳ Yank crates with a reason	二手掉包工程师
Standard reviews
↳ User-wide caching
↳ Explore sandboxed build scripts	Weihang Lo

clippy team

compiler team

crates-io team

lang team

Goal	Owner	Notes
Design meeting
↳ Async closures	Michael Goulet	2 meetings expected
↳ Trait for async iteration	Eric Holk	2 meetings expected
↳ Async drop experiments	Vadim Petrochenkov	2 meetings expected
↳ Ergonomic ref-counting	Jonathan Kelley	2 meetings expected
Discussion and moral support
↳ Const traits	Deadbeef
↳ Patterns of empty types	@Nadrieril
↳ “Stabilizable” prototype for expanded const generics	Boxy
Lang-team experiment
↳ Expose experimental LLVM features for automatic differentiation and GPU offloading	Manuel Drehwald	(approved)
Org decision
↳ Async WG reorganization	Niko Matsakis
RFC decision
↳ “Send bound” problem	Niko Matsakis
↳ Async closures	Michael Goulet
↳ Trait for async iteration	Eric Holk
↳ Derive smart pointer	Alice Ryhl
↳ Ergonomic ref-counting	Jonathan Kelley
Stabilization decision
↳ Stabilize cargo-script	Ed Page
↳ “Send bound” problem	Niko Matsakis
↳ Async closures	Michael Goulet
↳ Arbitrary self types v2	Adrian Taylor
↳ Derive smart pointer	Alice Ryhl
↳ asm_goto	Gary Guo
↳ Pointers to static in constants	Niko Matsakis
↳ Rust 2024 Edition	TC
↳ Associated type position impl trait	Oliver Scherer

leadership-council team

Goal	Owner	Notes
RFC decision
↳ Assemble project goal slate	Niko Matsakis
↳ Rust 2024 Edition	TC	(RFC #3501)

libs team

libs-api team

rust-analyzer team

rustdoc team

rustdoc-frontend team

types team

Definitions

Definitions for terms used above:

• Author RFC and Implementation means actually writing the code, document, whatever.
• Design meeting means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
• RFC decisions means reviewing an RFC and deciding whether to accept.
• Org decisions means reaching a decision on an organizational or policy matter.
• Secondary review of an RFC means that the team is “tangentially” involved in the RFC and should be expected to briefly review.
• Stabilizations means reviewing a stabilization and report and deciding whether to stabilize.
• Standard reviews refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
• Other kinds of decisions:
  • Lang team experiments are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
  • Compiler Major Change Proposal (MCP) is used to propose a ‘larger than average’ change and get feedback from the compiler team.
  • Library API Change Proposal (ACP) describes a change to the standard library.