Is there a crate ranking system for me to find the best, the most reliable, and the most promising crates in each cateogry? If there is none, I think we may need one. Thanks.
Ranking systems are subjective and can be "gamed". Further, a well ranked crate, while good from a larger community perspective, may not be the best option for the specific use case at one's hand. In case there are multiple options, I'd rather inspect a few - their docs, public interface, outstanding tickets, performance among others - and take a call.
On the other hand, there already are well regarded crates for almost all typical use cases (Serde for serialization, tokio for async etc.) which one can learn of by just "hanging-out" in the community.
Also, FM @kornel maintains https://lib.rs/ - in case crates.io feels tedious.
1 Like
Personally I think such a ranking system would be detrimental. If it's even possible to make devise one that makes any sense at all. We certainly don't need one. How is one to even define categories? Or such simplistic things as "best"?
Engineering by "likes" is not, well, engineering.
The whole thing would end up like Stack Overflow where often I find the most highly rated answer to a question is sub-optimal, out of date or even down right wrong! Meanwhile a correct solution can have no votes at all!
No doubt somebody will do it though. We will end up "programming by fashion" like the users of the ever changing Javascript frameworks in the web world.
1 Like
cargo-crev is working (among other things) towards ranking crates, and collecting list of alternatives.
You can find crates matching given keyword, sorted by number of reviews:
[I] 11-27 14:39 dpc@futex ~/l/breeze (master)> cargo crev crate search slog
2 log
1 slog-term
1 slog-async
1 syslog
0 slog
0 slog-scope
0 slog-stdlog
0 slog-json
0 slog-envlogger
0 slog-extra
and also list alternatives to a given crate:
[I] 11-27 22:37 dpc@futex ~/l/c/cargo-crev (master) [130]> cargo crev crate info term
---
package:
source: "https://crates.io"
name: term
version: 0.6.1
details:
verified: false
loc: 2262
geiger-count: 125
has-custom-build: false
unmaintained: true
recursive-details:
verified: false
loc: 280287
geiger-count: 2196
has-custom-build: true
unmaintained: true
dependencies:
- source: "https://crates.io"
name: winapi
version: 0.3.7
- source: "https://crates.io"
name: dirs
version: 2.0.2
rev-dependencies:
- source: "path+file:///home/dpc/lab/crev-dev/cargo-crev/cargo-crev"
name: cargo-crev
version: 0.13.0
alternatives:
- source: "https://crates.io"
name: yansi
- source: "https://crates.io"
name: termcolor
- source: "https://crates.io"
name: crossterm
Note: these features are still quite new, not many crates have been annotated yet, and there will be many improvements in the future.
It already exists, and IMHO works very well:
https://gitlab.com/crates.rs/crates.rs/blob/master/ranking/src/lib_ranking.rs
2 Likes
Is there perhaps some "well respected" authority who is watching and curating crates for specific uses? For example, I would love to find someone who I can trust who is maintaining a blog/recommendation web site on all crates related to network programming / web programming and the new async/.await capability to make suggestions on the best path forward. As rust continues to gain steam, each developer having to evaluate all competing crates will apply negative pressure to its adoption IMO.
1 Like
Not that I know of. That would be a lot of work, especially considering it would probably be done in free time. That's why I believe this sort of stuff can only be done collaboratively, and mostly by collecting pieces of information prepared by many, many people.
1 Like
I would rather see a curated site with pros and cons listed for crates, and the crates then organized based on functionality.
Now, to keep this list non-partial, that's another story.
2 Likes
I tried to shepherd an RFC for this; the best we could come to a consensus on was "more badges and default sort by the number of downloads in the last 90 days".
1 Like
I've had a look through some of the comments on the RFC and given that this was 3 years ago is it worth revisiting?
As a beginner to Rust I am trying to find packages that are going to help solve my problem so I can re-use and benefit from the experience of others. Also finding good, well used and maintained packages is useful from a learning perspective because the code is likely to be of a better quality.
I agree with the points that as Rust evolves and more of the community get involved this will likely sort itself out but over what timeline?
Ranking by downloads is likely to be flawed. The reason for this is that a little bit of hype on the web will encourage downloads, for example http://areweguiyet.com and azul. While this crate looks really promising the author mentioned on his Discord that he did not want any participants and would continue to work to his timeline.
I also think there should be an up vote or down vote similar to that of stack overflow which could be reset each time a new version of that crate is released and that may help encourage maintainers.
Then there are things like this https://crates.io/crates/codetrotter_aoc_2019_solutions. Should this have been published as a Crate?
I really don't think that trivializing things into 'like' counts and download counts tells us anything useful at all. It says nothing of the technical merits of the thing, it says nothing about reliability or suitability for task, or, well anything much.
Heck, if popularity, as measured by likes and downloads was the criteria by which we selected a programming language we would all be using C. Currently top of the TIOBE index.
At the end of the day we all have to do our own home work when selecting a library. Sure check the downloads, sure get a feel of how widely used it is, a quick google search will tell you that. You might also want to find out who the developers are, how actively they are working on the project, how many issues are outstanding on it, so those issues get fixed, is the project likely to be developed and maintained into the future, etc, etc.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.