Project Goals 2025h1

• Feature Name: N/A
• Start Date: 2025-01-14
• RFC PR: rust-lang/rfcs#3764
• Rust Issue: N/A

§ Summary

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

• Continue making Rust easier to use for network systems by bringing the Async Rust experience closer to parity with sync Rust. In 2025H1 we plan to:
  • tell a complete story for the use of async fn in traits, unblocking wide ecosystem adoption;
  • improve the ergonomics of Pin, which is frequently used in low-level async code; and
  • prepare to support asynchronous (and synchronous) generators in the language.
• Continue helping Rust support low-level projects by stabilizing compiler options and tooling used by the Rust-for-Linux project. In 2025H1 we plan to:
  • implement RFC #3716 to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth;
  • taking the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options;
  • add rustdoc features to extract and customize rustdoc tests (--extract-doctests);
  • stabilize clippy configuration like .clippy.toml and CLIPPY_CONF_DIR;
  • stabilize compiler flags to extract dependency info (e.g., as via -Zbinary-dep-depinfo=y) and to configure no-std without requiring it in the source file (e.g., as via -Zcrate-attr);
• Address the biggest concerns raised by Rust maintainers, lack of face-to-face interaction, by organizing the Rust All-Hands 2025. In 2025H1 we plan to:
  • convene Rust maintainers to celebrate Rust's tenth birthday at RustWeek 2025 (co-organized with RustNL);
  • author a first draft for a Rust vision doc and gather feedback.

§ 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:

• Continue making Rust easier to use for network systems by bringing the Async Rust experience closer to parity with sync Rust. In 2025H1 we plan to:
  • tell a complete story for the use of async fn in traits, unblocking wide ecosystem adoption;
  • improve the ergonomics of Pin, which is frequently used in low-level async code; and
  • prepare to support asynchronous (and synchronous) generators in the language.
• Continue helping Rust support low-level projects by stabilizing compiler options and tooling used by the Rust-for-Linux (RFL) project. In 2025H1 we plan to:
  • implement RFC #3716 to allow stabilizing ABI-modifying compiler flags to control code generation, sanitizer integration, and so forth;
  • taking the first step towards stabilizing build-std by creating a stable way to rebuild core with specific compiler options;
  • add rustdoc features to extract and customize rustdoc tests (--extract-doctests);
  • stabilize clippy configuration like .clippy.toml and CLIPPY_CONF_DIR;
  • stabilize compiler flags to extract dependency info (e.g., as via -Zbinary-dep-depinfo=y) and to configure no-std without requiring it in the source file (e.g., as via -Zcrate-attr);
• Address the biggest concerns raised by Rust maintainers, lack of face-to-face interaction, by organizing the Rust All-Hands 2025. In 2025H1 we plan to:
  • convene Rust maintainers to celebrate Rust's tenth birthday at RustWeek 2025 (co-organized with RustNL);
  • author a first draft for a Rust vision doc and gather feedback.

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.

Goal	Point of contact	Team
"Stabilizable" prototype for expanded const generics	[Boxy][]	[lang], [types]
Bring the Async Rust experience closer to parity with sync Rust	[Tyler Mandry][]	[compiler], [lang], [libs-api], [spec], [types]
Continue resolving cargo-semver-checks blockers for merging into cargo	[Predrag Gruevski][]	[cargo], [rustdoc]
Declarative (macro_rules!) macro improvements	[Josh Triplett][]	[lang], [wg-macros]
Evaluate approaches for seamless interop between C++ and Rust	[Tyler Mandry][]	[compiler], [lang], [libs-api]
Experiment with ergonomic ref-counting	[Santiago Pastorino][]	[lang]
Expose experimental LLVM features for GPU offloading	[Manuel Drehwald][]	[compiler], [lang]
Extend pubgrub to match cargo's dependency resolution	[Jacob Finkelman][]	[cargo]
Externally Implementable Items	[Mara Bos][]	[compiler], [lang]
Finish the libtest json output experiment	[Ed Page][]	[cargo], [libs-api], [testing-devex]
Implement Open API Namespace Support	![Help Wanted][]	[cargo], [compiler]
Implement restrictions, prepare for stabilization	[Jacob Pratt][]	[compiler], [lang], [spec]
Improve state machine codegen	[Folkert de Vries][]	[compiler], [lang]
Instrument the Rust standard library with safety contracts	[Celina G. Val][]	[compiler], [libs]
Making compiletest more maintainable: reworking directive handling	[Jieyou Xu][]	[bootstrap], [compiler], [rustdoc]
Metrics Initiative	[Jane Lusby][]	[compiler], [infra]
Model coherence in a-mir-formality	[Niko Matsakis][]	[types]
Next-generation trait solver	[lcnr][]	[types]
Nightly support for ergonomic SIMD multiversioning	[Luca Versari][]	[lang]
Null and enum-discriminant runtime checks in debug builds	[Bastian Kersting][]	[compiler], [lang], [opsem]
Optimizing Clippy & linting	[Alejandra González][]	[clippy]
Organize Rust All-Hands 2025	[Mara Bos][]	[leadership-council]
Prepare const traits for stabilization	[Oliver Scherer][]	[compiler], [lang], [types]
Promoting Parallel Front End	[Sparrow Li][]	[compiler]
Prototype a new set of Cargo "plumbing" commands	![Help Wanted][]	[cargo]
Publish first rust-lang-owned release of "FLS"	[Joel Marcey][]	[bootstrap], [spec]
Publish first version of StableMIR on crates.io	[Celina G. Val][]	[compiler], [project-stable-mir]
Research: How to achieve safety when linking separately compiled code	[Mara Bos][]	[compiler], [lang]
Run the 2025H1 project goal program	[Niko Matsakis][]	[leadership-council]
Rust Vision Document	[Niko Matsakis][]	[leadership-council]