Starting with 2017, Rust is following an open roadmap process for setting our aims for the year. The process is coordinated with the survey and production user outreach, to make sure our goals are aligned with the needs of Rust's users. It culminates in a community-wide discussion and ultimately an RFC laying out a vision.
This year, the overarching theme is productivity, especially for early-stage Rust users. From tooling to libraries to documentation to the core language, we want to make it easier to get things done with Rust.
A focus on productivity might seem at odds with some of Rust's other goals. After all, Rust has focused on reliability and performance, and it's easy to imagine that achieving those aims forces compromises elsewhere—like the learning curve, or developer productivity. Is "fighting with the borrow checker" an inherent rite of passage for budding Rustaceans? Does removing papercuts and small complexities entail glossing over safety holes or performance cliffs?
Our approach with Rust has always been to bend the curve around tradeoffs, as embodied in the various pillars we've talked about on this blog:
- Memory safety without garbage collection
- Concurrency without data races
- Abstraction without overhead
- Stability without stagnation
In the core language we've sometimes been able to leverage things like Rust's ownership model to make features easier to use. For example, closures in Rust, unlike those in C++, do not require explicit "capture clauses"; Rust's ownership tracking means that we can automatically infer whether to move or borrow data into the closure, without sacrificing reliability or performance. We've also been working to make the language easier to learn by improving the compiler's error messages. And Cargo is an example of early focus on productivity that has only enhanced the power of systems programming with Rust, allowing for OS projects to easily build and leverage an ecosystem of shared libraries. There's so much more we can do along these lines!
In short, productivity should be a core value of Rust, and we should work creatively to improve it while retaining Rust's other core values. By the end of 2017, we want to have earned the slogan:
- Rust: fast, reliable, productive—pick three.
The roadmap
With that framing in mind, here's Rust's vision for 2017 in a nutshell. Each statement links to a corresponding tracker with more details:
-
Rust should have a lower learning curve. Plans include a new book, collecting examples and patterns, improving errors, improving the core language, and building IDEs.
-
Rust should have a pleasant edit-compile-debug cycle. Plans include incremental compilation and a trait system overhaul.
-
Rust should provide a solid, but basic IDE experience. Plans are focused on the Rust language service.
-
Rust should provide easy access to high quality crates. Plans include crate categories, crate ranking, open-ended testing and benchmarking frameworks, new API and documentation guidelines, and guidelines for unsafe code.
-
Rust should be well-equipped for writing robust, high-scale servers. Plans mostly focus on the Tokio project for asynchronous I/O and potentially async/await notation.
-
Rust should have 1.0-level crates for essential tasks. Plans are under way to focus the libs team and the community on a number of important existing crates, to help polish them to 1.0 quality by the end of the year.
-
Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process.
-
Rust's community should provide mentoring at all levels. Plans include the RustBridge project and new team shepherds.
In addition to these primary goals, we have highlighted two areas we'd like to explore, but where the end point is less clear:
- Integration with other languages, running the gamut from C to JavaScript.
- Usage in resource-constrained environments.
The various Rust subteams are actively working on projects tied to these goals. You can track progress or jump in by watching and commenting on the roadmap tracker. And a fully detailed rationale for the roadmap is in the RFC.
As the year progresses, expect to see many more blog posts announcing roadmap-related initiatives and milestones. Around the end of the year, we'll publish a retrospective aggregating the progress of the year and providing a guide to the current state of Rust.
In the meantime—please get involved! We have ambitious goals for the year, and we need all the help we can get.