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
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
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
README.md 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.
ordermap A hash table (associative array) where the iteration order does not depend on the key or the hash, only insertion and removal.
In particular I find this to be a lifesaver when testing since I can make assertions and the diff (with
pretty_assertions) is easy to read if I just called
.sort() on both of the inputs first.
Compared to HashMap’s which are completely unreadable since the keys can be in literally any order.
I haven’t seen this mentioned anywhere so far: rust-semverver.
It compares the local version of the crate you are developing with the latest version on crates.io and will print out the major, minor and breaking changes in your local version. While it’s not completely bug-free yet, it was moved to the nursery today.
Introducing, skullrump. A way to quickly write UNIX-like binary head and tail routines. I use this to quickly read and write tons of data efficiently in a file-based database system.
With this there’s no need to use text files anymore, because doing a binary -> text conversion is very simple with
skullrump, allowing users to make use of other UNIX tools such as awk, sed, and friends.
Here is an example invocation of a program that utilizes
fswatch myfile.fmt | xargs cog --tail 1 | awk -f avg.awk | fig
This will run my program
cog with the
tail argument, outputting the last entry every time there is a change to the file being watched by
fswatch, passing the output to an averaging
awk program, and then printing the result in huge letters with
I’d like to propose built - a crate for putting build time information into the crate.
I’d like to nominate my own project DataFusion (https://www.datafusion.rs/) and (https://crates.io/crates/datafusion) which is query planner / execution framework that can be used as a crate dependency and is also a standalone “Big Data” product for data processing.
I bump v0.1 of my undo redo library rundo. Procedural Macros is really useful, let me can write a easy use undo redo library.
It’s a handy little command runner for saving and running project-specific commands.
Crate of the week offer: this might be a duplicate, but, cargo-tree
I think afl.rs wasn’t mentioned in here so far: https://github.com/rust-fuzz/afl.rs
It is a fuzzing library that found a lot of bugs in existing crates over the last 2 years.
You can check https://github.com/rust-fuzz/trophy-case for what afl.rs (and libfuzzer) caught.
Just tried out trace crate - it’s a big step up from peppering code with println (my command line gdb skills aren’t great yet, so println is my go to debugging tool).
They need to release a new version to cargo as v0.1.3 isn’t up to date with the compiler. This works fine though:
git = “https://github.com/gsingh93/trace.git”
Anything that improves debuggability is a big plus - many thanks Gulshan Singh for coding it up!
I’m the author of humansize, a small, configurable crate with sane defaults for displaying byte sizes in a human-friendly way; It’s a dependency of this week’s
fselect so I thought I’d submit it here.