I mostly agree with all @pietroppeter said in this thread...but I tried to reproduce the AMD Linux `dd` benchmark justifying this
> It's only about twice as fast. [..] Frankly, the performance difference is > such a non-issue that I would nuke existing statistical PRNGs all together. and noticed it uses a default 512-byte block size ( _many_ syscalls). E.g., on Linux6 by adding `bs=$((1<<17))` to the cmds, I get `/dev/random` being **_70+X slower, not ~2X slower_** , than `/dev/zero` (but I admit you may find one within 3-6X-ish in throughput..but I suspect this ain't it). In some big domains (stats, scientific, randomized algos, ..), **_slowness also confuses_**.. even not compiling with optimization. Assuming an adversary can also cause trouble. IIRC, Rust has secure-by-default string hash confusion. This has been an ongoing problem in Nim. We have DEBUG BUILD messages many other compilers feel no need for. _Many_ Forum threads relate. Beats me if people are more likely to read docs on a fast, insecure PRNG that says, `"exactly that; See std/sysrand"` vs. read docs on one that's slow & says `"see other for fast"`. Maybe you want >=3 levels like fastR, cryptR, trueR under **_a unified API_** where the last does not rely on a math problem being "hard". A fast, insecure one has used the name "random" since 2008. Unification is **_less needlessly disruptive_** , not forcing dependency edits to avoid bad perf regression, deprecating, etc. Resulting **_doc unification_** might also help. [New Forum threads](https://forum.nim-lang.org/newthread) or even better a thread that also points to some [secure-by-default RNGs RFC](https://github.com/nim-lang/RFCs/issues) are better for side topics like this. (Or _separate ones_ for hashes, RNG API re-org, etc.; BTW, I use **_triple-star_** only to emphasize "key thoughts", not "scream". FWIW, I intend all this as constructive engagement.)
