This scoring seems like a very incomplete story of importance in the ecosystem, and is misleading with regards to reusability which should be considered for inclusion in the standard library. Afterall, adding more baggage to everyone's download should at least come with overall useful payload.

Take memoffset for example whose download number comes overwhelmingly from a single crate, crossbeam . Or nodrop whose last release has marked it as deprecated after having been dropped from its main using crate arrayvec , by the same author (see above, @bluss beat me to the punch). Can a single major use be taken as an incentives to inclusion in std ?

On the case of phf_shared / phf_generator they are very minimal indeed. However, how useful are they on their own? The extremely costly dependency phf_macros , pretty much required to actually make use of its powers compared to standard hash functions, is not capture by the metrics.

And fuchsia-cprng is also curious since the description already disputes any cross-platform usability: Type-safe bindings for the Zircon kernel's CPRNG. . While that confirms that at least some party connected to Google Fuchsia is a prominent user of Rust & crates.io (Are other crates internally cached, or why don't all fuchsia crates show up that high?) it does not qualify the crate for inclusion in std in any way. And since the metrics rank it that high, that makes me question the metrics.