Code reuse in Rust
In my opinion, one of the biggest reasons why Rust is so productive is that it’s a superb language for code reuse.
First, ownership and borrowing system allows exposing in the API properties that are often impossible to express in other languages. The fact that the API communicates and enforces how the resources are being created, shared and moved and destroyed, all checked at the compilation time, gives the user great confidence that they are using any API — internal or external — correctly.
Second, Rust comes with first-class built-in tooling around discovering, creating, sharing and using publicly available Open Source libraries. It’s not a property unique to Rust, but it builds a powerful synergy when combined with the first one.
Third, the community (at least so far), were strongly encouraging uniformity and commonality: similar code style, similar documentation style, common core libraries, and patterns. A big chunk of this effort was achieved through great tooling like
Together, this creates a language/ecosystem where code reuse is almost effortless. While in other languages it’s often more tempting and more convenient to implement things yourself and avoid learning a new API, in Rust the difference between own and 3rd party code, often blurs completely. In a way, this creates a completely new
Despite all these strengths, there’s one problem that sticks out like a sore thumb: trust. Every additional dependency is another piece of code that we have could be buggy, or even malicious. And in my opinion, it’s problem so serious, that is entirely blocking the untapped potential of code reuse in Rust.
I’ve been personally bitten by this couple of times this in 2018.
One time, I’ve carelessly used a library that turned out straight buggy with the author refusing to fix or even admit the problem. I’ve used it because the name was very similar to a popular crate that I’ve used before. After I’ve investigated, turns out the author is crates.io name squatter and has plenty of almost-empty or poor quality libraries with very good names, and it’s hard for me to say exactly what is his motivation, but it doesn’t look good at all.
Another time, I’ve badly misjudged a library that looked good, had many authors, and yet, as I was pointed out by a fellow redditor, has some extremely serious performance problems, that makes it pretty much unusable until addressed. The only way to discover this problem was finding one github issue, between many other, innocent looking ones.
As things are right now, it’s very hard to judge the quality of a given crate. The only accessible metric available on crates.io is the download count. Not only can it be artificially inflated, but it is just unreliable: just because crate is popular, doesn’t mean it’s good. Another accessible way: judging crates by their authors, becomes less and less practical, as the ecosystem and user base grows.
On top of it, in 2018, there were at least a couple of instances where NPM ecosystem was shaken by serious security breaches:
It’s just a matter of time before issues like this will start happening in Rust ecosystem too.
crev is a language and ecosystem agnostic Code REView system concept and cargo-crev is its first implementation — tightly integrated with Rust and crates.io.
The idea behind
crev is fairly simple. You create a cryptographic ID, review packages in form of cryptographically verifiable proofs, publish your proofs online and share them with other users. Eventually, a Web of Trust is built, low-quality packages accumulate bad reviews, high-quality packages accumulate more and more good reviews, and it's easy to determine which packages are new and require a higher level of scrutiny.
Let’s take a tour over recently release
Here is the screenshot of using
cargo-crev when reviewing its own dependencies:
The first column (
status) show the cryptographically verifiable trust status of a given crate in a given version. In this case
common_failures crate is
verified because someone within my personal WoT (me), positively reviewed it.
The review proof is available in my Proof Repository
A crate negatively reviewed by someone in my WoT, would show a red
Following columns show:
reviews- the number of review proofs for a given crate version and all versions of it
downloads- https://crates.io download counters to help judge popularity
owners- a number of "known"/"total" crate owners;
cargo crev edit knowncommand allows editing a list of known and somewhat trusted crates.io users
version- the dependency name and version used
The primary role of
downloads is to help narrow down the set of crates which are unpopular and/or don't come from known, well-respected authors. This is especially useful when starting using
crev and trying to prioritize.
With time, I hope the number of users and circulating reviews is going to grow, shifting the focus from
A lot of crates are quite small, and low-intensity review of them takes around 10 minutes. It is not as titanic work, as one might think.
While there’s definitely more to talk about to fully introduce
cargo-crev functionality and features, I think this single screenshot, should give a good initial insight into current state of
Now, after such a long introduction, here is the time for my Rust 2019 wish: I would like the Rust community in 2019 to solve the code trust problem and untap the “fearless code re-use” potential. I know of at least 2 other Rust 2019 series posts:
voicing similar concerns. So I now, I’m not the only one which would like this to happen.
I invite all Rust users to give
cargo crev a try and share their reviews and feedback.