Crate of the Week

I've read that in the latest Rust Weekly there was no crate to nominate.

I am submitting my own crate here, not sure this is allowed:

It's supposed to be a pure-Rust replacement for Apache PDFBox, etc.

  • ~ 3K LOC
  • Compiles on stable Rust
  • Good documentation and examples
  • All issues closed except for feature requests
  • No issues with clippy

So this is why I'd nominate it, instead of nominating no crate at all. Not sure if this is allowed, though.


I will nominate Wither. An ODM for MongoDB written in Rust.

A few awesome things about this crate:

  • extremely simple to get started with.
  • provides a model first approach to interfacing with your MongoDB data.
  • you get to deal with your structs as opposed to BSON documents.
  • well tested.
  • has a nice schema migrations system.
1 Like

I'd like to nominate Zbox. A zero-details, privacy-focused embeddable file system.

Unlike other system-level file systems, Zbox is a file system that runs inside your application. It only provides access to one process at a time.

Some of its features:

  • Metadata encryption
  • Advanced crypto
  • Content-based data chunk deduplication and file-based deduplication
  • Data compression
  • File contents versioning
  • Copy-on-write (COW :cow:) semantics
  • ACID transactional operations
  • Snapshot
  • Support multiple storages, including memory and OS file system
1 Like

smallvec is so great I think it should be in the std. It is useful for any time you need to store a small amount of items and an allocation is overkill. It is also great as a part of larger data structures because of data locality.


state_machine_future - Easily create type-safe Futures from state machines — without the boilerplate.


I nominate cargo-audit which checks all dependencies for known vulnerabilities in the RustSec Advisory Database.


I'd like to nominate sec - simple and useful


interesting crate

Rusty Object Notation


I think the "disclaimer" there is important:

While sec usually does a good job from preventing accidentally leaks through logging mistakes, it currently does not protect the actual memory (while not impossible, this requires a lot of extra effort due to heap allocations).

If protecting cryptographic secrets in-memory from stackdumps and similar is a concern, have a look at the secrets crate or similar crates.

Besides the secrets crate, there's also secstr that does something similar.

@imp do you know where the repo for sec is? I'm wanting to open a couple issues/PRs but the owner never filled in the repository or homepage fields in his Cargo.toml. I wasn't able to find it on GitHub either.


@Michael-F-Bryan I believe this is the one

1 Like

I'd like to nominate crossbeam-channel. It's young and in active development, but deserves more hype.


Whoa!! Super nice! I'll integrate this into my project to replace mpsc and see how it does.

This looks awesome! I will definitely check it out for usage in my project(s)

YEW - a framework for making Elm/React/Angular-like client web-apps with Rust


An awesome Cassowary UI layout implementation. Super useful for the GUI frameworks.


I propose artifact for next week!

It is the open source design documentation tool for everybody.


I'd very much like to nominate It's not on, but in my book that doesn't matter. What really makes this outstanding is @autozimu's support, fast response time and time-to-bugfix, his willingness to dive into problems from the interaction with other plugins and the language servers, and to raise issues and interact with the maintainers of those. Three thumbs up!


cargo-bloat - Find out what takes most of the space in your executable.


If I may, sec author here:

I think the “disclaimer” there is important:


Besides the secrets crate, there’s also secstr that does something similar.

I would like to point out that both secstr and secrets solve slightly different issues. The data protected by sec is usually sent across the network and passed around among different applications (e.g. a token authorizing a client), e.g. it could reasonably be used as a key for a HashMap:

Moving non-heap allocated data from the stack into a HashMap will cause it to be copied at least once, with no way (to my knowledge) of reliably ensuring that the resulting copy will not be overwritten. One solution for this problem is passing in references and storing a single copy of the confidential information on the heap, where scrubbing is much easier.

This is what secstr seems to do (by wrapping a Vec). The secrets crate also does a much better job at protecting data than sec in a similar vein. secstr requires linking against an external C library (sodium).

Both of these are different use cases though: sec is not written to protect your GPG private key or Bitcoin wallet, which will never leave your machine. Instead, it protects things like your login token which will be serialized and sent as a HTTP-header (with probably one or two extra copies being made somewhere in the stack already), but should not be exposed when a dev turns on logging to see why there are currently so many 500s. It does so with zero overhead (outside of printing), so requiring additional heap allocations is not acceptable. Finally, sec works with any type and requires almost no effort to add.

The disclaimer is in place to ensure no one accidentally uses sec when they really need to use secrets instead. Maybe I should add this Post to the as well? Feel free to send me additional feedback (possibly as a direct message to not derail this thread), I am very happy to discuss and learn about other opinions on this.