Comment by dgacmu
1 year ago
The Go hash table approach is similar to this: it's randomizedish but not strongly random enough to depend on it being actually random...
https://dev.to/wallyqs/gos-map-iteration-order-is-not-that-r...
(Which I find a hilarious second order example of Hyrum's law - if you add true randomness to prevent people from depending on the iteration order, they might use it as a way to randomly access items in the map!)
This was mostly annoying because Go doesn't really provide any ordered map in std (and for while didn't give you generics, which are needed to make a general-purpose one that's perfomant). I feel like the best response to people relying on the order of iteration is to recognize that as a valid need an provide it via a separate type.
There's also the Python approach, where dict() iteration became insertion-ordered as of Python 3.7+ (it was also ordered in 3.6, but only as an implementation detail, not as a language feature).
At the time I thought this was a questionable decision that'd cause nightmare debugging scenarios, where someone writes code accidentally depending on insertion-ordered iteration, only to deploy it on a python runtime without it (<=3.5). I'm sure this has happened to someone, but at least it hasn't happened to me.
Reference: https://stackoverflow.com/a/60775590
Agreeing with kookamamie, yau8edq12i, and marliechiller
Hyrum and his dedicated self-proclaiming website reminded me of the gracelessness in the 3rd example of r/iamverysmart: Self-quoting
Matt Kulukundis (sp?) mentions this problem is his talk about Google's rather fancier Swiss tables.
At that point their debug builds would do a "coin toss" with 50.3% chance to be heads during hash table insertion and he expected some idiots would use that to generate random bits then be annoyed if it breaks. I believe in production it's entirely seeded from ASLR, so you're actually leaking address layout info if you try to use these bits as entropy instead of just to make the hash table defeat your bad unit tests.
Here's a link to that talk and mentioning of the 50.3%: https://youtu.be/ncHmEUmJZf4?t=2610
I have fixed a bug caused by this feature not being random enough.