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.
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".
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.
percent-encode) have higher download counts, even though users are much more likely to directly use something much higher-level like
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:
futuresis higher than
tokiois higher than
lazy_staticis higher than
once_cell- I'm guessing this is a momentum thing?
proc_macro2seem a bit high even though they're low level details of much more popular proc-macro crates
rayonfeel a bit low if we are talking about an "extended std"
- I'm surprised to see
hashbrowngetting a mention considering it's already available as
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
hashvbrown works with no_std and exposes a couple of useful methods.
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.
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
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
Tokio really does have more crates using it as a direct dependency than
Future trait is in
std, so you don't need the
futures crate unless you want the extra functionality.
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
dashmap and several other crates. Indirectly it ends up used in 20% of all crates!
Heh, you learn something new every day
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.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.