Status: RFC pending This set of goals has proposed as RFC #3764(https://github.com/rust-lang/rfcs/pull/3764) on the Rust RFC repository.

Summary

Propose a slate of 39 project goals for 2025H1, including 3 flagship goals:

Motivation

The 2025H1 goal slate consists of 39 project goals, of which we have selected 3 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 a point of contact, somebody who is willing to commit resources (time, money, leadership) to seeing the work get done. The point of contact 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 point of contact 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. We don't want to create stress via unrealistic, ambitious goals. We want to make steady progress each goal period on important problems.

Guide-level explanation

Flagship goals

The flagship goals proposed for this roadmap are as follows:

Why these particular flagship goals?

Async. Rust is a great fit for server development thanks to its ability to scale to very high load while retaining low memory usage and tight tail latency. 52% of the respondents in the 2023 Rust survey indicated that they use Rust to build server-side or backend applications. In 2025H1 our plan is to deliver (a) improved support for async-fn-in-traits, completely subsuming the functionality of the async-trait crate; (b) progress towards sync and async generators, simplifying the creation of iterators and async data streams; (c) and improve the ergonomics of Pin, making lower-level async coding more approachable. These items together start to unblock the creation of the next generation of async libraries in the wider ecosystem, as progress there has been blocked on a stable solution for async traits and streams.

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 a true alternative to C. Currently the Linux kernel support depends on a wide variety of unstable features in Rust; these same features block other embedded and low-level systems applications. We are working to stabilize all of these features so that RFL can be built on a stable toolchain. As we have successfully stabilized the majority of the language features used by RFL, we plan in 2025H1 to turn our focus to compiler flags and tooling options. We will (a) implement RFC #3716 which lays out a design for ABI-modifying flags; (b) take the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options; (c) extending rustdoc, clippy, and the compiler with features that extract metadata for integration into other build systems (in this case, the kernel's build system).

Rust All Hands 2025. May 15, 2025 marks the 10-year anniversary of Rust's 1.0 release; it also marks 10 years since the creation of the Rust subteams. At the time there were 6 Rust teams with 24 people in total. There are now 57 teams with 166 people. In-person All Hands meetings are an effective way to help these maintainers get to know one another with high-bandwidth discussions. This year, the Rust project will be coming together for RustWeek 2025, a joint event organized with RustNL. Participating project teams will use the time to share knowledge, make plans, or just get to know one another better. One particular goal for the All Hands is reviewing a draft of the Rust Vision Doc, a document that aims to take stock of where Rust is and lay out high-level goals for the next few years.

Project goals

The full slate of 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.

Invited goals. Some goals of the goals below are "invited goals", meaning that for that goal to happen we need someone to step up and serve as an owner. To find the invited goals, look for the Help wanted badge in the table below. Invited goals have reserved capacity for teams and a mentor, so if you are someone looking to help Rust progress, they are a great way to get involved.

