|
1 | | -> * This goal slate has been accepted as [RFC #3672].* |
| 1 | +# Rust project goals for 2024H2 |
2 | 2 |
|
3 | | -## Summary |
| 3 | +>  [RFC #3672] has been **accepted**, establishing [<!-- #GOALS --> total Rust project goals for 2024H2](./goals.md). |
4 | 4 |
|
5 | | -The Rust project has accepted <!-- #GOALS --> total project goals for 2024H2, with 3 designated as flagship goals: |
| 5 | +## Want to learn more? |
6 | 6 |
|
7 | | -* [Release the Rust 2024 edition](./Rust-2024-Edition.md) (owner: @traviscross) |
8 | | -* [Bring the Async Rust experience closer to parity with sync Rust](./async.md) (owners: @tmandry, @nikomatsakis) |
9 | | -* [Resolve the biggest blockers to Linux building on stable Rust](./rfl_stable.md) (owners: @joshtriplett, @nikomatsakis) |
10 | | - |
11 | | -Read on to learn more about our goal program! |
12 | | - |
13 | | -## Motivation |
14 | | - |
15 | | -This RFC marks the first goal slate proposed under the experimental new roadmap process described in [RFC #3614]. It consists of <!-- #GOALS --> project goals, of which we have selected three as **flagship goals**. Flagship goals represent the goals expected to have the broadest overall impact. |
16 | | - |
17 | | -### How the goal process works |
18 | | - |
19 | | -**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. |
20 | | - |
21 | | -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. |
22 | | - |
23 | | -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. |
24 | | - |
25 | | -### Rust’s mission |
26 | | - |
27 | | -Our goals are selected to further Rust's mission of **empowering everyone to build reliable and efficient software**. Rust targets programs that prioritize |
28 | | - |
29 | | -* reliability and robustness; |
30 | | -* performance, memory usage, and resource consumption; and |
31 | | -* long-term maintenance and extensibility. |
32 | | - |
33 | | -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. |
34 | | - |
35 | | -### Axioms for selecting goals |
36 | | - |
37 | | -We believe that... |
38 | | - |
39 | | -* **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. |
40 | | -* **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. |
41 | | -* **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. |
42 | | - |
43 | | -## Guide-level explanation |
44 | | -[guide-level-explanation]: #guide-level-explanation |
45 | | - |
46 | | -### Flagship goals |
47 | | - |
48 | | -The flagship goals proposed for this roadmap are as follows: |
49 | | - |
50 | | -* [**Release the Rust 2024 edition**](./Rust-2024-Edition.md), which will contain |
51 | | - * a change in how `impl Trait` capture bounds work ([RFC #3498] and [RFC #3617]) |
52 | | - * reserving the `gen` keyword to allow for generators ([RFC #3513]) |
53 | | - * never type fallback ([#123748]) |
54 | | - * and a [number of other potential changes](https://github.com/rust-lang/rust/issues?q=label%3AC-tracking-issue+label%3AA-edition-2024+label%3AS-tracking-ready-to-stabilize%2CS-tracking-needs-documentation+-label%3AS-tracking-impl-incomplete%2CS-tracking-design-concerns) that may be included if they make enough progress |
55 | | -* [**Bring the Async Rust experience closer to parity with sync Rust**](./async.md) via: |
56 | | - * resolving the "send bound problem", thus enabling foundational, generic traits like Tower's [`Service`](https://docs.rs/tower-service/latest/tower_service/trait.Service.html) trait; |
57 | | - * stabilizing async closures, thus enabling richer, combinator APIs like sync Rust's [`Iterator`](https://doc.rust-lang.org/std/iter/trait.Iterator.html); |
58 | | - * 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. |
59 | | -* [**Resolve the biggest blockers to Linux building on stable Rust**](./rfl_stable.md) via: |
60 | | - * stabilizing support for arbitrary `self` types and unsizeable smart pointers, thus permitting ergonomic support for [in-place linked lists](https://rust-for-linux.com/arc-in-the-linux-kernel) on stable; |
61 | | - * stabilizing features for labeled goto in inline assembler and extended `offset_of!` support, needed for various bts of low-level coding; |
62 | | - * adding Rust For Linux project on Rust CI, thus ensuring we don't accidentally cause regressions for this highly visible project (done!); |
63 | | - * stabilizing support for pointers to statics in constants, permitting the construction of vtables for kernel modules; |
64 | | - |
65 | | -[MCP 727]: https://github.com/rust-lang/compiler-team/issues/727 |
66 | | - |
67 | | -#### Why these particular flagship goals? |
68 | | - |
69 | | -**2024 Edition.** 2024 will mark the 4th Rust edition, following on the 2015, 2018, and 2021 editions. Similar to the [2021 edition](https://github.com/nikomatsakis/rfcs/blob/rfl-project-goal/text/3085-edition-2021.md), 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. |
70 | | - |
71 | | -**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](https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Survey-2023-results.html) indicating that they use Rust to build server-side or backend applications. |
72 | | - |
73 | | -**Rust for Linux.** The [experimental support for Rust development in the Linux kernel][RFL.com] 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][RFL#2], blocking the effort from ever going beyond experimental status. For 2024H2 we will work to close the largest gaps that block support. |
74 | | - |
75 | | -[RFL.com]: https://rust-for-linux.com/ |
76 | | -[RFL#2]: https://github.com/Rust-for-Linux/linux/issues/2 |
77 | | - |
78 | | -### Project goals |
79 | | - |
80 | | -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](#reference-level-explanation) section below. |
81 | | - |
82 | | -Some goals here do not yet have an owner (look for the ![Help wanted][] badge). Teams have reserved some capacity to pursue these goals but until an appropriate owner is found they are only considered provisionally accepted. If you are interested in serving as the owner for one of these orphaned goals, reach out to the mentor listed in the goal to discuss. |
83 | | - |
84 | | -<!-- GOALS 'Accepted,Orphaned' --> |
85 | | - |
86 | | -# Reference-level explanation |
87 | | -[reference-level-explanation]: #reference-level-explanation |
88 | | - |
89 | | -The following table highlights the asks from each affected team. |
90 | | -The "owner" in the column is the person expecting to do the design/implementation work that the team will be approving. |
91 | | - |
92 | | -<!-- TEAM ASKS --> |
93 | | - |
94 | | -### Definitions |
95 | | - |
96 | | -Definitions for terms used above: |
97 | | - |
98 | | -* *Author RFC* and *Implementation* means actually writing the code, document, whatever. |
99 | | -* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected). |
100 | | -* *RFC decisions* means reviewing an RFC and deciding whether to accept. |
101 | | -* *Org decisions* means reaching a decision on an organizational or policy matter. |
102 | | -* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review. |
103 | | -* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize. |
104 | | -* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated. |
105 | | -* Other kinds of decisions: |
106 | | - * [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) 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. |
107 | | - * Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team. |
108 | | - * Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library. |
109 | | - |
110 | | -[AGS]: ./Project-goal-slate.md |
111 | | -[AMF]: ./a-mir-formality.md |
112 | | -[Async]: ./async.md |
113 | | -[ATPIT]: ./ATPIT.md |
114 | | -[CS]: ./cargo-script.md |
115 | | -[CT]: ./const-traits.md |
116 | | -[ERC]: ./ergonomic-rc.md |
117 | | -[MGCA]: ./min_generic_const_arguments.md |
118 | | -[NBNLB]: ./Polonius.md |
119 | | -[NGS]: ./next-solver.md |
120 | | -[PET]: ./Patterns-of-empty-types.md |
121 | | -[PGC]: ./pubgrub-in-cargo.md |
122 | | -[RFL]: ./rfl_stable.md |
123 | | -[SBS]: ./sandboxed-build-script.md |
124 | | -[YKR]: ./yank-crates-with-a-reason.md |
125 | | -[SC]: ./Rust-for-SciComp.md |
126 | | -[OC]: ./optimize-clippy.md |
127 | | - |
128 | | -<!-- Github usernames --> |
| 7 | +* Read about the flagship goals: |
| 8 | + * **Continue simplifying Rust** by [releasing the Rust 2024 edition](./Rust-2024-Edition.md). |
| 9 | + * **Improve the experience of building network systems in Rust** by [bringing Async Rust experience closer to parity with sync Rust](./async.md). |
| 10 | + * **Enable safe abstractions for low-level systems** by [resolving the biggest blockers to Linux building on stable Rust](./rfl_stable.md). |
| 11 | +* See the [full list of goals](./goals.md). |
| 12 | +* Read [RFC #3672], which describes the rationale and process used to select the goals. |
0 commit comments