curation has little, if any, curation. I As a language matures, it needs more of that, as it goes from "has anyone written code to do X" to "we have ten crates to do X and they all have problems." Both Perl and Python went through this process long ago. Go's libraries are curated by, mostly written by, and used by Google staff, so they tend to be well-exercised. It's about that time for Rust.

s anybody working on that?

There are still too many crates that haven't reached 1.0 yet. Hyper, with 50 million downloads, is still at v0.14.19.

Some incentive is needed to get crate developers to get from "almost finished" to "version finished".
Maybe give crates a blue checkmark if they reach basic milestones such as 100,000 downloads, a version of 1.0 or higher, and no issues open for more than 30 days. Return those results first in crate search. Developers involved with a blue-checkmark project get some kind of badge.

Hey, it works for Twitter and LinkedIn. Comments?


Having some sort of "Accomplishment" system could be quite a useful motivator for going 1.0 and help with discovery.

Even if we don't want to build it into directly, a more opinionated frontend like might be a good place for it (cc @kornelski because he's one of the main developers) and the "Ranking System" section on the about page already touches on a lot of this.

Of course, "When a measure becomes a target, it ceases to be a good measure" and people will always try to game the system, but a solution that isn't 100% comprehensive can still be plenty useful[1].

Maybe it's time to move this forward now the Rust foundation has been established and there is potential for paid roles.

  1. (insert comment about letting crates be namespaced here) ↩︎


I doubt the team would be willing to do this "curation" work. Third parties will, though of course the question then is to whom to pay attention.

One effort I remember at a "curated" list of crates was stdx from brson (who was a major member of the Core Team back when the Core Team was just "the Team")


On this note, npm has measures of popularity, quality and maintaince, based on various metrics. It seems to work pretty well in my experience.


Download counts can (and have) been spoofed. Version 1.0 is a decision of the crate authors alone, and a repository with some notion of “issues” is optional; additionally, popular crates will regularly have issues open for longer than that, especially if issues for feature requests are permitted; if anything, few (and thus few long-lived) issues is a good indicator that the crate is not really used by anyone.


I think was (or is) meant more as a (forgive me the wording, I know there is a lot of work in it) "data dump" platform:

  • everyone can upload
  • no namespaces
  • no depublication guidelines other than "we do not delete packages, except when we do, but we don't talk about it in the rules" (see also my experiences here)
  • almost no metadata changes after publication possible (I think except for crate ownership and the yanking flag, which is one(!) bit of metadata)
  • no automatic rating (or not much? Downloads, dependencies, and other stats are counted, but not really connected or further processed in any manner.)
  • no manual rating

It certainly serves a good purpose though and "works".


Good idea. How would you go about that?

Yeah. Have to watch for people running up their personal badges with trivial pull requests. Some hackathon resulted in a huge number those on Github, annoying maintainers.

My usuau concerns tend to be with crates where there's unfinished dirty laundry. As in, doesn't work on Mac. Doesn't work unless on main thread. Doesn't work on Wayland. Doesn't work if optional generic type parameter is not default. Doesn't work in full screen mode. Modal dialog gets stuck behind main window. Unexplained memory corruption in async mode. I've run into all of those this month. That's what I mean by wanting an incentive to encourage crate authors to take their crates from "almost finished" to "finished".

None of these are fun, exciting problems to work on. They're just things that can slow a project down by a week or more. This is the sort of thing which discourages production use of Rust.


I'm not sure whether such a curation needs (or should be) mixed up with the place where crates are "stored". Even if there was an "official recommendation list for packages" (made up by real humans or good AI algorithms, or both), could still stay the "data dump" it is and serve its purpose as such. From another thread:

However, we should also acknowledge that is more than just one Rust package repository. It is the default package registy on almost every installation of Rust. That gives it a special role (and responsibility?).

I guess it's a philosophical question whether (being in that role) should stay most "neutral" as in not judging about packages in any way, or be more trustworthy (perhaps a bit like an app store for consumers?) by providing more guidance. I don't really want to say that one or the other direction is best – just bringing up some thoughts.

1 Like

That's what I had in mind when I suggested could be a good place for this sort of "curation".

A 3rd party site can be as opionionated as it wants without exposing the core Rust project to any forms of favouritism. It also offers a way to skip the bikeshedding and analysis paralysis that you get from something like the RFC process because there is no need to convince the wider community of something (just look at how the threads you linked to would go around in circles for hundreds of comments without reaching any sort of resolution).

I'm guessing you could go through the foundation's grants program, probably under the "Project Grants" section.


Comparing to curation process, maybe the other direction should worth exploring.

Such as add extra library to rust compiler as extension of core/std library, which contains curated or recommended high quality battle-tested stable and matured enough packages collection; in the meantime as a natural part of nightly build toolchain we can keep them update as

