Hacker News Reader

Comment by gouggoug | Hacker News Reader

Would you be able to expand on why using a seed of 0 is an issue?

If you randomly generate numbers using `math/rand`, then every invocation of your program is going to see the same sequence of "random" numbers. If you happen to persist those random numbers and expect a uniform distribution, you're going to be sadly surprised in the future.

It's the kind of "bug" that doesn't manifest until your data is thoroughly boned.

So, if I use `math/rand` the RNG will always output the same sequence of random numbers?

How do I make sure I'm passing a random seed to my RNG?

(I must be missing something here)

> So, if I use `math/rand` the RNG will always output the same sequence of random numbers?

math/rand provides global functions using a global RNG, as well as the ability to instantiate your own RNG and call functions (methods) on that RNG.

Previously, the global functions all used a seed of 1, which made them generate identical sequences. Now, they use random seed, which makes them less-easily predictable (though still predictable).

There is no change to the self-instantiated RNGs.

> How do I make sure I'm passing a random seed to my RNG?

With the change, using the global functions in Go 1.20+ is the same as instantiating your own RNG with a random seed.

The example in previous versions of the Go math/rand package suggested using time.Now().UnixNano() to seed the RNG source since that's essentially a random int64.

It's a reasonable choice, and will be unique for most program runs, but it's not exactly random

Philosophically, there is no such thing as a random number

There are ways to get truly random numbers into a computer. Certain phenomena are theorized to be fundamentally random, and can be used as inputs to hardware.

https://en.m.wikipedia.org/wiki/Hardware_random_number_gener...

The sound of conviction in your first sentence does not match the "theorized to be" in the second sentence. I recommend that you don't bring a "for all intents and purposes" to a "philosophically" fight. ;)

However, the universe is based on randomness at its quantum core.

Or perhaps the universe is a simulation whose prng was seeded with 1 just like golang does

Maybe we're in the first batch of simulations, and the tester came along and asks why they're all identical. The cosmic coder then realises that they forgot to call the function to seed the prng.

Is it though? I’m merely a layperson here so I might be grossly misunderstanding, but I didn’t know determinism had been ruled out by quantum physics. I was under the impression that quantum phenomena was best described using probability. That means there might be an element of true randomness going on, but also that these systems are so chaotic that an observation is going to have some noise, regardless of any randomness at the core. The latter says nothing about how random things are, merely that they appear with some probability, they could be completely deterministic for all we know.

To get cryptographically grade randomness you can use one of these C functions:

*BSD, newer macOS, and GNU libc: int getentropy(void *buffer, size_t length);

Linux 3.19+: ssize_t getrandom(void *buf, size_t buflen, unsigned int flags);

iOS and macOS 10.7+: int SecRandomCopyBytes(SecRandomRef, size_t, uint8_t *);

Fuchsia: void zx_cprng_draw(void* buffer, size_t buffer_size);

Any *nix: Read from "/dev/random" (or "/dev/urandom" under the assumption that your system has already enough entropy).

Windows: There are different functions/libraries depending on the Windows version and some of them are a complicated multi-step mess.

Some time ago I wrote a C library that abstracts that away just for fun: https://github.com/panzi/portable_get_random*

What a fascinating insight to the naming conventions of the different OS. Mac the long descriptive. BSD short and accurate. Linux short details are for specs. Fuchisa the functional HW reference ? What is that

Fuchsia is an open-source capability-based operating system developed by Google. —Wikipedia

The generator returns the same sequence every time. For instance Kubernetes CSI drivers have a supposedly unique csiProvisionerIdentity but it uses math/rand without seeding so they're all using the integer number 8081.

Having the seed value set to the same value at run time will cause the pseudorandom number generator to produce the same sequence of values. In essence just creating a new random number generator in go w/o setting the seed will not actually generate random values.

> In essence just creating a new random number generator in go w/o setting the seed will not actually generate random values.

This change only affects the global RNG. Creating a new RNG has always required setting a seed

Which is also significant because the global RNG is safe for concurrent use. Instantiated RNGs are not.

> Which is also significant because the global RNG is safe for concurrent use. Instantiated RNGs are not.

Amusingly, I submitted a patch for this some years ago, and it was rejected on the grounds that callers might depend on the specific sequence of numbers outputted by the global RNG using the default seed, which could break the compatibility promise.

Now that that's been deemed a non-issue, I might resubmit.

To be clear, if setting a global seed was required it would not be so bad - but silently seeding with 1 is an edge that's pretty easy to trip on.

It appears like it's an API design that intersects the world of high level application development and computer science.

Given randomness requires a seed and UNIX's ISO standard defines the default seed as 0, it's rational from a comp sci perspective to expect to supply a seed to produce a random number.

However, due to how ergonomic and safe high level languages are today, you don't need to be a computer scientist to make a highly available, beautiful and robust application. As such, the inhabitants of the application development world are considerably less concerned with such details and want, when they call a thing, it gives an intuitive result.

It's important that tool makers consider their users when creating APIs. Supplying a seed to a function called "getRandomNumber" might be obvious to a C programmer, but not obvious to a JavaScript programmer looking to use Go to improve the performance of their back end service.

Reply on news.ycombinator.com