They are so close that people can and often do build rand() as "internal state s = hash(s) return s" (or similar). then other people, wanting that deterministic hash() behavior thus accidentally exposed, build entire worlds(literally) out of rand().

Another problem with this is that the rand() internals are opaque and unknown and can change without violating the spec. hash(), because it is supposed to be deterministic, usually has an exposed stable algorithm.

A specific example. At one job I found they were storing long term customer order archives encrypted where the key was a hash of the date, this in itself is a little suspicious but the archives were offline and physically locked up on site, so not too bad. The real wtf was that the encryption was done on a win98 machine with a perl script that was basically "seed(date); key = rand(); encrypt(data, key)". expecting to regenerate the key if they ever wanted to look at the data. When I saw that I went "I don't know much about perl, but that does not feel stable" and did a few checks. Sure enough the behavior of rand() could change depending on the operating system or even version. making the keys highly dependent on that exact win98 machine with that exact version of perl, I think they ended up using that machine to generate and store all used keys in a database so other machines could decrypt the archives.

Every hiring manager worth their salt has caught at least one completely incompetent applicant with a CV full of certifications.

-object rng-random,id=objrng0,filename=/dev/null

or maybe just a file that contains 4 :O

You're confusing just assuming by default its enough for purpose rather than not caring at all.

Rust is a general purpose programming language, which is great if your problem might be something never imagined before, but this literally isn't our first rodeo, we have wrangled lots of file formats before, we should use a language purpose-built to do that safely.

You're right, PDFs are horrible scary monsters who you should never trust.