A colored favicon would probably be ideal

I think adding fyrox to the list of game engine would complete it. Fyrox is a OOP Game engine with an UI for rust and is definitively worth mentioning.

arboard seems to be most downloaded per month fork of rust-clipboard (230k vs 40k/13k).
Additionally it supports images (and HTML).

a great ORM lib is rbatis , this is repo : https://github.com/rbatis/rbatis

(Full disclosure, I am a maintainer for indicatif.)

I think indicatif is probably the de facto standard progress bar library for CLIs, might make sense to mention in the CLI section?

faer is

a pure Rust implementation of low level linear algebra algorithms that leverages SIMD instructions, modern cache friendly algorithms and thread parallelism to achieve high performance.
-- Rust Scientific Computing 2023

• Journal of Open Source Software submission
• benchmarks against ndarray, nalgebra, eigen, etc are in the README.md
• interoperable with polars
• interoperable with ndarray and nalgebra

Alongside arrayvec and tinyvec, heapless has stack-allocated arrays, but also includes:

• Arc – like std::sync::Arc but backed by a lock-free memory pool rather than #[global_allocator]
• Box – like std::boxed::Box but backed by a lock-free memory pool rather than #[global_allocator]
• BinaryHeap – priority queue
• IndexMap – hash table
• IndexSet – hash set
• LinearMap
• Object – objects managed by an object pool
• String
• Vec
• mpmc::Q* – multiple producer multiple consumer lock-free queue
• spsc::Queue – single producer single consumer lock-free queue

I recently discovered inquire, which is just what I needed at the time. It was one of those "I wish someone (like blessed.rs) had told me about this sooner!"

That being said, I haven't put much more thought into whether it's a good fit for the site beyond that it seems high quality and useful for a broad range of use cases. I'm guessing there's more that goes into the descision? Popularity, maintenance status...

I'd say CLIs > Terminal Rendering would be an appropriate place.

Thanks for considering it.

There are several good libs for building gui and tui apps.

https://crates.io/crates/unicode-segmentation

I think this seems to be the go-to way for doing things like iterating over grapheme clusters.

Maybe some other crates from https://github.com/unicode-rs would make sense as well?

You've listed ring in the TLS/SSL section, but it actually provides many of the same crypto primitives (AEADs, hashes, signatures) as the RustCrypto crates, so maybe that should be more clearly explained?

I actually think webpki and ring probably shouldn't be mentioned in the TLS section, since they're low-level building blocks that rustls uses but that aren't very friendly as libraries.

Watchexec (the library) is extremely focused on, like, making watch tools. It's only used by a few things, because it has that very particular focus. Notify is the general purpose filesystem watching library. That's the part that's used by like, RA and mdBook and alacritty and all that.

• RustCrypto or Ring for primitives?
• Rustls or native-tls for TLS?

colored-rs/colored (https://lib.rs/crates/colored) seems like it would a better fit to recommend for colouring text on a terminal than termcolor. It has 3.5x the GitHub stars of termcolor as of this issue. I think that both should be recommended or that colored should replace termcolor. The linked page for termcolor on lib.rs has also been removed.

I initially came across colored myself from this stackoverflow answer that recommends it.

Polars is a dataframe library written in Rust.
It is similar to pandas library in Python and is highly performant as per benchmarks.

It seems quite surprising to me that bpaf comes before clap in the current version, when the former has some 12k recent downloads compared to clap's 15M. I wouldn't disagree that clap might be ripe for disruption, but in terms of the ecosystem it seems that clap is still the favorite by far.

Stable release is sync only. Pre-release async branch is currently AGPL.

Neither of this is true:

• There is no pre-release branch for async support in diesel. It's a different crate, so it should likely be listed as a separate entry
• That crate is not licensed as AGPL code anymore

Is there any dns crate(both server/client) to be added?

One important section I noticed missing is database related crates.

Just to kick off the list, here are some popular database libraries:

• SQLx: Async SQL library with support for PostgreSQL, MySQL, SQLite, and MSSQL
• SeaQuery: SQL query builder
• SeaORM: Async ORM (built on top of SQLx and SeaQuery)
• Diesel: Sync ORM

https://crates.io/crates/error-stack

Some explanatory comment on reddit:
https://www.reddit.com/r/rust/comments/vpg49v/comment/ieppvjv/?context=3

I think the mention of surf should probably come with a caveat, at least:

http-rs/surf#352

For one thing, the latest release of surf (and current Git) still depend on a rustls version from over 2 years ago (2 semver-incompatible versions ago).

I could guess that rs is a tld, but it would be nice to see that this repo is actually hosted. I just found it through my github activity :)

