Fat Rand: How many lines do you need to generate a random number?

> 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.

See also the Azure CLI. There's a github issue, still open, from 2018 complaining about their 350 MB monstrosity bloating up a docker container. By now the thing weighs more than 1.5 GB. Fucking MS.

https://github.com/Azure/azure-cli/issues/7387

I agree with his sentiments in the article. I love Rust as a PL, but the situation with certain crates and dependency trees is a bit of a nightmare IMO. It's certainly a trade off.

I recently ripped out the rand crate and replaced it with some much simpler code ported from a C++ codebase. Still does what I need it to do but way fewer LOC and way less complexity. Is it as flexible as what rand and related crates offer? Maybe not, but that flexibility comes at a cost.

I really like Armin "food for thought" articles and I'm also concerned with the dependencies attitude in Rust. I like the language a lot, but I cringe when I clone some project and see the number of dependencies... It's really a balance: when you add a dependency you get a lot of code for "free" but nothing is free: now you've potentially new bug/security failure/things to update. It's a balance.

On the article, two random thoughts:

- I like that the Rust standard lib is "tiny" and a lot of stuff is delegated to third-parties crates. I wish crates support namespaces (for instance std) so it's easier to see what dependencies are blesser. For the moment, you can obtain a good name, like http, and squat it forever (http being just an example, don't know if there is an actual crate)

- when you vendor a Rust project, does it vendor also the flag dependencies? For instance, Rand is dependent on Serde because of an optional flag for serializing a random generator. Serde loc should be ignored in that case if we count the code lines.

I think that the rand crate is much bigger than it needs to be and is conflating unrelated concepts *. This is a sore spot for the stdlib - it should standardize 1 PRNG and a CSPRNG so that they’re available on all platforms as a default and the types that everyone can use so that you can properly plug in whatever PRNG / CSPRNG that you want. It should also standardize what interfaces random distributions should conform to and implement really common ones like Norm & Uniform. Those two changes alone would remove the need for the vast majority of dependencies, especially if a crate wants to delegate selection of the RNG to their users.

That being said, I simultaneously think the concerns are slightly overblown on the safety part. Having stable pillar crates that everyone builds around is a good thing not a bad thing. The build issues for things like that should be solved at the language/tooling level (e.g. pulling in a crate for 1 function should be trivially cheap) while relying on the network effects of auditing the components (i.e. it’s OK to rely on a crate with a stronger chain of trust than you have yourself).

* To be fair, they call out alternatives that you might find more appealing, but the type and module system being what it is (+ the name rand being so concise and appealing when you come at it with a first glance), it becomes the de facto standard.*

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

You can use getrandom directly.

getrandom v0.3.1 ├── cfg-if v1.0.0 └── libc v0.2.169

I love Armin’s blog. I don’t always agree with everything he says, but always come away with a new appreciation for his POV.

Does —release do tree shaking to remove unused code in the final executable?

One reason to care about this is that random number generators are a very lucrative target to attack for security services. See for example ECDual https://eprint.iacr.org/2015/767.pdf or Linus Torvalds' answer about NSA approaching him about a backdoor: https://www.youtube.com/watch?v=wwRYyWn7BEo

Random number generation?

There still is:

     R. R. Coveyou, R. D. MacPherson,
     "Fourier Analysis of Uniform Random
     Number Generators", Journal of the
     ACM, Volume 14, Issue 1, Jan. 1967,
     Pages 100-119.

     i -- a positive integer
     ip1 -- a positive integer
     Set i = 1
     Do Forever
       Set ip1 = i * 5^15 + 1 mod 2^47
       Return(ip1)
       Set i = ip1
     End

Here's one I use for cryptographic purposes:

  let invocations = 0;

  export function rand3000() {
    invocations += 1;

    const timestamp = new Date().getTime() + invocations * 1000;
    const masked = (timestamp ^ (timestamp >> 8)) & 0xFF;
    const result = masked / 255;

    return result;
  }

1/ What?

If this kind of insane dependencies for such a simple thing is common practice in the Rust ecosystem then the language is in a lot worse place than I imagined it to be.

    function rand() {
      return 4;
    }