GoalPoint of contactTeam
"Stabilizable" prototype for expanded const genericsBoxylang, types
Bring the Async Rust experience closer to parity with sync RustTyler Mandrycompiler, lang, libs-api, spec, types
Continue resolving cargo-semver-checks blockers for merging into cargoPredrag Gruevskicargo, rustdoc
Declarative (macro_rules!) macro improvementsJosh Triplettlang, wg-macros
Evaluate approaches for seamless interop between C++ and RustTyler Mandrycompiler, lang, libs-api
Experiment with ergonomic ref-countingSantiago Pastorinolang
Expose experimental LLVM features for GPU offloadingManuel Drehwaldcompiler, lang
Extend pubgrub to match cargo's dependency resolutionJacob Finkelmancargo
Externally Implementable ItemsMara Boscompiler, lang
Finish the libtest json output experimentEd Pagecargo, libs-api, testing-devex
Implement Open API Namespace SupportHelp Wantedcargo, compiler
Implement restrictions, prepare for stabilizationJacob Prattcompiler, lang, spec
Improve state machine codegenFolkert de Vriescompiler, lang
Instrument the Rust standard library with safety contractsCelina G. Valcompiler, libs
Making compiletest more maintainable: reworking directive handlingJieyou Xubootstrap, compiler, rustdoc
Metrics InitiativeJane Lusbycompiler, infra
Model coherence in a-mir-formalityNiko Matsakistypes
Next-generation trait solverlcnrtypes
Nightly support for ergonomic SIMD multiversioningLuca Versarilang
Null and enum-discriminant runtime checks in debug buildsBastian Kerstingcompiler, lang, opsem
Optimizing Clippy & lintingAlejandra GonzΓ‘lezclippy
Organize Rust All-Hands 2025Mara Bosleadership-council
Prepare const traits for stabilizationOliver Scherercompiler, lang, types
Promoting Parallel Front EndSparrow Licompiler
Prototype a new set of Cargo "plumbing" commandsHelp Wantedcargo
Publish first rust-lang-owned release of "FLS"Joel Marceybootstrap, spec
Publish first version of StableMIR on crates.ioCelina G. Valcompiler, project-stable-mir
Research: How to achieve safety when linking separately compiled codeMara Boscompiler, lang
Run the 2025H1 project goal programNiko Matsakisleadership-council
Rust Vision DocumentNiko Matsakisleadership-council
SVE and SME on AArch64David Woodcompiler, lang, types
Scalable Polonius support on nightlyRΓ©my Rakictypes
Secure quorum-based cryptographic verification and mirroring for crates.iowalterhpearcecargo, crates-io, infra, leadership-council, release
Stabilize public/private dependenciesHelp Wantedcargo, compiler
Stabilize tooling needed by Rust for LinuxNiko Matsakiscargo, clippy, compiler, rustdoc
Unsafe FieldsJack Wrenncompiler, lang
Use annotate-snippets for rustc diagnostic outputScott Schafercompiler
build-stdDavid Woodcargo
rustc-perf improvementsDavid Woodcompiler, infra

Reference-level explanation

The following table highlights the asks from each affected team. The rows are goals and columns are asks being made of the team. The contents of each cell may contain extra notes (or sometimes footnotes) with more details. Teams often use these notes to indicate the person on the team signed up to do the work, for example.

bootstrap team

*1: For any tooling integration (from here)

*2: including consultations for desired test behaviors and testing infra consumers (from here)

*3: Probably mostly bootstrap or whoever is more interested in reviewing [compiletest] changes (from here)

cargo team

*1: 1 hour Overall Design and threat model (from here)

*2: 1 hour General design/implementation for index verification (from here)

*3: 1 hour Design for novel incremental download mechanism for bandwidth conservation (from here)

clippy team

Goalr?Stabilize.
Optimizing Clippy & lintingβœ…
Rust-for-Linux
↳ Clippy configurationβœ…

compiler team

GoalGood vibesr?Ded. r?Design mtg.RFCStabilize.Policy
Async
↳ Implementable trait aliasesβœ…
↳ Return type notationβœ…
Evaluate approaches for seamless interop between C++ and Rustβœ…*2
Expose experimental LLVM features for GPU offloadingβœ…
Externally Implementable Itemsβœ…
Implement Open API Namespace Supportβœ…
Implement restrictions, prepare for stabilizationβœ…
Improve state machine codegenβœ…βœ…
Instrument the Rust standard library with safety contracts
↳ Experimental Contract attributesβœ…βœ…
Making compiletest more maintainable: reworking directive handling*6*7
Metrics Initiativeβœ…βœ…
Null and enum-discriminant runtime checks in debug buildsBen Kimock
Prepare const traits for stabilizationβœ…
Promoting Parallel Front Endβœ…
Publish first version of StableMIR on crates.ioβœ…
Research: How to achieve safety when linking separately compiled codeβœ…
Rust-for-Linuxβœ…
↳ ABI-modifying compiler flagsβœ…*3*4
↳ Extract dependency information, configure no-std externallyβœ…βœ…
SVE and SME on AArch64βœ…
↳ Extending type system to support scalable vectorsβœ…
↳ Investigate SME supportβœ…
↳ Land nightly experiment for SVE typesβœ…
Stabilize public/private dependenciesβœ…
Unsafe Fieldsβœ…
Use annotate-snippets for rustc diagnostic output
↳ Production use of annotate-snippets*5
↳ Standard reviewsβœ…
rustc-perf improvements*1