I think cargo-mutants (https://github.com/sourcefrog/cargo-mutants) is pretty helpful for Rust testing. Would you like to bless it?

This is a great list. I just wonder: is there something similar for Go? My problem is the same: I have no idea which package to pick. Thanks in advance.

Hey, I found out once_cell has been merged into std and stabilized, ref rust-lang/rust#105587.

The description of once_cell : Newer crate with more ergonomic API. On track to be incorporated into the standard library. Should be preferred for all new projects. could be updated.

HTTP probably deserves it's own description.

One fairly common usecase that doesn't seem to be covered by crates on blessed.rs is encoding text and binary data.
In particular I think there are two main cases:

• Encoding strings with a non-UTF8 encoding
  • UTF8 encoding is well supported by the standard library, but for other encodings you need an external library. The main choice for this seems to be encoding_rs.
• Encoding binary data to string. In particular the two common cases here are hex and base64.
  • For hex there is the crate hex. This crate hasn't had a release in 2 years and there are a number of unmerged pull requests. I don't know if this is a cause for concern or not.
  • For base64 there is base64.
  • Another popular one seems to be data-encoding, which supports hex, base64 and a few other encodings.

It would be nice if at least some more stable and well maintained encoding crates could be added to blessed.rs, especially since encoding is an area where both performance and correctness are important, so you would want to prefer crates that have been vetted by the community.

Thank you for an effort to create this list.

However, I have a few points to address:

1. Page don't need to contain rust source. Whole page can be simplified to page generated from AsciiDoc sources with a custom CSS.
2. Page information contains many claims without any source links, co these claims can't be trusted. If information had been taken from an issue, issue link must be provided, if an article, lemmy, mastodon or another source, the same.
   1.page information contains no version information for projects, thus it's hard to say if claim is true or false at time of reading.
3. At the time of writing lib.rs and crates.io contain way more libs and tools on each topic, some of them could be added manually to the list.
4. I hope this page is populated not only by issues but also checked manually from time to time. It would be misleading if not (see point about claim sources).

I noticed the druid repo now contains a discontinuation notice, and it points to https://github.com/linebender/xilem as the successor.

The Math / Scientific section has a typo in the description: "Numberical" should be "Numerical".

I don't know exactly what the inclusion criteria are for blessed.rs, but nix has almost as many downloads as winapi :) More subjectively, I think folks who are new to the Rust ecosystem and who benefit the most from blessed.rs, also have the most to gain from the safety provided by nix.

cargo-zigbuild is a really handy tool for easy cross compilation using Zig as a linker. It's already being used by cargo-lambda. As an alternative to cross, it stands out because it doesn't require any containers. In my own experience, cargo-zigbuild was much faster and easier to use than cross.

Arenas can be categorized into three kinds:

• bump arenas: No reuse of the backing storage is supported
• non-generational arenas: Reuse of the backing storage is supported, but indices can be reused, potentially resulting in ABA problems
• generational arenas: Reuse of the backing storage is supported and indices are never reused

My suggestions are:

• bumpalo for a Drop-less heterogenous bump arena
• typed-arena for a homogenous bump arena
• slab for a homogenous non-generational arena
• slotmap for a homogenous generational arena

All four are well-maintained and used.

Not sure if it's outside the scope of this website, but there are some useful external tools like

• cargo-nextest - [website]
• cross

Would you be open to a PR adding either a major version indicator or an "unstable" indicator to the packages?

Something like this, for example:

It's a useful thing to know when comparing libraries "at a glance".

I think it would be useful to add another category to the websocket section that lists the web frameworks that support websockets. I know that you mention that frameworks often support them above the list, but it is easy to miss. I think it would make it more clear to instead list them under a new category called "As part of a web framework" or similar.

The guide currently says that "development has stalled. Avoid for new projects".

Rocket has had a new release tagged in July this year (0.4.11), a new release candidate for the next version bump tagged in May (0.5), and has an active development channel that includes the primary developer on Matrix.

The description here doesn't seem to accurately reflect Rocket's status.

I think byteorder was common and indispensable prior to the introduction of to_<endian>_bytes and from_<endian>_bytes in Rust 1.32. But now that those are standard, I think it's less common to have a need for that crate in new code.

I was noticing missing table borders in Firefox (bugzilla bug) and then found out that the tables are actually malformed: The rowspans are incorrect.

Example:

The two "rows" are actually just two <p> elements in the same row, so no rowspan is needed.

https://crates.io/crates/diesel-oci

I think that adding Tomaka's Rouille would be warranted: https://crates.io/crates/rouille

Why? Because it's mature and its stack and philosophy is significantly different from many of the other frameworks. It doesn't use Hyper or Tokio, but mini-http as its HTTP implementation. It eschews async, and provides a simple, linear microframework-style API. In this sense, it is the "go-to" experience if you want to quickly set up a simple non-async web service.

Rustqlite isn't a crate - I think this should be rusqlite

In particular what are those rough edges and which parts of the API are confusing?

Comments I encounter on the Internet are mostly in favor of it as having small and flexible API and with derive macro until you start doing strange things the difference with clap is mostly with what you derive and how you run it. And once you do start doing strange things - everything comes from a combination of a few rules similarly to how you would chain iterators...

https://news.ycombinator.com/item?id=35734051

Oddly on the cli parsing thing, I did end up finding a library I like - bpaf. It's kind of abstract but seems more conceptually principled than the near-universal clap. The kind of abstraction where once you have grasped a small set of orthogonal concepts, you can just combine them at will, seems OK to me. As contrasted with the type which has dozens of small rules, and special cases that rely heavily on (human) memory and/or constant doc lookups.

Hi.

Is there any chance to add parser library. Such as nom and pest?

Thanks!

It was recently mentioned here that we should consider adding ratatui to blessed.rs. I hadn't heard of blessed.rs before so I am unfamiliar with the process for adding a project to it.

The ratatui fork was recently created as the original maintainer of the tui crate was no longer responding. The crate is being actively maintained and we are about to release the first version of the crate since the fork.

It is currently possible to link directly to a section of blessed.rs using a link like https://blessed.rs/crates#section-graphics-subsection-gui, which works however:

• The links are long an unwieldy
• The links are tied to the section name which is liable to change

We should add "short links" like https://blessed.rs/crates#gui which are snappy and can also be preserved if/when the crates list is reorganised. We could also add crate specific links like https://blessed.rs/crates#axum or similar.

Zerocopy is an alternative to bytemuck that has similar popularity and I believe is worth adding.

While bytemuck has ~3x more all-time downloads, zerocopy, by both crates.io and lib.rs metrics, is currently getting more monthly downloads. After trying both crates myself, I can't necessarily recommend one over the other; they both achieved the exact same thing. I personally landed with zerocopy but that was mostly down to it having more recent downloads, being under Google, and having a roadmap for future improvements.

Since lexopt and pico-args are mentioned in the argument parser section, I would like to propose getargs, which I significantly revamped a while ago. (it also works quite well with argv)

It is still a minimal argument parser, as opposed to the huge framework that is clap, but it is fairly competitive in benchmarks and also somewhat pedantic about correctness. It also has a decent API as far as I can tell, though it is still iterator-based.

It was not accepted into argparse-benchmarks-rs due to the low number of downloads that it has. But the purpose of this website is to raise awareness, yes? :D

If you'd like, I'd be happy to help review changes here? You mentioned on HN:

I want to put together more guidance on how to contribute, and gradually transition this into more of a community maintained model over time, but I haven't had a chance to do this yet.

I could just start watching the repo -- maybe you could set up branch protection so that PRs are required, and I'd have a chance to give feedback.