We are in the process of assembling the goal slate.
Summary
This is a draft for the eventual RFC proposing the 2025H1 goals.
Motivation
The 2025H1 goal slate consists of 40 project goals, of which we have selected (TBD) 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 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:
(TBD)
Why these particular flagship goals?
(TBD--typically one paragraph per goal)
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 
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.
bootstrap team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Making compiletest more maintainable: reworking directive handling | Jieyou Xu | including consultations for desired test behaviors and testing infra consumers |
| RFC decision | ||
| ↳ Rust Specification Testing | Connor Horman | |
| Standard reviews | ||
| ↳ Making compiletest more maintainable: reworking directive handling | Jieyou Xu | Probably mostly bootstrap or whoever is more interested in reviewing [compiletest] changes |
cargo team
clippy team
| Goal | Point of contact | Notes |
|---|---|---|
| Stabilization decision | ||
| ↳ Clippy configuration | Niko Matsakis | |
| Standard reviews | ||
| ↳ Optimizing Clippy & linting | Alejandra González |
compiler team
crates-io team
| Goal | Point of contact | Notes |
|---|---|---|
| Deploy to production | ||
| ↳ Quorum-based cryptographic infrastructure (RFC 3724) | @walterhpearce | |
| RFC decision | ||
| ↳ Quorum-based cryptographic infrastructure (RFC 3724) | @walterhpearce |
infra team
| Goal | Point of contact | Notes |
|---|---|---|
| Deploy to production | ||
| ↳ rustc-perf improvements | David Wood | rustc-perf improvements, testing infrastructure |
| ↳ Quorum-based cryptographic infrastructure (RFC 3724) | @walterhpearce | |
| Discussion and moral support | ||
| ↳ rustc-perf improvements | David Wood | |
| RFC decision | ||
| ↳ Quorum-based cryptographic infrastructure (RFC 3724) | @walterhpearce | |
| Standard reviews | ||
| ↳ rustc-perf improvements | David Wood |
lang team
leadership-council team
| Goal | Point of contact | Notes |
|---|---|---|
| Allocate funds | ||
| ↳ Rust All-Hands 2025! | Mara Bos |  for event |
| Miscellaneous | ||
| ↳ Rust All-Hands 2025! | Mara Bos | Prepare one or two plenary sessions |
| ↳ Team swag | Mara Bos | Decide on team swag; suggestions very welcome! |
| ↳ Rust Vision Document | Niko Matsakis | Create supporting subteam + Zulip stream |
| ↳ Quorum-based cryptographic infrastructure (RFC 3724) | @walterhpearce | Select root quorum |
| Org decision | ||
| ↳ Run the 2025H1 project goal program | Niko Matsakis | approve creation of new team |
libs team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Instrument the Rust standard library with safety contracts | Celina G. Val | |
| Standard reviews | ||
| ↳ Standard Library Contracts | Celina G. Val |
libs-api team
| Goal | Point of contact | Notes |
|---|---|---|
| Design meeting | ||
| ↳ Trait for async iteration | Tyler Mandry | |
| ↳ Evaluate approaches for seamless interop between C++ and Rust | Tyler Mandry | 2-3 meetings expected; all involve lang |
| Discussion and moral support | ||
| ↳ Evaluate approaches for seamless interop between C++ and Rust | Tyler Mandry | |
| RFC decision | ||
| ↳ Trait for generators (sync) | Tyler Mandry |
opsem team
| Goal | Point of contact | Notes |
|---|---|---|
| Design meeting | ||
| ↳ Null and enum-discriminant runtime checks in debug builds | Bastian Kersting | |
| Discussion and moral support | ||
| ↳ Null and enum-discriminant runtime checks in debug builds | Bastian Kersting | |
| Standard reviews | ||
| ↳ Null and enum-discriminant runtime checks in debug builds | Bastian Kersting |
project-stable-mir team
| Goal | Point of contact | Notes |
|---|---|---|
| Standard reviews | ||
| ↳ Publish first version of StableMIR on crates.io | Celina G. Val |
release team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Integrate FLS into release process | Joel Marcey | Februrary 2025 |
| Standard reviews | ||
| ↳ Integrate FLS into release process | Joel Marcey |
rustdoc team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
↳ Continue resolving cargo-semver-checks blockers for merging into cargo | Predrag Gruevski | |
| ↳ Rust-for-Linux | Niko Matsakis | |
| ↳ Making compiletest more maintainable: reworking directive handling | Jieyou Xu | including consultations for desired test behaviors and testing infra consumers |
| RFC decision | ||
| ↳ Rustdoc features to extract doc tests | Niko Matsakis | |
| Stabilization decision | ||
| ↳ Rustdoc features to extract doc tests | Niko Matsakis | |
| Standard reviews | ||
| ↳ Rustdoc features to extract doc tests | Niko Matsakis |
spec team
| Goal | Point of contact | Notes |
|---|---|---|
| Miscellaneous | ||
| ↳ Integration of the FLS into the Rust Project | Joel Marcey | Take ownership of the FLS (prior to, or shortly into January 2025). |
| RFC decision | ||
| ↳ Rust Specification Testing | Connor Horman | |
| ↳ Integrate FLS into T-spec processes | Joel Marcey | End of March 2025 |
testing-devex team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Finish the libtest json output experiment | Ed Page |
types team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ "Stabilizable" prototype for expanded const generics | Boxy | |
| ↳ Model coherence in a-mir-formality | Niko Matsakis | |
| ↳ Next-generation trait solver | lcnr | |
| ↳ SVE and SME on AArch64 | David Wood | |
| ↳ Investigate SME support | David Wood | |
| FCP decision(s) | ||
| ↳ Next-generation trait solver | lcnr | for necessary refactorings |
| RFC decision | ||
| ↳ Implementable trait aliases | Tyler Mandry | |
| ↳ Land nightly experiment for SVE types | David Wood | |
| ↳ Extending type system to support scalable vectors | David Wood | |
| Standard reviews | ||
| ↳ Scalable Polonius support on nightly | Rémy Rakic | Matthew Jasper |
| ↳ Return type notation | Tyler Mandry | |
| ↳ Implementable trait aliases | Tyler Mandry | |
| ↳ Next-generation trait solver | lcnr |
wg-macros team
| Goal | Point of contact | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Design for macro metavariable constructs | Josh Triplett | |
| Policy decision | ||
↳ Declarative (macro_rules!) macro improvements | Josh Triplett | Discussed with Eric Holk and Vincenzo Palazzo; lang would decide whether to delegate specific matters to wg-macros |
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 not accepted:
| Goal | Point of contact | Progress |
|---|