*1: Update performance regression policy (from here)

*2: 2-3 meetings expected; all involve lang (from here)

*3: RFC #3716, currently in PFCP (from here)

*4: For each of the relevant compiler flags (from here)

*5: Esteban Kuber will be the reviewer (from here)

*6: including consultations for desired test behaviors and testing infra consumers (from here)

*7: Probably mostly bootstrap or whoever is more interested in reviewing [compiletest] changes (from here)

crates-io team

*1: 1 hour Overall Design, threat model, and discussion of key management and quorums (from here)

*2: 1 hour General design/implementation for automated index signing (from here)

infra team

*1: rustc-perf improvements, testing infrastructure (from here)

*2: 3 hours of design and threat model discussion. Specific production infrastructure setup will come at a later time after the initial proof of concept. (from here)

lang team

GoalGood vibesChampionExperimentDesign mtg.RFCStabilize.Policy
"Stabilizable" prototype for expanded const genericsβœ…
Async
↳ Implementable trait aliasesTyler Mandryβœ…
↳ Pin ergonomicsTyler MandryComplete
↳ Return type notationNiko MatsakisCompleteβœ…
↳ Trait for generators (sync)Tyler Mandry2 meetings expectedβœ…
↳ Unsafe binders*3Stretch goal
↳ async fn in dyn TraitNiko Matsakis
Declarative (macro_rules!) macro improvements*4
↳ Design and iteration for macro fragment fieldsJosh Triplettβœ…βœ…
↳ Design for macro metavariable constructsβœ…
↳ macro_rules! attributesJosh Triplettβœ…
↳ macro_rules! derivesJosh Triplettβœ…
Evaluate approaches for seamless interop between C++ and Rustβœ…Tyler Mandry*1
Experiment with ergonomic ref-countingNiko Matsakis
Expose experimental LLVM features for GPU offloadingTCComplete
Externally Implementable ItemsNiko MatsakisComplete
Implement restrictions, prepare for stabilizationβœ…βœ…
Improve state machine codegenTCβœ…
Nightly support for ergonomic SIMD multiversioningβœ…βœ…βœ…
Null and enum-discriminant runtime checks in debug buildsβœ…
Prepare const traits for stabilizationNiko MatsakisComplete*2(stretch goal)
Research: How to achieve safety when linking separately compiled codeβœ…Niko MatsakisNiko Matsakis
SVE and SME on AArch64βœ…
↳ Extending type system to support scalable vectorsDavid Woodβœ…
↳ Investigate SME supportβœ…
Unsafe Fieldsβœ…Scott McMurrayβœ…βœ…

*1: 2-3 meetings expected; all involve lang (from here)

*2: first meeting scheduled for Jan; second meeting may be required (from here)

*3: Niko Matsakis (stretch) (from here)

*4: Discussed with Eric Holk and Vincenzo Palazzo; lang would decide whether to delegate specific matters to wg-macros (from here)

leadership-council team

*1: approve creation of new team (from here)

*2: Complete for event (from here)

*3: Prepare one or two plenary sessions (from here)

*4: Decide on team swag; suggestions very welcome! (from here)

*5: Create supporting subteam + Zulip stream (from here)

