Roadmap for 2019 #2657
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,328 @@ | ||
| # 2019 Roadmap | ||
|
|
||
| - Feature Name: N/A | ||
| - Start Date: 2019-03-07 | ||
| - RFC PR: rust-lang/rfcs#0000 | ||
| - Rust Issue: N/A | ||
|
|
||
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| This RFC proposes the *2019 Rust Roadmap*, in accordance with [RFC 1728]. The | ||
| goal of the roadmap is to lay out a vision for where the Rust project should | ||
| be in a year's time. | ||
|
|
||
| [RFC 1728]: https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db243d639aee6e46d35d75/text/1728-north-star.md | ||
|
|
||
| The proposal is based on the [2018 survey], our annual [call for blog posts], | ||
| direct conversations with individual Rust users, and discussions at the 2019 | ||
| Rust All Hands. Thanks to everyone who helped with this effort! | ||
|
|
||
| [2018 survey]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html | ||
| [call for blog posts]: https://readrust.net/rust-2019/ | ||
|
|
||
| In short, 2019 will be a year of **rejuvenation and maturation** for the Rust | ||
| project. Much of the focus is on **strengthening our foundations** and | ||
| **paying down debt**, both technical and organizational. | ||
|
|
||
| # Detailed description | ||
| [Detailed description]: #detailed-description | ||
|
|
||
| In 2018, the Rust team came together around a shared vision: Rust 2018, our | ||
| first real edition. We not only decided to develop Rust 2018, but also the | ||
| idea of editions themselves, all in one year. 2018 was also a fantastic year | ||
| for production usage of Rust. Some of the largest names in tech have started | ||
| relying on Rust as a key part of their stack. Smaller companies have started | ||
| to build great things with our technology as well. | ||
|
|
||
| Looking at the [2018 Rust Survey] results, one can start to see a shift as | ||
| well. Rust projects are [growing larger], with [more and more people using | ||
| Rust at work][r@w]. Ergonomics no longer ranks as the number one concern | ||
| amongst respondents: [instead, we see a need for mature libraries, a better | ||
| IDE experience, and more Rust adoption][challenges]. | ||
|
|
||
| [challenges]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#challenges | ||
| [r@w]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#rust-at-work | ||
| [growing larger]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#how-much-do-you-use-rust | ||
| [2018 Rust Survey]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html | ||
|
|
||
| Shipping the 2018 edition was both a herculean task and a great success. But | ||
| it also created a lot of debt, both technical and organizational. When | ||
| reading the Rust 2019 blog posts, and when having conversations with team | ||
| members at the Rust All Hands, a general theme developed: 2019 should still | ||
| be a year of shipping, but a certain kind of shipping. Words like confidence, | ||
| maturity, practicality, productivity, sustainability, and stability were | ||
| often used. This should be a year of reflection, one of polish, one of | ||
| finishing plans that were started long ago. | ||
|
|
||
| In some ways, it's easier to describe what this year should *not* be, rather | ||
| than what it should be. This should not be a year of dreaming up large new | ||
| features, one of drastic change, or one that makes your old code feel | ||
| obsolete. | ||
|
|
||
| Here's some select quotations from a few Rust 2019 posts that really | ||
| resonated with folks: | ||
|
|
||
| > Let’s finish what we started. As much as is possible and practical this | ||
| > year, let’s set aside new designs and ship what we’ve already designed. Let’s | ||
| > tackle challenges we haven’t had time to give our full attention. | ||
| > | ||
| > - Jonathan Turner, ["The fallow year"](https://www.jonathanturner.org/2018/12/the-fallow-year.html) | ||
|
|
||
| > I believe not only that the processes and institutions of Rust need to be | ||
| > shored up, but that special attention should be paid to people. Ultimately, | ||
| > people are what drives the language forward, whether it be through design, | ||
| > implementation, or outreach. If no people want to work on Rust, or are | ||
| > blocked from working on Rust, the language will stagnate. ... | ||
| > | ||
| > This is not to say that there should not be any movement on improving | ||
| > features or process. Just that their effects and costs should be measured in | ||
| > people, as well as in technology. | ||
| > | ||
| > - Cessen, ["Rust 2019 - It's the Little Things"](https://blog.cessen.com/post/2018_12_12_rust_2019_its_the_little_things) | ||
|
|
||
| > In this post, I’ll refer to a highly simplified maturity life cycle with | ||
| > three stages: research, development, and polish. Different parts of the Rust | ||
| > ecosystem are at different levels of maturity. It’s important for effort to | ||
| > match the actual stage in the life cycle, ideally to push it to the next. For | ||
| > example, I consider the language to mostly be in the “polish” stage. | ||
| > Continuing to treat it as research would bring dependent types, virtual | ||
| > structs, etc., which would be interesting but disruptive. Conversely, we | ||
| > don’t know exactly what we want for GUI, so trying to drive that to a | ||
| > standardized solution too early will likely get us to a suboptimal place. | ||
| > | ||
| > Many mature products have alternating releases focused on new features, | ||
| > then stabilization... 2018 has seen a lot of new features, so I think it’s | ||
| > time for a stabilization phase. | ||
| > | ||
| > - Raph Levien, ["My thoughts on Rust 2019"](https://raphlinus.github.io/rust/2018/12/16/rust-2019.html) | ||
|
|
||
| > If you’re familiar with the history of Rust you might be confused with a | ||
| > call to stabilization. After all, Rust 2015 (a.k.a 1.0) was all about | ||
| > stabilization and the team has actually done a pretty good job with achieving | ||
| > this goal. So what gives? | ||
| > | ||
| > While Rust 2015 defined stabilization around language backward | ||
| > compatibility, it’s time for the language, the tooling, the ecosystem and the | ||
| > governance to stabilize. Each of these characterize stability in a different | ||
| > way. | ||
| > | ||
| > - Ryan Levick, ["Rust 2019: Stabilization"](https://blog.ryanlevick.com/posts/rust-2019/) | ||
|
|
||
| > The Rust project has been growing like a startup for the last several | ||
| > years. This has some good aspect - “hockeystick curves” - but it has some | ||
| > very bad aspects as well. If this project is going to have a chance of | ||
| > sustaining itself in the long term, we need to get real about dealing with | ||
| > the organizational debt we have accumulated. I think we have serious problems | ||
| > at every level of our organization that need to be addressed, and I’m going | ||
| > to enumerate them from my personal perspective. | ||
| > | ||
| > - withoutboats, ["Organizational Debt"](https://boats.gitlab.io/blog/post/rust-2019/) | ||
|
|
||
| We don't have space to quote every single post; if you'd like to read them | ||
| all, you can over at [Read Rust](https://readrust.net/rust-2019/). And of | ||
| course, these themes are not *universally* shared among Rust developers, but | ||
| there is a common theme in many of them: slow down, pay off debt, finish what | ||
| we've started. | ||
|
|
||
| # By team | ||
| [By team]: #by-team | ||
|
|
||
| With this general theme in mind, here are the high-level plans from each of | ||
| the teams for the upcoming year, in alphabetical order. These summaries are | ||
| based on discussions had at the All Hands; each team may also post a more | ||
| detailed individual roadmap. The summaries are meant to show plans in broad | ||
| strokes and how they fit together for the project. | ||
|
|
||
| ## Cargo | ||
|
|
||
| The [cargo team 2019 roadmap](https://gist.github.com/nrc/6f0fb3b66d3b043aace30217128f3af9) identifies a few major themes: | ||
|
|
||
| - **Better support for cross compilation:** | ||
| - Try to incorporate some of the innovations from tools like [Xargo](https://github.com/japaric/xargo), [cross](https://github.com/rust-embedded/cross), [Rustup](https://github.com/rust-lang/rustup.rs), and [WASM-Pack](https://github.com/rustwasm/wasm-pack) into cargo itself. | ||
| - **Focus on the cargo ecosystem by supporting plugins (custom commands):** | ||
| - Custom commands enable faster experimentation, bringing new and flexible workflows to users sooner rather than later. | ||
| - Make plugins more discoverable. | ||
| - Provide library crates for parts of cargo to make it easier to create plugins. | ||
| - **Compile times:** | ||
| - Investigate ways that cargo can help to reduce compilation time, including potentially distributing binaries for builds from crates.io. | ||
|
There was a problem hiding this comment. That would mean supporting binaries for a lot of targets (which is ok IMO). There can also be a target "MIR" where people could build crates from the MIR code, saving some time in parsing/type-checking/borrow-checking. This could be done with a fallback mechanism: is there a binary matching my target? if not use MIR, if that doesn't exist as well build from source. There was a problem hiding this comment. Of course there is the problem of conditional compilation ( There was a problem hiding this comment. It also makes me a bit wary security-wise, but I guess that can be discussed at the time... |
||
| - **Addressing technical debt:** | ||
| - There are a number of parts of cargo that could use refactoring, and we plan to spend some time on that. | ||
| - **Finishing "almost complete" work:** | ||
| - Work on [custom registries](https://github.com/rust-lang/cargo/issues/6589), | ||
| [offline mode](https://github.com/rust-lang/cargo/issues/4686), and | ||
| [custom profiles](https://github.com/rust-lang/cargo/issues/2007) is nearly done, and we intend to see those items over the finish line. | ||
steveklabnik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ## Community | ||
|
|
||
| The community team has decided to make "solidifying" the theme of the year. | ||
| While it has a lot of ideas of what could be done, a lot of existing projects | ||
| are useful and would be more so with more time and investment. Projects like | ||
| RustBridge, event support, the YouTube channel and modernizing the community | ||
| calendar will take priority. | ||
|
|
||
| Internationalization will also be a big subject over the next year. This both | ||
| means making Rust more accessible to non-English speakers and growing our | ||
| global reach. This will bring with it organizational changes to allow the | ||
| team to grow out of its current locations. It's hard to contribute to the | ||
| community team if you are in timezones incompatible with meetings in US/EU | ||
| timezones and the community team wants to change that. | ||
|
|
||
| ## Compiler | ||
|
|
||
| The compiler team has five main themes of work for this year: | ||
|
|
||
| - **Improving "core strength"** by lowering raw compilation times and also generating better code (which in turn can help with compilaton times) | ||
steveklabnik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - **Improved IDE integration**, including support for typed completions | ||
| - Extracting parts of rustc into **libraries**, which are easier to understand and maintain but also help in developing a Rust specification | ||
| - Supporting lang team in **key feature development**, such as around `async fn` support, or improvements to the trait system | ||
| - Improving our **documentation** and **organization**, helping to make it clearer what is going on at any given time, and how people can get involved. | ||
|
|
||
| Some of the specific projects we have in mind are as follows: | ||
|
|
||
| - **Parallelizing rustc**, which should help with improving raw compilation times and also increasing IDE responsiveness. | ||
| - Introducing **MIR optimizations**, which will improve the quality of our generated code, but also may help reduce compilation time by giving LLVM less work to do (LLVM remains a large percentage of overall compilation time). | ||
| - Introducing **working groups** for each project, and track them on the [compiler-team repository](https://github.com/rust-lang/compiler-team). | ||
|
|
||
| One project worth calling out in more detail is the [**RLS 2.0 | ||
| effort**](https://github.com/rust-lang/compiler-team/tree/master/working-groups/rls-2.0). | ||
| The existing RLS, while functional, was never deeply integrated into rustc | ||
| itself. Over the past two years, we have rewritten the back end of rustc to | ||
| use an **incremental and demand-driven infrastructure.** To get the IDE | ||
| experience we truly want, we need to see that work through for the front end | ||
| of the compiler as well. However, this part of rustc is one of its oldest, | ||
| and there are significant design questions involved in how best to do that. | ||
|
|
||
| This is where the RLS 2.0 effort comes in. **The plan is to build a prototype | ||
| of the new front-end, thus enabling a truly first-class IDE experience.** | ||
| Wherever possible, we aim to share code between this front-end and rustc by | ||
| extracting libraries, such as [Chalk] (for traits), [Polonius] (for the | ||
| borrow checker), and a new library focusing on name resolution. Eventually, | ||
| we will merge this new front-end with the remaining bits of back-end from | ||
| rustc. | ||
|
|
||
| [Chalk]: https://github.com/rust-lang-nursery/chalk | ||
| [Polonius]: http://github.com/rust-lang-nursery/polonius | ||
| [rust-analyzer project]: https://github.com/rust-analyzer/rust-analyzer | ||
|
|
||
| ## Crates.io | ||
|
|
||
| One of the newer teams, the Crates.io Team is going to be focused on growing | ||
| itself, paying down technical debt in the codebase, and establishing themes | ||
| for long-term priorities. | ||
|
|
||
| ## Dev Tools | ||
|
There was a problem hiding this comment. Getting cargo miri to stable would also be great. There was a problem hiding this comment. MIR isn't meant to be stable, so this can't really be done easily, nor do I think the MIR folks want to (It's potentially useful to ship cargo miri with rustup on stable, though) There was a problem hiding this comment.
That's what I mean here. (But my other suggestion in the compile time section would imply a stable (or versioned) MIR.) |
||
|
|
||
| The Dev Tools team has a few core functions: | ||
|
|
||
| - liasing with the wider project | ||
steveklabnik marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - being a bit of a "commons" space for cross-cutting tools concerns | ||
| - finding out what needs are yet to be addressed by tooling and filling them | ||
| - providing some kind of quorum helping smaller tool subteams make decisions | ||
|
|
||
| They'll be working to fulfill these functions this year, along with looking | ||
|
There was a problem hiding this comment. For a roadmap, the approach of listing "core functions" and then saying the team will work to fulfill these functions this year seems a bit weak. Is that different from last year, and if so, how? If all the specific measurable goals are pursued by subteams, maybe this section can just be left out? There was a problem hiding this comment. It is different from last year, last year the devtools team didn't really have these core functions. It somewhat implicitly did but didn't necessarily actively pursue them. We've only recently enumerated these and decided to start moving towards them. I don't consider the roadmap to be a place for only measurable goals. |
||
| for ways to improve their internal processes. | ||
|
|
||
| Individual devtools subteams may be coming up with their own roadmaps, you | ||
|
There was a problem hiding this comment. How many dev-tools subteams do we want to enumerate here? For example, i wrote out the roadmap for the Rustdoc Team over here, which was summarized in the All-Hands recap post for the dev-tools team. There was a problem hiding this comment. If you add it to the devtools repo I think we can list it here There was a problem hiding this comment. I'm not sure! It can't hurt to have it in the text, I think. I'm open to opinions! There was a problem hiding this comment. Yeah. We can inline the text or just put it in the devtools repo and link it, either works for me. There was a problem hiding this comment. I think putting it in the dev-tools repo and linking it here is probably best; since the IDEs roadmap is linked externally, adding a similar mention to rustdoc won't be too much of a stretch. There was a problem hiding this comment. Update: The Rustdoc 2019 roadmap is now live on the Dev-Tools Team repo. I don't know if you wanted to post an edit yourself, or if you wanted me to post a PR to add it to this. There was a problem hiding this comment. (The more the merrier, is my opinion) There was a problem hiding this comment. This still needs to be added btw |
||
| can see the one of Cargo above, and the IDE team | ||
| [here](https://github.com/rust-dev-tools/dev-tools-team/blob/master/roadmaps/ides-and-editors-2019.md). | ||
|
|
||
| ## Documentation | ||
|
|
||
| The documentation team is going to be completely reformulating itself, and | ||
|
There was a problem hiding this comment. Is the idea that the learning team RFC will still be in time for this RFC? |
||
| possibly re-naming itself as the "learning team." They're working on an RFC | ||
| to do so, and that will lay out the roadmap. Stay tuned! | ||
|
|
||
| ## Language | ||
|
|
||
| The language team has four areas of interest this year: | ||
|
|
||
| - **Organizational:** | ||
| - [Introduce working groups](http://smallcultfollowing.com/babysteps/blog/2019/02/22/rust-lang-team-working-groups/) with the goal of increasing transparency and lowering the barrier to get involved | ||
| - Create a [lang-team repository](https://github.com/rust-lang/lang-team/) to help track what is happening and how to get involved | ||
| - **Key ergonomic improvements:** | ||
| - Async/await in particular is needed to help "unlock" Async I/O | ||
| - **Finish long-standing features:** | ||
| - Rust has a number of in-progress features -- such as const generics, Generic Associated Types, and specialization -- that have been in development for some time. It's time to finish their designs and ship them. | ||
| - **Reference material and guidelines:** | ||
| - Work with the documentation team on the Rust reference. | ||
| - Produce "unsafe code guidelines" that describe what unsafe code can and cannot do. | ||
|
|
||
| ## Library | ||
|
|
||
| The library team will be focusing on maintaining the standard library. The | ||
| team will handle specialized tasks such as overseeing and reviewing ports of | ||
| the standard library to new platforms, as well as typical bug fixes and | ||
| performance improvements. | ||
|
|
||
| The team doesn't currently have the bandwidth to take on a large number of | ||
| new features for the standard library, but is specifically planning to | ||
| develop a plan of attack for custom allocators associated with instances of | ||
| collections (e.g. `Vec<T, A: Alloc>`). | ||
|
There was a problem hiding this comment. cc @rust-lang/release Do we want to say anything here? (also @rust-lang/infra is missing but y'all presumably have plans re. CI?) There was a problem hiding this comment. Both teams opted to not add anything specific. There was a problem hiding this comment. @steveklabnik Well... at least for T-Release iirc we didn't really discuss the RFC itself... more like the roadmap in general; but we probably should do that next Wednesday. :) There was a problem hiding this comment. I checked with @Mark-Simulacrum and @aidanhs and they both felt like they didn't want to add anything, but I'm certainly game to include plans that exist. =) |
||
|
|
||
| # Working Groups | ||
|
|
||
| In addition to the Rust teams, we also have a number of active **working | ||
| groups** that report to the core team. These groups are tasked with exploring | ||
| a particular domain and making recommendations to other Rust teams with | ||
| decision-making power. This section contains the 2019 priorities for each of | ||
| these working groups. | ||
|
|
||
| [2018 Roadmap RFC]: https://rust-lang.github.io/rfcs/2314-roadmap-2018.html | ||
|
|
||
| ## Async Foundations and Async Ecosystem | ||
|
|
||
| The 2018 roadmap comissioned a "Networking Services" domain working group. | ||
| Since then, that working group has [split into two | ||
| parts](https://blog.yoshuawuyts.com/async-ecosystem-wg/): | ||
|
|
||
| - __The "Async Foundations" effort__, which is being led by the language design team, will focus on building the 'core building blocks' that belong to the language itself, such as the `Future` trait and `async`-`await` syntax. | ||
| - __The "Async Ecosystem" working group__, meanwhile, will focus on nurturing the budding ecosystem built on top of those layers. The plan for 2019 is to focus on the [Tide web framework], and help expand the ecosystem around async/await. | ||
|
|
||
| [Tide web framework]: https://docs.rs/tide/0.0.5/tide/ | ||
|
|
||
| ## CLI apps | ||
|
|
||
| The CLI working group's [2019 | ||
| roadmap](https://paper.dropbox.com/doc/0lRnShqsfMlfS6ylXrX9h) focuses on | ||
| three main themes: | ||
|
|
||
| - the **design and maintenance of clap v3.0** | ||
| - working on the **testing crates**, such as [`assert_cli`](https://crates.io/crates/assert_cli), [`assert_fs`](https://crates.io/crates/assert_fs), and [`assert_cmd`](https://crates.io/crates/assert_cmd) | ||
| - improving the **organizational structure** of the WG through meetings, organization, and branding | ||
|
|
||
| ## WebAssembly | ||
|
|
||
| The [2019 WebAssembly WG roadmap](https://github.com/rustwasm/rfcs/pull/7) | ||
| adopts the overall theme of **practicality**. The intent is to focus on these | ||
| areas: | ||
|
|
||
| - Grow our library ecosystem by collaborating on a modular toolkit. | ||
| - Bring multithreading to Rust-generated Wasm. | ||
| - Integrate best-in-class debugging support into our toolchain. | ||
| - Polish our toolchain and developer workflow, culminating in a 1.0 version of `wasm-pack`. | ||
| - Invest in monitoring, testing, and profiling infrastructure to keep our tools and libraries snappy, stable and production-ready. | ||
|
|
||
| ## Embedded "bare metal" devices | ||
|
|
||
| The Embedded WG's [2019 | ||
| Roadmap](https://paper.dropbox.com/doc/ZmUYvRp4PjX1jqq6LSxcZ) designates | ||
| **productivity** as their theme for 2019. They plan to focus on three main | ||
| points: | ||
|
|
||
| - Documentation, specially intermediate level docs covering API design patterns and coding guidelines | ||
| - Maturing the ecosystem: growing existing libraries and highlighting projects to serve as examples | ||
| - Filling the gaps: getting toolchain bugs fixed and polishing existing tools | ||
|
|
||
| ## Secure code | ||
|
|
||
| The [Secure code working group](https://github.com/rust-secure-code/wg) is a | ||
| newer working group focused on making it easy to write secure code in Rust. | ||
| The [2019 | ||
| roadmap](https://medium.com/@shnatsel/security-as-rust-2019-goal-6a060116ba39) | ||
| for the Secure Code working group focuses on four areas of improvement: | ||
|
|
||
| - Distribution of security patches | ||
| - Improving code authentication | ||
| - Reducing the need for unsafe code | ||
| - Better verification of the standard library | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So while this was one of the posts that I saw a number of people quote and at least for me generated a lot of recognition, it feels like the RFC covers very few of the issues, or in general, the topic of organizational debt. Adding back the core team section to suggest work on governance might help with that a little bit, but feels to me like it doesn't give this group of issues the priority that it deserves.