53 KiB
- 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 Traitcapture bounds work (RFC #3498 and RFC #3617) - reserving the
genkeyword 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
- a change in how
- 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
Servicetrait; - 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.
- resolving the "send bound problem", thus enabling foundational, generic traits like Tower's
- Resolve the biggest blockers to Linux building on stable Rust via:
- stabilizing support for arbitrary
selftypes 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;
- stabilizing support for arbitrary
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
| Goal | Owner | Notes |
|---|---|---|
| Standard reviews | ||
| ↳ Optimization work | Alejandra González |
compiler team
| Goal | Owner | Notes |
|---|---|---|
| Collaboration with GSoC proc-macro project | ||
| ↳ Explore sandboxed build scripts | Weihang Lo | |
| Discussion and moral support | ||
| ↳ Stabilize parallel front end | Sparrow Li | |
| Policy decision | ||
| ↳ |
Jakub Beránek | |
| Standard reviews | ||
| ↳ Patterns of empty types | @Nadrieril | |
| ↳ Async drop experiments | Vadim Petrochenkov | |
| ↳ Arbitrary self types v2 | Adrian Taylor | |
| ↳ Use annotate-snippets for rustc diagnostic output | Esteban Kuber, Scott Schafer | |
| ↳ Ergonomic ref-counting | Jonathan Kelley | |
| ↳ Expose experimental LLVM features for automatic differentiation and GPU offloading | Manuel Drehwald | |
| dedicated reviewer | ||
| ↳ Production use of annotate-snippets | Esteban Kuber, Scott Schafer | Esteban Kuber will be the reviewer |
crates-io team
| Goal | Owner | Notes |
|---|---|---|
| Approve RFC | ||
| ↳ Yank crates with a reason | 二手掉包工程师 | |
| Standard reviews | ||
| ↳ Yank crates with a reason | 二手掉包工程师 | |
| Try it out in crates.io | ||
| ↳ Yank crates with a reason | 二手掉包工程师 |
lang team
leadership-council team
| Goal | Owner | Notes |
|---|---|---|
| RFC decision | ||
| ↳ Assemble project goal slate | Niko Matsakis |  |
| ↳ Rust 2024 Edition | TC | (RFC #3501) |
libs team
| Goal | Owner | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Survey tools suitability for Std safety verification | Celina V. | |
| Org decision | ||
| ↳ Async WG reorganization | Niko Matsakis | |
| Standard review | ||
| ↳ Survey tools suitability for Std safety verification | Celina V. | We would like to contribute upstream the contracts added to the fork. |
libs-api team
| Goal | Owner | Notes |
|---|---|---|
| RFC decision | ||
| ↳ Trait for async iteration | Eric Holk | |
| ↳ Ergonomic ref-counting | Jonathan Kelley | |
| Stabilization decision | ||
↳ Extended offset_of syntax |
Ding Xiang Fei |
rust-analyzer team
| Goal | Owner | Notes |
|---|---|---|
| Standard reviews | ||
| ↳ Stabilize next-generation solver in coherence | lcnr | |
| ↳ Support next-generation solver in rust-analyzer | lcnr |
rustdoc team
| Goal | Owner | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Make Rustdoc Search easier to learn | Michael Howell | |
| RFC decision | ||
| ↳ Stabilize doc_cfg | Guillaume Gomez | |
| Standard reviews | ||
| ↳ Stabilize doc_cfg | Guillaume Gomez | |
| ↳ Implement "merged doctests" to save doctest time | Guillaume Gomez |
rustdoc-frontend team
| Goal | Owner | Notes |
|---|---|---|
| Design meeting | ||
| ↳ Improve on any discovered weaknesses | Michael Howell | |
| FCP review | ||
| ↳ Improve on any discovered weaknesses | Michael Howell | |
| Standard reviews | ||
| ↳ Improve on any discovered weaknesses | Michael Howell |
types team
| Goal | Owner | Notes |
|---|---|---|
| Discussion and moral support | ||
| ↳ Const traits | Deadbeef | |
| ↳ Next-generation trait solver | lcnr | |
| ↳ "Stabilizable" prototype for expanded const generics | Boxy | |
| FCP decisions | ||
| ↳ Associated type position impl trait | Oliver Scherer | |
| Stabilization decision | ||
| ↳ Stabilize next-generation solver in coherence | lcnr | |
| ↳ Rust 2024 Edition | TC | |
| ↳ Associated type position impl trait | Oliver Scherer | |
| Standard reviews | ||
| ↳ Stabilize next-generation solver in coherence | lcnr | |
| ↳ Support next-generation solver in rust-analyzer | lcnr | |
| ↳ Scalable Polonius support on nightly | Rémy Rakic | Matthew Jasper |
| ↳ Testing infra + contributors for a-mir-formality | Niko Matsakis |
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.