A list of the most-used Rust libraries

I've created a list of the most popular Rust libraries. Unlike the crates.io top list, this one takes into account number of direct reverse dependencies, number of unique users using the crates, and downranks crates that are losing popularity.

33 Likes

Long-term goal for this is to be a list of crates that are de-facto Rust's standard library. I'm open to suggestions what should be the criteria for crates to be "standard".

10 Likes

Wow, I'm impressed with how closely that list lines up with my intuition!

I like how it deals with the fact that low-level crates (e.g. syn and percent-encode) have higher download counts, even though users are much more likely to directly use something much higher-level like serde_derive and url. I'm guessing you use the number of direct reverse dependencies as the primary metric for sorting and use the others to tweak it?

I'm not sure how to quantify it, but here are some rankings which I don't necessarily agree with:

  • futures is higher than tokio tokio is higher than futures
  • lazy_static is higher than once_cell - I'm guessing this is a momentum thing?
  • syn, quote, and proc_macro2 seem a bit high even though they're low level details of much more popular proc-macro crates
  • tracing and rayon feel a bit low if we are talking about an "extended std"
  • I'm surprised to see hashbrown getting a mention considering it's already available as std::collections::HashMap
2 Likes

Really very nice! I have been missing something like that for a long time.

In the long run, I'm not sure whether an approach entirely based on numbers/metrics will be sustainable. If a list of popular Rust libraries gets popular, then this could cause feedback effects on how people publish their crates (e.g. avoiding indirect reverse dependencies in favor of direct ones, etc).

Perhaps in the end, it needs manual adjustment or bootstrapping through a seed at discretion from a board (or responsible person).

Another potential for improvement could be to ensure diversity regarding "niche" application fields. Let me try to explain what I mean with a hypothetical example: Rather than listing the 4th propular crate for performing FFTs/DFTs, it might make sense to instead list a most popular crate for DCTs, even if the most popular DCT crate is less "popular" than the 4th popular DFT-providing crate. I'm not sure how this can be achieved, however, without manual classification.


Or instead of the hypothetical example, an actual real one: We see no single FFT crate in the list at all, but six random related creates (of which half belong to the rand suite).

hashvbrown works with no_std and exposes a couple of useful methods.

2 Likes

I'm guessing futures is used with all async runtimes, while tokio is one runtime.

I'd think so as well - I almost reflexively type cargo add lazy_static even though I should stop that.

rayon did feel a bit low. I'm not too surprised about tracing - I learnt about tracing wayy too late, and that too thanks to Amos including it in just about every article.

2 Likes

Sorry, I wrote that the wrong way around... tokio is ranked higher than futures even though futures is used by almost all runtimes and end users would be pulling it in for things like Stream, somu_future.and_then(), and so on.

I'm curious how the algorithm decided one runtime was more popular than something that arguably belongs under std::future.

Tokio really does have more crates using it as a direct dependency than futures. The Future trait is in std, so you don't need the futures crate unless you want the extra functionality.

The lazy_static vs once_cell case needs tweaking. once_cell gets more downloads, but lazy_static has more crates using it as a dependency.

hashbrown is still used to get more control over hashing and memory allocation. It's used in indexmap, dashmap and several other crates. Indirectly it ends up used in 20% of all crates!

4 Likes

Heh, you learn something new every day :sweat_smile:

Structopt has been folded into Clap, so it's slightly unfortunate that structopt is on the list too.

Overall, though, this is a wonderful resource; thanks for creating it.

1 Like