I think the Kotlin developers know what the importance of being able to set the seed of an RNG is… you can always build your own RNG instances with a specified seed value (e.g.
val random = Random(42)
), and if “controlling randomness” is important in your application, you should make calls to RNG instances you control instead of relying on the
1 year ago
I'm aware of that. However, whenever we use some piece of code that includes library calls that use shuffled etc internally, we are loosing determinism.
That's why many languages (C++, c, rust, go, r, python, etc.) allow to set the seed systemwide I guess. It's imho more a flaw in java, that kotlin simply adopted.
1 year ago
could be modified to take a
as an argument, with a default of
. However, the library would then have to declare either that it commits to using the same sequence of random-value calls for all future updates, or that the same seed may lead to different results after an update to the stdlib.
We allow controlling randomness of the stdlib functions by providing overloads that take an arbitrary Random instances including deterministic ones. We expect other libraries to follow this convention.
We're against providing any guaranties of determinism for
, for example being able to set its seed with some global method.
In fact, having such globally mutable seed in a concurrent environment doesn't make further random calls anymore predictable.