In January of this year, we adopted the 2017 Rust Roadmap, 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.
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 list of issues on the rust-roadmap repo. 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.
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 (roadmap issue), and we now have a complete draft available online. 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 pre-order a printed version through No Starch Press. If you'd like to help out, there is still lots of editing work to be done!
We've also been working on a number of language changes aimed at
improving language ergonomics. These range from long-standing
proposals, like non-lexical lifetimes or impl Trait, to
newer ideas, like the recently approved RFCs on trait aliases and
match ergonomics. On the roadmap issue, 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!
We've been targeting the problem of improving compiler performance in
a number of different ways. One of the simplest is the
cargo check command that we released in Rust 1.16
-- 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 the "beta" release of incremental on nightly builds. 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 the incremental compilation roadmap issue or the tracking issue for the new algorithm itself; you can also follow this internals thread, 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
the perf.rust-lang.org website 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
major performance improvements. 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
tracking issue on this topic for more.
Since it first debuted at RustConf last year, the Rust Language Service (RLS) has been growing rapidly (roadmap issue). 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 the racer project). 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 install the RLS directly through rustup.
If you'd like to give the RLS a spin, the easiest way is to use the VSCode plugin; however, the RLS is a generic server (it speaks Microsoft's Language Server Protocol), 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 roadmap issue or the RLS issue listing; in particular, those things tagged with "good first issue".
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 categories and a number of badges that crate authors can add to their crates. These help people find crates for a particular purpose and judge a crate’s quality at a glance. In addition, RFC 1824 laid out a plan for improving the default sort in crates.io and exposing additional information to help in selecting a crate. There is a tracking issue 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 "cookbook" described below will also be a boon for discovering crates in a task-centric way.
We've made some excellent strides the first half of this year towards
making Rust well equipped for writing robust servers. The futures
crate and Tokio project continue to explore the asynchronous I/O
ecosystem and have seen some heavy usage through crates like Hyper
and production users like linkerd-tcp. Additionally we've seen
projects like Rocket continue to tirelessly improve the ergonomics
of Rust-on-the-server. A recent discussion of what the biggest
blockers are today has highlighted that async/await 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.
The Libz Blitz 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 API guidelines, filing and fixing the issues that arise, and writing examples for a new "cookbook" of Rust examples.
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 introductory post on the internals thread.
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:
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 tracking issue!
When it comes to mentoring, we've been pursuing a few different efforts. The first, RustBridge, is specifically aimed at bringing underrepresented folks into tech; it also serves as a great curriculum for people completely new to Rust. The materials have already been through several iterations and continue to evolve and improve, and we are going to be running a RustBridge workshop the day before RustConf. We would like to see more RustBridge events.
We also just launched Increasing Rust's Reach, an initiative for hearing more from groups currently underrepresented in Rust (or technology more generally), and working together to make Rust accessible to a wider audience. While this isn't a mentorship program per se (in many cases, it's the participants who are doing the teaching!), it is still geared toward lowering the on-ramp to Rust's community.
In addition, the various Rust teams have been pursuing a number of different initiatives trying to encourage people to get involved in the Rust project itself:
In addition to the main roadmap items, the roadmap RFC called out two "areas of exploration". These are areas with strong potential for Rust that are still in a more exploratory phase.
The embedded Rust ecosystem continues to grow. A bare metal concurrency framework for Cortex-M microcontrollers geared towards robotics and control systems has been recently developed. And Tock, an embedded OS that also targets Cortex-M microcontrollers, has been making progress towards pure Rust userland applications and continues growing its driver support.
On the compiler side support for the MSP430 architecture has been improving thanks to the community's effort, and support for the AVR architecture is also being worked on, out of tree, by the community.
On the community side efforts in standardizing the development workflow are on going with the creation and development of guides, project templates, core crates and tooling. Recently a survey to identify the current needs of embedded developers was performed and the corresponding roadmap issue was updated to reflect the results. In response to the survey results a community effort to create a Hardware Abstraction Layer, that will serve as a base for building the embedded crate ecosystem, has been started and the design discussion is currently on going. An "Are we embedded yet?" web site that will reflect the up to date state of the embedded ecosystem and track its progress is also being worked on.
(Thanks to Jorge Aparicio for this writeup.)
bindgen Updatebindgen is the frontier for automating integration
of C and C++ libraries into Rust code bases. bindgen takes header
files as input, and outputs the appropriate foreign function and type
declarations so that the C/C++ library can be used with minimal effort
from Rust.
bindgen has become a crucial infrastructure for the Stylo project,
which brings Servo's style system to Firefox. As the Stylo project nears
shipping, we've been hammering bindgen into shape for production. This has
manifested itself as tons of reliability and correctness work. Our test suite is
ever expanding, we've been focusing on correctness of struct layout, size, and
alignment for ABI corner cases such as bitfields, as well as test coverage and
support across different versions of libclang.
At the same time, we've been working to improve the contribution experience. We've been documenting workflows, adding visualizations of our internal representation for debugging, and mentoring new contributors. Since the creation of the Rust DevTools team, we've also been talking with other toolsmiths about fostering contribution to common tools. Expect to hear more on this soon.
Finally, we also introduced a bindgen Users Guide to
help folks get up and running with bindgen in their project.
(Thanks to Nick Fitzgerald for this writeup.)
Higher level languages come with their own integration challenges, often involving cooperation with an external runtime system (which possibly includes a garbage collector). Here's a quick rundown of some of the major projects on this front:
There are many less high-profile projects in this space as well; if you'd like yours to be tracked as part of the roadmap, please leave a comment on the tracking issue!
In conclusion, you can see that it's been a very busy six months in Rust land. I'd like to thank all the many people who have been involved in pushing these projects over the finish line!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