*6: 1 hour synchronously discussing the threat models, policy, and quorum mechanism. Note: The ask from the Leadership Council is not a detailed exploration of how we address these threat models; rather, this will be a presentation of the threat models and a policy decision that the project cares about those threat models, along with the specific explanation of why a quorum is desirable to address those threat models. (from here)

libs team

GoalGood vibesr?
Instrument the Rust standard library with safety contractsβœ…
↳ Standard Library Contractsβœ…

libs-api team

*1: 2-3 meetings expected; all involve lang (from here)

opsem team

project-stable-mir team

release team

*1: Asynchronous discussion of the release team's role in the chain of trust, and preliminary approval of an experimental proof of concept. Approximately ~1 hour of total time across the 6-month period. (from here)

rustdoc team

*1: including consultations for desired test behaviors and testing infra consumers (from here)

spec team

testing-devex team

types team

GoalGood vibesr?RFCRFC rev.Stabilize.FCP
"Stabilizable" prototype for expanded const genericsβœ…
Async
↳ Implementable trait aliasesβœ…βœ…
↳ Return type notationβœ…βœ…
↳ Unsafe bindersStretch goal
Model coherence in a-mir-formalityβœ…
Next-generation trait solverβœ…βœ…*3
Prepare const traits for stabilization*1
↳ Formalize const-traits in a-mir-formality*2
SVE and SME on AArch64βœ…
↳ Extending type system to support scalable vectorsβœ…
↳ Investigate SME supportβœ…
↳ Land nightly experiment for SVE typesβœ…
Scalable Polonius support on nightlyMatthew Jasper

*1: Types team needs to validate the approach (from here)

*2: During types team office hours, we'll share information about our progress. (from here)

*3: for necessary refactorings (from here)

wg-macros team

GoalGood vibesPolicy
Declarative (macro_rules!) macro improvements*1
↳ Design for macro metavariable constructsβœ…

*1: Discussed with Eric Holk and Vincenzo Palazzo; lang would decide whether to delegate specific matters to wg-macros (from here)

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.

Frequently asked questions

What goals were not accepted?

The following goals were proposed but ultimately not accepted, either for want of resources or consensus. In some cases narrower versions of these goals were prepared.

GoalPoint of contactProgress
Field ProjectionsBenno Lossin(no tracking issue)
Rust Specification TestingConnor Horman(no tracking issue)

What do the column names like "Ded. r?" mean?

Those column names refer to specific things that can be asked of teams:

AskakaDescription
"Allocate funds"Alloc fundsallocate funding
"Discussion and moral support"Good vibesapprove of this direction and be prepared for light discussion on Zulip or elsewhere
"Deploy to production"Deploydeploy code to production (e.g., on crates.io
"Standard reviews"r?review PRs (PRs are not expected to be unduly large or complicated)
"Dedicated reviewer"Ded. r?assign a specific person (or people) to review a series of PRs, appropriate for large or complex asks
"Lang-team champion"Championmember of lang team or advisors who will champion the design within team
"Lang-team experiment"Experimentbegin a lang-team experiment authorizing experimental impl of lang changes before an RFC is written; limited to trusted contributors
"Design meeting"Design mtg.hold a synchronous meeting to review a proposal and provide feedback (no decision expected)
"RFC decision"RFCreview an RFC and deciding whether to accept
"RFC secondary review"RFC rev.briefly review an RFC without need of a formal decision
"Org decision"Orgreach a decision on an organizational or policy matter
"MCP decision"MCPaccept a Major Change Proposal
"ACP decision"ACPaccept an API Change Proposal
"Finalize specification text"Spec textassign a spec team liaison to finalize edits to Rust reference/specification
"Stabilization decision"Stabilize.reach a decision on a stabilization proposal
"Policy decision"Policymake a decision related to team policy
"FCP decision(s)"FCPmake formal decision(s) that require 'checkboxes' and a FCP (Final Comment Period)
"Blog post approval"Blogapprove of posting about this on the main Rust blog
"Miscellaneous"Miscdo some one-off action as described in the notes