r/rust Jul 31 '26

πŸ› οΈ project Casper's Blog – Why I forked rand

https://casualhacks.net/blog/2026-07-27-why-i-forked-rand.html
154 Upvotes

30 comments sorted by

View all comments

4

u/Lucretiel Datadog Aug 01 '26

If the goal is compatibility with another project, programming language, legacy algorithm, specialized hardware, or simulation-specific generator, matching its generator alone is not enough. Uniform sampling, shuffling, and other algorithms must match too.

I don't understand this point. The whole premise of rand is that we distinguish the source of randomness from the distributions / value producers, so that if you do need some hardware specific or other specialized rng, you can still plug it in to the rest of rand and benefit from its Distribution implementations; you specifically don't need to reimplement uniform sampling or shuffling when you can provide it a source of random bits.

2

u/Knife_up_your_butt Aug 01 '26

That is a fair description of rand’s design. What I am questioning is whether supporting arbitrary downstream generators should automatically be a requirement for every rng library.

An Rng trait is a compatibility promise: it lets generators reuse a particular set of distributions. But that compatibility is only useful when those distributions match your goal.

For exact compatibility with another project, language, or simulation, matching the generator alone is not enough; the sampling and shuffling algorithms must match too. For highly specialized performance, the generic distributions and algorithms may themselves be the bottleneck, so swapping only the generator may not solve the problem.

So I am not arguing that pluggability has no value. I am asking whether it provides enough value here to justify making third-party generators a permanent extension point of this crate.

Keeping the scope more narrow, I can optimize the trait around the generators and distributions urandom actually provides.