Fat Rand: How Many Lines Do You Need To Generate A Random Number?

Platform Dependencies

First there is the question of getting access to the system RNG. On Linux and Mac it uses libc, for Windows it uses the pretty heavy Microsoft crates (windows-targets). The irony is that the Rust standard library already implements a way to get a good seed from the system, but it does not expose it. Well, not really at least. There is a crate called fastrand which does not have any dependencies which seeds itself by funneling out seeds from the stdlib via the hasher system. That looks a bit like this:

use std::collections::hash_map::RandomState;
use std::hash::{BuildHasher, Hasher};

fn random_seed() -> u64 {
    RandomState::new().build_hasher().finish()
}

Now obviously that's a hack, but it will work because the hashmap's hasher is randomly seeded from good sources. There is a single-dependency crate too which can read from the system's entropy source and that's getrandom. So there at least could be a world where rand only depends on that.

Dependency Chain

If you want to audit the entire dependency chain, you end up with maintainers that form eight distinct groups:

1. libc: rust core + various externals
2. cfg-if: rust core + Alex Crichton
3. windows-*: Microsoft
4. rand_* and getrandom: rust nursery + rust-random
5. ppv-lite86: Kaz Wesley
6. zerocopy and zerocopy-derive: Google (via two ICs there, Google does not publish)
7. byteorder: Andrew Gallant
8. syn, quote, proc-macro2, unicode-ident: David Tolnay

If I also cared about WASM targets, I'd have to consider even more dependencies.

Code Size

So let's vendor it. How much code is there? After removing all tests, we end up with 29 individual crates vendored taking up 62MB disk space. Tokei reports 209,150 lines of code.

Now this is a bit misleading, because like many times most of this is within windows-*. But how much of windows-* does getrandom need? A single function:

extern "system" fn ProcessPrng(pbdata: *mut u8, cbdata: usize) -> i32

For that single function (and the information which DLL it needs link into), we are compiling and downloading megabytes of windows-targets. Longer term this might not be necessary, but today it is.

On Unix, it's harder to avoid libc because it tries multiple APIs. These are mostly single-function APIs, but some non-portable constants make libc difficult to avoid.

Beyond the platform dependencies, what else is there?

• ppv-lite86 (the rand's picked default randon number generator) alone comes to 3,587 lines of code including 168 unsafe blocks. If the goal of using zerocopy was to avoid unsafe, there is still a ton of unsafe remaining.
• The combination of proc-macro2, quote, syn, and unicode-ident comes to 49,114 lines of code.
• byteorder clocks in at 3,000 lines of code.
• The pair of zerocopy and zerocopy-derive together? 14,004 lines of code.

All of these are great crates, but do I need all of this just to generate a random number?

Compilation Times

Then there are compile times. How long does it take to compile? 4.3 seconds on my high-end M1 Max. A lot of dependencies block each other, particularly the part that waits for the derives to finish.

• rand depends on rand_chacha,
• which depends on ppv-lite86,
• which depends on zerocopy (with the derive feature),
• which depends on zerocopy-derive
• which pulls compiler plugins crates.

Only after all the code generation finished, the rest will make meaningful progress. In total a release build produces 36MB of compiler artifacts. 12 months ago, it took just under 2 seconds.

Final Thoughts

The Rust developer community on Reddit doesn't seem very concerned. The main sentiment is that rand now uses less unsafe so that's benefit enough. While the total amount of unsafe probably did not go down, that moved unsafe is is now in a common crate written by people that know how to use unsafe (zerocopy). There is also the sentiment that all of this doesn't matter anyways, because we will will all soon depend on zerocopy everywhere anyways, as more and more dependencies are switching over to it.

Maybe this points to Rust not having a large enough standard library. Perhaps features like terminal size detection and random number generation should be included. That at least is what people pointed out on Twitter.

We already treat crates like regex, rand, and serde as if they were part of the standard library. The difference is that I can trust the standard library as a whole—it comes from a single set of authors, making auditing easier. If these external, but almost standard crates were more cautious about dependencies and make it more of a goal to be auditable, we would all benefit.

Or maybe this is just how Rust works now. That would make me quite sad.

Update: it looks like there is some appetite in rand to improve on this.

• zerocopy might be removed in the core library: issue #1574 and PR #1575.
• a stripped down version of chacha20 (which does not require zerocopy or most of the rust-crypto ecosystem) might replace ppv-lite86: PR #934.
• if you use Rust 1.71 or later, windows-target becomes mostly a no-op if you compile with --cfg=windows_raw_dylib.

Edit: This post originally incorrectly said that getrandom depends on windows-sys. That is incorrect, it only depends on windows-targets.