Furthermore as a bonus, through extra we also get a pre-compiled most used popular libraries which keep us from compiling huge source code again and again, increase build speed, reduce memory consumption.

Yes, is it.

It's meant to be opinionated. It has its own ranking algorithm. It aggressively removes deprecated and unmaintained crates. It combines data from multiple sources and often overrides crate's metadata. It bans users for spam and squatting.


When I started using Rust I thought it was a pain to find suitable crates for certain types of projects. For "regular" (what I like to call "allowed to grow without upper bound, because 'memory/storage is cheap'") server/desktop application it wasn't as difficult, but I do some work in embedded -- but not just no_std kind, but "sort-of server, but highly resource constrained" systems. And for those environments it is/was a challenge to find the appropriate crates.

My perspective: I don't want a The One Curated list, because with some Rust ecosystem experience it's pretty easy to find out what The Big Defacto Crates(tm) are.

However, say I'm in a constrained environment, and I have very specific needs: I don't want the binary size to explode (no multiple sha2 implementations, no two async runtimes, no two TLS runtimes, no 0.X.0 version of a http library and a 0.Y.0 version of the same library, etc).

My idea for this was to establish a new meta-entity, which isn't necessarily a crate, just a database of:

  • Rules and Goals for the crate collection.
  • Crates that match those rules and goals.

Each maintainer for such a collection would manually update their curated list of crates. Then someone (with specific needs) could go to that database and specify their search parameters for what their needs are, and get a list of collections that (should) suite their need.

I wrote a brain-dump of the idea here:

The basic idea is to have what I called "freighters" that are maintained by people with specific needs, though this could trivially be extended to have one freighter being maintained by core Rust members and be called something like "Main-stream crates" (though i think that term may have negative connotations these days..).

I always get a little weary when I see suggestions for a The One List of Approved crates, because it makes me fear that people who make specialized crates feel that their work will never be seen, so there's no point in working on them. (But this may just be me projecting).

I did have a Devious And Secret Plan(tm) with this whole idea: Crate developers may become aware of some of the quirky needs that exist out there, that they don't (but could) fulfill.

(I will stress though that since I wrote that original post, the number of accidental duplicates has been reduced dramatically. It's no longer as big of an issue as I found it to be back then).

I started working on such a database a while back, but got side-tracked by $DAYJOB, and have with time come to realize I would rather see something like that integrated into or

If I'm asked to develop an embedded product with specific constraints, I wold love to be able to go to Some Site(tm), and get a list of curated collections by some search parameter (like "embedded", "resource-constrained", "no-duplicates", "http-server", "no-gpl" (these would be collection tags, not crate tags)), then I'd browse through the list of collections, read their mission statement, and when I find one that matches our overall needs, do a final check to make sure the crates support the specific features we need.

In the same way, the vast majority of users could just go to some "blessed by core developers" collection on the same site.

For my "99.9%" use-cases I like idea of adding a "blue checkmark". But those aren't really the cases where I need help finding suitable crates -- my problem is finding crates for the 0.1% cases, and I fear those crates would be even more buried by a "blue checkmark" system.


This is off-topic, but those unbalanced quotes are really triggering me :joy:


Fixed! :slight_smile:

1 Like

I'm less concerned about ranking than completeness. Ranking is more of a social media thing. Completeness is a quality thing. The object here is to provide an incentive for crate maintainers to do the last 5% of the job.

1 Like

Just because a crate is not 1.0 does not mean it's not reliable/battle-tested (see: Hyper). Rather, I think 1.0 is more a promise that the API will not change in any significant way.

And in the Rust community seems like the 1.0 version is treated with even more caution than usual.

A hand-curated list of crates (like others mentioned in the previous comments) for various targets (embedded, constrained server environment, regular backend, etc etc) might be more effective than relying on the version number / download statistics.


I think a great way to do this is not just to have a list but to write a book about the topic, using those crates.

Like how there's not some list of "send a pull request to add your CLI crate!" (which is better as crate metadata), but there's Getting started - Command Line Applications in Rust that gives an opinionated take on "here's how to do this kind of task, using these crates that we recommend".


Right. Which is why widely used crates, on which other crates depend, need to advance to 1.0 and get the no breaking changes guarantee.

You get that with 0.x crates too.


Not really. See this previous discussion on that.

What I'd like to get past is lore-based programming. As in "everybody knows hyper is stable even it it's below 1.0". Lack of a stability guarantee is a negative for organization adoption of Rust.

It took years for the language and compiler people to get their side settled. Remember when every time you downloaded a new compiler, you had to change your code? Remember all those "only works in nighly"crates? We're past that stage. Now the crates need to settle, too.