Reasonable Performance

Rust 2019

December 9, 2018

(This is my response to the call for Rust 2019 Roadmap blog posts.)

In 2019, there are three areas where I would like to see the Rust community focus its efforts:

Improved compile times

I already wrote about compile times in Rust (see Rust at Work—Two Paint Points and How to alleviate the pain of Rust compile times), and I don’t have much more to add. I just want to re-iterate that this issue is very important and that it should be given the attention it deserves.

The Rust compiler is much slower than the compilers of some “competing languages” such as Go, D, or Jai. As Jonathan Blow put it when he first announced that he was working on a programming language, long compile times are a constant source of friction for developers: they lengthen the write-test loop and they disrupt the programmer’s flow. The success of Go can partly be attributed to its quick compile times; it compiles fast enough that it feels like an interpreted language. (Of course, other factors contributed to Go’s success—an extensive standard library, a vibrant ecosystem, a friendly community, great tooling, good performance, etc.) I want new Rust programmers to not be turned off by Rust’s long compile times and I want veteran Rust programmers to iterate more quickly and wait less on rustc.

The situation is improving. Incremental recompilation has been merged and tools like sccache can speed up compilation in CI. Nicholas Nethercote detailed his experiments in making rustc faster. A new, upcoming backend, cranelift, appears to be faster than the current LLVM backend.

I think most Rust programmers realize that improved compile times would be beneficial to everyone, and I look forward to seeing improvements on that front in 2019.

A community effort to review crates

Rust would not be used nearly as much if it weren’t for Cargo and crates.io. The rich ecosystem of Rust is what made it go from an interesting programming language project to a tool that many now use in production. In 2019, I would like to see a code review effort from the Rust community. The goal of these reviews is to provide answers to two questions for anyone looking for a crate.

What are the quality crates? What are the best crates for making HTTP requests, for consuming from Kafka, or for manipulating dates? Are those crates reliable enough for business-critical services? Should I have concerns about their performance or security? Is the code easy to understand and modify? In a nutshell, how does one find quality crates?

At the moment, we try and decide if a crate is worth checking out based on word-of-mouth, number of downloads, number of GitHub stars, the name of the contributors, etc. Code reviews would be stronger indicators of quality, because someone actually read the code. On Reddit, Dawid Ciężarkiewicz announced crev, a language-agnostic tool for publishing and signing code reviews and forming webs of trust. A tool like that would be ideal for the crates ecosystem. At my place of work, we’ve reviewed a number of the crates that we use in production, to convince ourselves that they were worth using. We’d love to have a place to share that work with the reset of the community.

Is this crate compromised? In 2018, we heard a few stories (1, 2) about malicious packages in NPM, the Node.js package repository. I don’t think I’ve heard about any backdoors in a crate yet, but I see nothing that would make such attacks impossible. (We did have an issue back in October with squatting that actually led to a degradation of service.)

These attacks will undoubtedly become more common in the coming years. Some aspects of Cargo make these attacks more difficult: the immutability of crates and the ability to pin dependencies at a particular version (ideally, a versio that has been reviewed). Active code reviews would provide an extra line of defense against these attacks. They would also, hopefully, increase the overall quality of the most popular crates.

More “80% solutions”

Improved compile times and code reviews require time and effort, and are not likely to occur overnight. While we wait, I’d like to see more “80% solutions”—projects that perform a task well enough, but without being perfect. We are lucky to have some incredibly high-quality projects in the Rust ecosystem: serde, hyper, reqwest come to mind. They are also what I’d call 100% solutions: they offer all the features that users could possibly want and they have extremely good performance. They are also complex beasts, and that makes them more difficult to review. Some of these projects (e.g., hyper) also have many dependencies, which makes the review process even more difficult, and also increases compile times.

An example of an 80% project is miniserde: unlike serde, JSON is the only serialization format that miniserde supports, and some Rust datatypes like enums cannot be encoded. Miniserde has also 10x less code than serde (tokei reports 2379 lines of Rust code for miniserde vs. 25,205 for serde) so it’s much easier for a single person to do a full review of the code.

I’d love to see more such projects: a simple HTTP server for services that just need a /status endpoint; an HTTP client that can send simple requests and write the responses in a Write object.