Nice idea.. or is it? It would probably improve the signal-to-noise ratio on the short term.
Risk is that in fine this delegates part of the triage to the Codeberg community.
Maybe having many selection features like this would be a good way to help with triage, without putting too much strain on any one of them. This is in effect another way of crowd sourcing crate vetting.
Another possibility would be to select at random a representative set of crates (call this a training set), say 0,1% or 0,01%, review them manually, and then use statistical analysis or data mining to do this categorization, based on data features that we could all collectively suggest. And find out which are best. Then use machine learning algorithms (low resource consumption, not LLMs) to classify all current and new crates.
Random feature ideas : where crate is hosted, "proof" of actual use, discussions about a crate on this forum, blog reviews or suggestions by rust community, ...
How about scanning the git repository for a lines/characters of code per author per time metric? That being way too high in comparison to other known good quality crates could indicate that the time to polish and refine the code and review it isn't being spent.
Also maybe a churn metric on how often previously committed lines of code change
Personally, I am always very skeptical when large projects appear suddenly on GitHub, with no real history, all published within a few hours. However a possible explanation could be that people developed the project somewhere internally for years, and finally when they consider all the code perfect, push it to GitHub -- or perhaps made a private repository public. I think this is not fully impossible -- I started using GitHub myself in 2015, and then uploaded a few projects, which were stored in Tar files initially. And actually from time to time I clear whole GitHub projects by fully deleting them and recreating, to ensure that old garbage is really gone and does not occupy expensive storage at MicroSoft servers.
That pretty common when company outsources something that they developed for year. Cleaning source and ensuring it's not chock-full company secrets is usually doable, but looking on the whole history to ensure there are no issues is usually not realistic.
Yes, exactly. At very beginning, I coded bad but I did not know. And I really believed it could help others...
If I remember correctly, after deleting, it would still be in your dashboard. It just yanked all versions. When someone displays the dashboard to HR, he/she must not want to show such a bad crate...
EDIT: Wow, I just find crates.io and lib.rs are different websites!!!!!!!! lib.rs seems so cool!
Indeed. I do that sometimes, though rarely, for projects developed on another server and for which I don't want all the files to be public (or the comments). I don't want to hack the repo to filter things out, so I just push the necessary files without the history. Or sometimes I squash a few commits because the intermediate ones are just noise.
I suspect people don't all follow the same script all the time, and since it's only anecdotal to the actual crate's content, I wouldn't use that parameter. Nor would I use the repository's location, GitHub, Codeberg, GitLab, or otherwise (not sure that was a serious suggestion, though). It's too random, and those metrics are easy to fake.
Finding the most recognized crates is nice, but we already have manually curated awesome-* and arewe*yet for this. I mostly use lib·rs to search for less famous crates that fit exactly my needs. Then, my criteria are not number of downloads or dependents, but quality of the readme, dependencies, recent update or repo activity, absence of LLM contribution in the repo, clear API, sometimes a quick review of the code... (absence of repo is a no-go)
I really think a web of trust may be a good solution. It brings back human trust and makes everything easier because zero-trust approaches are either costly, undesirable or inefficient (see most blockchains or open P2P networks). There are many ways to build a web of trust, depending on the security needed. If we want to prevent an individual to maintain dozens of unlinked identities easily, then the criteria for certifying some identity (publicly signing their public key) should be "I have met this person physically (or maybe in video), know how to contact them in the future, am sure it's not a robot, think they are not trying to create multiple identities, and think they respect the same criteria when certifying other people". Such webs of trust exist for real and are not that hard to maintain if the community is dense enough. See a detailed description with more security features. (note: no blockchain required, it can be done "old fashion" like in PGP)
As this is problem is not specific to Rust or even to software packages, there may be a joined effort by multiple communities to avoid having too many webs of trust to maintain.
People may publish signed reviews for crates (e.g. predefined criteria like "code quality", "well documented", "well tested", "functional", "trustworthy"...). If they have more than N certifications, their review is accepted. The closer your are to someone in the web, the more trustworthy their review is. (and if you are not in the web, number of certifications can be a proxy for trustworthiness)
There are even a lot of crates on crates.io that haven’t been updated for nearly ten years. They’re sitting on good crate names, and the library only does a hello world print.
The only limit on creating a new "good" crate name is the imagination of the crate author.
Perhaps someone wants to write a perl language server. Because it is a perl language server they want to use the "good" crate name "perl-lsp" and see it it taken. I think they should just spend some energy and think of a "new" name. For example, the crate name "clap" is great. If there were already a "clap" crate that was a click timer, I am sure the argument parser would have just found a different name. The argument parser crate would not have suffered because it could not get the "clap" name.
If the author, lets say "hackorg" has little imagination in the "crate name" field but has great programming skill they could just name their crates hackorgcratename. If they are great programmers, their name and reputation will propel their crates and allow easy finding on crates.io.
The problem with sitting on good names is less of a problem for a crate author than it is to a crate consumer. I'll sometimes find a crate with a name related to the problem domain I'm working on, with a description that implies it's going to provide solutions for that problem, but an implementation that does absolutely nothing and hasn't been updated since it was first made. Even looking at it is a complete waste of time.
This often fails for the embedded rust ecosystem, as those crates often need special things and tier 3 targets to build. ESP-HAL as well as various embassy crates used to host their docs on their own sites because of this, but seemingly this has changed for embassy since I last looked.
(Fun side fact: embedded crates sometimes cause false positives in typo squatting detectors, as they often have very similar names that are just a jumble of letters and numbers, named after the chip they provide a driver for. Quite often the different crates will be made by different authors.)
Here is an idea: different people want different criteria. Perhaps it is time to extend the search of lib.rs with some filter and/or ranking options. For example, let users filter out crates newer than N days, or with less that N reverse dependencies, or less than N monthly downloads. Another filter could be for old vs new authors.
Conversely there could also be a filter for only looking for new crates. Combine that with a flagging system (with a short list of flaggning reasons) and filters on those flags.
However, I wouldn't necessarily make these filters enabled by default, this would be something for users to opt in to (but made easy to find). Though perhaps this would be too heavy for lib.rs (reducing cache hits, causing more server load etc)?
There are the description, keywords, and categories.
I think those are more descriptive of what a crate does than the name.
Or in other words "don't judge a crate by it's name"
While the total number of crates is very huge, the number of crates focused on some narrow task one needs to implement is often manageable. From my experience, number of candidates that even remotely would be considered reasonable is usually less than ten.
Thinking this way, a reasonable approach would be to provide precise classification, maybe with automated analysis of the crate API, that would tell clearly what does the crate implement.
Hence may be more reasonable to provide clear and direct search tools for the user than attempting to rank all crates by some complex and unclear criteria.
I feel that might be a bit extreme. As much as we seem to be inundated with AI slop I don't believe all AI assisted code is therefore bad and to be cancelled.
I don't have anything in crates.io but some of my projects do have signs of AI use even if they are mostly written by me.
I was just looking into the Box3D physics engine. It's a written in C by Erin Catto. The guy behind Box2D which famously powered Angry Birds. If we want to use that from Rust we need a Rust bindings crate. Looking on crates.io I find there are already many such binding. But then I find there is a translation of Box3D to Rust: crates.io: Rust Package Registry. Which claims to be a very accurate Rust translation, down to bit for bit deterministic results matching the C original. Which says it "Ported with Claude Code" at the bottom of it's README.
I'm not about to write that off a AI slop. Especially knowing the quality of work Lars Brubaker has under his belt.
