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. 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 thantokio
tokio
is higher thanfutures
-
lazy_static
is higher thanonce_cell
- I'm guessing this is a momentum thing? -
syn
,quote
, andproc_macro2
seem a bit high even though they're low level details of much more popular proc-macro crates -
tracing
andrayon
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 asstd::collections::HashMap
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.
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.
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!
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.