Pseudorandomness vs randomness is a funny distinction to me because randomness effectively boils down to either an inadequate dataset or inadequate computational resources for analyzing an adequate dataset, with adequateness being an arbitrary measure. In other words, any apparently random sequence approaches pseudorandomness as more computational resources are applied to its analysis.

Does this not imply that its usefulness degrades depending on how much random data you need / the frequency at which you need it? For example if you ask for 8 bits of randomness within the same time-slice (either as a chunk of 8 bits or 8 separate invocations) - then you're only ever going to get 00000000 or 11111111 as your "pseudorandom" values (and this feels like it would be an easily re-producible outcome)

There is a limit on the frequency of requests, which makes sure the bit will be flipped several times before every request. Current enforced minimum is 20 milliseconds (roughly 50 bits/second). Lower values may be safe as well, but have not been tested yet.

> BitGenGo is actually a small program which spawns off two goroutines(threads) and they take turns setting a shared variable with a value(zero/one). Every time the user requests a bit, the current value of the shared variable is returned.

dakarand!

I had to google "dakarand"; here are links to the original post announcing the DakaRand code and the GitHub repository:

- https://dankaminsky.com/2012/08/15/dakarand/ - https://github.com/stribika/dakarand

interesting project!

will be great if the author can add some Go benchmark results comparing this library to the one in Go's stdlib, will be useful for potential users to know what kind of CPU performance they can expect.

This is a good idea. It'll be added in the next commit.