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.
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), crates.io could still stay the "data dump" it is and serve its purpose as such. From another thread:
However, we should also acknowledge that crates.io 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 crates.io (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.
That's what I had in mind when I suggested lib.rs 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).
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 crates.io.
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.
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 libs.rs or crates.io.
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.
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.
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".
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.
I agree (and probably others do as well) that tribal knowledge helps no one. It would be great if it were (somehow) explicit what crates are “stable”, just not sure what the best way is. Also, there’s nothing anyone can do to force maintainers to go to 1.0; it’s at their discretion how they want to run their project. Though writing up some recommended guidelines around stability guarantees that maintainers can choose to follow more closely would be nice. Is there not such a doc floating around already? I haven’t seen one.