Awesome thread, very interesting and useful, thanks! I hope the next generation of random APIs will get those things right.
-
-
Replying to @daniil_vodopian @colmmacc
Btw, say you have a chance to design a new language. What random APIs would you put into the stdlib, and what would you put into the concomitan library, and what would you left to specialized frameworks?
1 reply 0 retweets 0 likes -
Replying to @daniil_vodopian
Changing the syntax to suit, I'd have: int random(int ceiling); randombytes(bytes []); getuuid(); shuffle(stuff []); in the stdlib. I'd also have compatible insecure_random(), insecure_randombytes() versions too that are deterministic from a seed. For fuzzing, games and science.
1 reply 0 retweets 1 like -
Replying to @colmmacc @daniil_vodopian
I'd ignore distributions (like gaussian), doubles, floats, etc, but if there's a BigNum library it should have a native secure random for the types it supports. I would have a pick() for weighted selection in its own library, using a dictionary or whatever for weights.
1 reply 0 retweets 1 like -
Replying to @colmmacc
It is interesting that you think shuffle() should be in the stdlib. IMO it is a niche functionality and is better left in the satellite library.
1 reply 0 retweets 0 likes -
Replying to @daniil_vodopian
I guess I just see sort() abused as a shuffle so often, with a random comparator, and it just heats the planet with waste energy! People don't seem to think to look for a lib.
1 reply 0 retweets 0 likes -
Replying to @colmmacc
Preventing API abuse is a reason good enough :) BTW if you are wondering why I am asking,
@kotlin now goes from using Java Random to its own (because multiplatform), so they are resigning the core functionality. I quoted your tweets, hope you don't mindhttps://github.com/Kotlin/KEEP/pull/132 …1 reply 0 retweets 0 likes -
Replying to @daniil_vodopian @kotlin
Quote away, this is great work! also Java Random is terrible! I'm in the process of Open Sourcing AmazonSecureRandom, the interface/package we have internally.
1 reply 0 retweets 2 likes -
Terrible?
I didn't know things were this bad. AFAIK the plan was to reuse JDK implementation on JVM. Should we not?1 reply 0 retweets 0 likes -
Replying to @daniil_vodopian @kotlin
It's got all of those anti-patterns like DoubleStreams and setSeed(), *shudder*. I gave up auditing its use because mistakes are so common and just tell people to use our replacement instead which can't be abused as easily.
2 replies 0 retweets 0 likes
We also over-ride the SPI so that setSeed() is a no-op!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.