Setting our vision for the 2017 cycle
Recently we’ve been discussing a roadmap process for the Rust project. Part of that process is setting a project agenda each year by identifying 8-10 key problems we want to try to tackle across the project, which taken together represent a major increment in Rust’s evolution. This post lays out some preliminary thoughts on vision statements for the 2017 cycle.
Overview
There’s no end of possible improvements to Rust—so what do we use to guide our thinking?
The core team has tended to view things not in terms of particular features or aesthetic goals, but instead in terms of making Rust successful while staying true to its core values. Part of that success is for Rust to be increasingly used in production settings, but how much and for what things is something we can and should debate on this thread. More on the core values a bit later.
Rather than trying to identify some particular killer app(s) and drive toward them, our strategy has primarily been to knock down the clearest impediments to Rust adoption that are in front of us, see what doors that opens, then rinse and repeat. The 2016 survey provides a trove of valuable information here—it’s essential background for this discussion—and it directly informs several of the proposed problem statements. These proposals represent the areas we’re most confident need attention this year.
With that out of the way, onto the initial proposals!
In one year’s time:
- Rust should have a lower learning curve
- Rust’s compiler should be significantly faster
- Rust should have basic IDE support
- Rust’s core ecosystem should be maturing
- Rust should have 1.0-level libraries for concurrency and parallelism
- Rust should be well-equipped for writing servers
- Rust should provide a more seamless FFI story
- Rust’s community should provide mentoring at all levels
Below are brief elaborations on each point.
These vision statements are deliberately a bit vague. It’s clear that there are important problems in all of these areas, but the precise problems to focus on, their relative priority, and crisp, realistic goals for the year are all open questions. The list should likely grow a bit as well. Our hope is to have a robust, community-wide discussion oriented mainly around the problems, ultimately leading to a more crisp set of vision statements with rationales and goals. After that discussion, we’ll make a revised version in RFC form and go from there (assuming that the roadmap process RFC is accepted, of course!)
Rust should have a lower learning curve
Rust unique features make it valuable, but also means there’s a lot to learn. A common refrain is “the first couple of weeks are tough, but it’s oh so worth it.” How many people are bouncing off of Rust before they get through those first couple of weeks? How many team leads are reluctant to introduce Rust because of the training needed? 1 in 4 survey respondents mentioned the learning curve.
Some potential avenues: improved docs/training materials; improved compiler errors; language improvements (e.g. things like non-lexical lifetimes).
Rust’s compiler should be significantly faster
Bottom line, the edit-compile-test cycle in Rust takes too long, and it’s one of the complaints we hear most often from production users. We’ve laid down a good foundation with MIR (now turned on by default) and incremental compilation (expected to hit alpha this week). But we need to continue pushing hard to actually deliver the improvements.
Depending on how far we want to take IDE support (see below), pushing incremental compilation up through the earliest stages of the compiler may also be important.
Rust should have basic IDE support
For many people—even whole organizations—IDEs are an essential part of the programming workflow. In the survey, 1 in 4 respondents mentioned requiring IDE support before using Rust seriously. Tools like Racer and the IntelliJ Rust plugin have made great progress this year, but compiler integration has yet to get off the ground, and there’s a lot of room to do more.
Rust’s core ecosystem should be maturing
Another major message from the survey and elsewhere is that Rust’s ecosystem, while growing, is still quite immature (1 in 9 survey respondents mentioned this). Maturity is not something we can rush. But we should think about steps we can take to build more momentum around maturity, and think about what “maturity” means to us (e.g., that core functionality exists, is easy to find, and is of high quality).
Some potential avenues: discoverabiliy/curation; 1.0 releases of “core” crates; surveying “batteries included” stdlibs for gaps in Rust’s ecosystem; tooling and guidelines to encourage crate quality.
Rust should have 1.0-level libraries for concurrency and parallelism
Rust’s potential for fearless concurrency across a range of paradigms is one of the most unique and exciting aspects of the language. But we aren’t fully delivering on this potential, due to the immaturity of libraries in the space. The response to work in this space, like the recent futures library announcement, suggests that there is a lot of pent-up demand and excitement, and that this kind of work can open a lot of doors for Rust. In general, then, getting our concurrency/asynchrony/parallelism story in 1.0 shape seems like a particularly important segment of the ecosystem to focus on.
Rust should be well-equipped for writing servers
Shifting gears somewhat, probably the biggest area we’ve seen with interest in production Rust is the server, particularly in cases where high-scale performance, control, and/or reliability are paramount. At the moment, our ecosystem in this space is nascent, and production users are having to build a lot from scratch. Investing in the server ecosystem could make a huge impact this year. But we’ll need to talk through more detail about how, where, and what to invest in.
Rust’s should provide a more seamless FFI story
An essential adoption vector for Rust is to use it for building components in a larger system. For this use-case to really sing, we need a seamless “FFI” experience. The meaning of “FFI” here is potentially quite broad—from making it trivial to bind unsafe C APIs (#include somelib.h for Rust), to C++ integration, to embedding in languages like Ruby, Python or JS, to compiling to wasm. We’ve been making progress on all of these fronts, but to make an even bigger impact, we could consider choosing a small number of such scenarios to really focus on as a community this year.
Rust’s community should provide mentoring at all levels
The Rust community is awesome, in large part because of how welcoming it is. But we could do a lot more to help grow people into roles in the project, including pulling together important work items at all level of expertise to direct people to, providing mentoring, and having a clearer on-ramp to the various official Rust teams. Outreach and mentoring is also one of the best avenues for increasing diversity in the project, which, as the survey demonstrates, has a lot of room for improvement.
Other possibilities, or potential non-goals
We’ve tried to keep the initial list conservative, containing items that the core team is confident are of utmost importance this year for the project. But there are lots of additional possibilities, e.g.:
- Making Cargo work well in more contexts (e.g. big existing build systems)
- Adding compiler/platform targets
- Producing more API bindings for core platform libraries
- Improving our story for programming embedded systems/OSes
- More robust project infrastructure (CI, nightlies, Crater, performance metrics, dashboards)
- More systematic outreach/evangelism
- A revamped web presence
What else is missing? And, in an effort to focus on the most important priorities, what can we say should not be on the agenda this year?
A word on core values
Part of what makes Rust so exciting is that it attempts to eliminate some seemingly fundamental tradeoffs. One important such tradeoff is between safety and speed. Rust promises
- uncompromising reliability
- uncompromising performance
and it delivers. But are we compromising something else? Are we paying with decreased productivity?
I think we’re all proud of Rust’s ergonomics and modern tooling. But can we do better? Are there places where we are forcing explicitness that don’t really buy you much? Can we build libraries that make it easier to rapidly prototype? Can we improve ergonomics while keeping Rust code robust and fast by default? These kinds of productivity gains can also pay dividends for learnability. They can lower the apparent cost of using Rust. Taken together with goals around learnability, tooling improvements, and ecosystem maturation, they lead to a possible overall theme for the year (and ambition for Rust):
- Rust: safe, fast, productive—pick three.
That’s not to say that there’s not already stuff out there heading the right direction, but I do feel it should be part of the vision to get Rust infrastructure more production ready.