Spark Browser. Rust's 2017 roadmap, six months in Jul 5, 2017 • Nicholas Matsakis In January of this year, we adopted the, which laid out our plans for 2017. As part of the roadmap process, we plan to regularly release updates on the progress of each roadmap item. This post marks the halfway point through the year. Tracking progress via roadmap issues First, a meta note. If you’d like to follow along with the progress on a particular roadmap initiative, or to find out more about how you can get involved, the best place to go is the. There you will find an issue dedicated to each of the major initiatives that we are pushing on.
These issues contain links to ongoing work. You’ll find a number of links to issues like this in the descriptions that follow. Rust should have a lower learning curve The most direct way to make Rust easier to learn is to improve the way that we teach it.
To that end, we’ve been hard at work on a brand new edition of the official “Rust” book (), and we now have a. This new edition puts ownership front and center and it also has expanded coverage of a number of other areas in Rust, such as error handling, testing, matching, modules, and more. Even better, you can through No Starch Press. If you’d like to help out, there is still We’ve also been working on a number of language changes aimed at improving.
Rust has a system whereby it openly declares the vulnerability of a new players, and thus in theory the pointlessness of killing them. This system is quite famous, because it involves schlongs and racks.
These range from long-standing proposals, like or, to newer ideas, like the recently approved RFCs on and. On the, you will find a large list of initiatives, organized by the part of the language that they target (e.g., ownership/borrowing, the trait system, etc). We are actively looking for people to help with writing RFCs but also implementing the accepted RFCs – if you’re interested in helping out with something, look for the “mentoring” contacts listed in the roadmap issue or on the tracking issue for a specific RFC. And, of course, if you think you’ve got a good idea that’s not listed, open up a thread on internals and let’s talk about it! Rust should have a pleasant edit-compile-debug cycle We’ve been targeting the problem of improving compiler performance in a number of different ways.
One of the simplest is the – this command does a limited form of compilation which skips code-generation and simply looks for errors. Since code generation typically takes 50% or more of compilation time, this can be really useful in the early stages when you are writing new code and trying to get it to compile, particularly if you have a multi-crate project. This command is also used by the RLS. Of course, eventually you want to run your code, and for that you need a full compilation. In order to make that faster, we’ve been hard at work retooling the compiler to work in an incremental fashion. Earlier this year, we advertised.
While the beta version sometimes achieved quite large speedups, we also found that the dependency tracking was not as robust or effective as we would like. Therefore, we are now adopting a new and improved approach to incremental compilation that we expect be ready in the next month or so. If you’re interested in helping with the transition to the new system, check out or; you can also follow, where we regularly post links to bugs that include mentoring instructions.
Looking beyond incremental compilation, we’ve also been taking steps to optimize compilation time in other ways. Probably the most important step in that respect has been getting a new version of up and running. The “perf” website tracks the effect of each and every PR on compilation performance, so that we can detect and correct regressions. In fact, the new website immediately led to some.
There is still lots of work that could be done to improve it, however, ranging from evaluating and improving our benchmark suite to improving the web interface; see the for more. Rust should provide a solid, but basic IDE experience Since it first debuted at RustConf last year, the Rust Language Service (RLS) has been growing rapidly ().
It now offers support for most basic IDE operations, such as “jump to definition” or “find all uses”, as well as offering code completion (via ). At this point, the focus is primarily on polish: making the RLS easier to install and fixing bugs.
For example, we recently made it possible to. If you’d like to give the RLS a spin, the easiest way is to use; however, the RLS is a generic server (it speaks Microsoft’s ), and there are also clients available for a number of other editors. A word of warning: at this point, the RLS is still in an “alpha” period. While it is eminently usable, you may encounter bugs or other limitations. If you’d like to get involved with the RLS, check out the or the; in particular, those things tagged with.
Rust should provide easy access to high quality crates As the size of the crates.io ecosystem has grown, the simple search and sorting criteria used by the crates.io website are no longer that helpful for figuring out which crates you should use. To address this, we’ve added and that crate authors can add to their crates. Limewear.
These help people find crates for a particular purpose and judge a crate’s quality at a glance. In addition, laid out a plan for improving the default sort in crates.io and exposing additional information to help in selecting a crate. There is that lists the pieces of this RFC, and we’d love contributions towards those pieces!
Once the RFC is completely implemented and people have had a chance to use the features for a while, we plan to ask the community for feedback and make adjustments. In addition, the effort on the described below will also be a boon for discovering crates in a task-centric way. Rust should be well-equipped for writing robust servers We’ve made some excellent strides the first half of this year towards making Rust well equipped for writing robust servers. The crate and project continue to explore the asynchronous I/O ecosystem and have seen some heavy usage through crates like and production users like. Additionally we’ve seen projects like continue to tirelessly improve the ergonomics of Rust-on-the-server. A of what the biggest blockers are today has highlighted that notation, better Tokio/futures documentation, and a solid HTTP foundation for the ecosystem are some of the next highest priorities.
We plan to enable async/await notation on the nightly Rust channel by the end of the year and position it for stabilization in early 2018. This in turn should help fuel a rewrite of Tokio’s/ future’s documentation and continue to grow community support for crates such as HTTP. Rust should have 1.0-level crates for essential tasks The proceeds apace! The Libz Blitz is a systematic effort to identify the most broadly used crates in the Rust ecosystem and to ensure that they all meet a consistent level of completeness and quality. This effort entails collaborating on the internals forum to review crates according to the, filing and fixing the issues that arise, and writing examples for a new. The effort is structured to be highly amenable to contribution, particularly from new Rust developers, and so far has resolved 99 crate issues across 10 crates, and created more than 30 examples for the cookbook, thanks to the efforts of 53 contributors. If you’re interested in participating, take a look at the.
Rust should integrate easily into large build systems Most work on build system integration has focused on more clearly identifying what the challenges are and developing concrete proposals that target them. Some of the current avenues for exploration are: • • (rather than via arbitrary build scripts as we do today) We are hoping to pick up the pace on this work in the second half of the year, but could use help doing so. If either of the above Cargo improvements is of interest to you, or if you have insights on build system integration in general, please reach out on the! Rust’s community should provide mentoring at all levels When it comes to mentoring, we’ve been pursuing a few different efforts.