4 ms·

Hyrum's Law strikes again: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your s

Hyrum's Law strikes again: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/

qayxc 5y ago
Mark my words: Hyrum's Law will strike in full force and introduce a whole new world of pain once more and more software development will be done (or helped-) by machine learning. What happened here is a perfect example of what an optimiser might come up with and resulting systems will be so brittle and delicate that a whole new form of cargo cult might develop around them :D
- coliveira 5y ago
  Future systems will be like human genome: a small letter change will lead to the system self destroying after 20 days of flawless operation.
  - deleted 5y ago
    [deleted]
  - tryauuum 5y ago
    I wonder if there actually is a possibility of something like that in human genome. Are there any known bugs that can be introduced to human genome and instantly kill a human after, e.g. 18 years of normal operation?
    - a_t48 5y ago
      Aneurysms.
    - NavinF 5y ago
      Do genes associated with cancer count? I can't think of anything that kicks in instantly, but there are plenty of probabilistic bugs
    - masklinn 5y ago
      “Known” probably not because nobody cares but if you can edit the generic code of all cells (not just one) you just need to do a function-affecting substitution of a protein-coding segment for a vital protein. Doesn’t matter which one as long as it’s not solely developmental. It would not quite be instant though, the body would first have to run out of the existing supply then break down as operations stop. If you pick the right protein (e.g. something affecting the muscles or brain) I’d think the timescale would be minutes if not seconds. If you can only edit one cell or a small number if them then probably not, you can definitely cause long-term issues (e.g. cancers) but I would not think instant death an option. I think the GP was talking more about existing genetic defects leading to sudden issues down the line though.
  - masklinn 5y ago
    Surely they’d already the case? There’s tons of latent bugs which are only revealed because the conditions to trigger them have not been encountered yet. Every 4 years code breaks all over in leap days. A program crashing after not crashing is essentially “the system self destroying”.
Zababa 5y ago
It's intersting to see that some people add randomness to fight this, for example with maps in Go. It seems like it's the right choice.
- MaulingMonkey 5y ago
  Inserting randomness can help prevent denial of service attacks as well, by making it harder to manufacture pathological hash collisions (which can turn ~O(1) operations into O(N) operations).
- ncmncm 5y ago
  Right, like every release of any component should vary some detail that the spec doesn't guarantee. Especially, all hash functions should change on every release -- at least when building in debug mode.
  - vlovich123 5y ago
    Hash functions should use a random seed on every new container instance (or at least once per launch). Those hash tables that need specific properties of the hash should inject it in that way (cryptographic, deterministic, DOS-resistant, etc).
- jeffbee 5y ago
  Another place to insert randomness that could have uncovered this would be in the allocator size classes. In non-optimized builds, if your allocator has size classes, just pick them randomly. In my experience this uncovered a lot of bugs in programs linked against tcmalloc.
- yxhuvud 5y ago
  Other people fight it by adding a defined iteration order. That works just as well and don't introduce randomness.
  - wizzwizz4 5y ago
    But prevents optimisation, if that optimisation would lose the iteration order. If you need defined ordering in your type, use it. Otherwise, don't specify it.
tialaramex 5y ago
There's even a CPPCon talk about Google's "Swiss" tables with interruptions by Hyrum each time the new code's observable behaviour changes because, at Google, they internally have enough users for Hyrum's law to kick in all the time: https://www.youtube.com/watch?v=JZE3_0qvrMg https://www.youtube.com/watch?v=JZE3_0qvrMg The talk was presumably better live because Hyrum doesn't have a microphone, so his interjections are hard to follow, but it's a good way to illustrate. Some of the examples are much like this story, you design this sophisticated, heavily optimised unordered container for millions of items, and then your users put three items into it, and they depend on the order of those items and you "broke" their code by not having this behaviour you never promised and it made no sense to depend on. And the defence mentioned in this thread (randomise things which aren't guaranteed to have stability) is introduced because these are Google employees, they know about Hyrum, it just isn't enough. Sure the code failed when I tried to store 40 items due to your randomisation, but I found it worked OK with ten items as then the randomisation was defeated, so now I store ten items, and then your latest change broke that... The pathological use of data structure is why stuff like making the constructor for empty strings very cheap has a big effect on some codebases. Rust const-ified String::new() because an empty string doesn't need any heap store. So this means code which loops over a large array setting all the members to the empty string is only about as expensive as looping over an integer array setting all the integers to zero, it doesn't incur a heap allocation, or a function call. Of course modifying these strings now takes on the expense of allocating, but guess how often people who do stuff like this never actually touch the string...
- rasz 5y ago
  >they depend on the order of those items and you "broke" their code by not having this behaviour you never promised and it made no sense to depend on reminds me of a time my extension started glitching because localStorage stopped returning results in same order they were put in :o) Now that I think about it it happened somewhere around 2017-2018, did google drop it into Chrome at this point?

qayxc 5y ago

Mark my words: Hyrum's Law will strike in full force and introduce a whole new world of pain once more and more software development will be done (or helped-) by machine learning. What happened here is a perfect example of what an optimiser might come up with and resulting systems will be so brittle and delicate that a whole new form of cargo cult might develop around them :D

coliveira 5y ago
Future systems will be like human genome: a small letter change will lead to the system self destroying after 20 days of flawless operation.
- deleted 5y ago
  [deleted]
- tryauuum 5y ago
  I wonder if there actually is a possibility of something like that in human genome. Are there any known bugs that can be introduced to human genome and instantly kill a human after, e.g. 18 years of normal operation?
  - a_t48 5y ago
    Aneurysms.
  - NavinF 5y ago
    Do genes associated with cancer count? I can't think of anything that kicks in instantly, but there are plenty of probabilistic bugs
  - masklinn 5y ago
    “Known” probably not because nobody cares but if you can edit the generic code of all cells (not just one) you just need to do a function-affecting substitution of a protein-coding segment for a vital protein. Doesn’t matter which one as long as it’s not solely developmental. It would not quite be instant though, the body would first have to run out of the existing supply then break down as operations stop. If you pick the right protein (e.g. something affecting the muscles or brain) I’d think the timescale would be minutes if not seconds. If you can only edit one cell or a small number if them then probably not, you can definitely cause long-term issues (e.g. cancers) but I would not think instant death an option. I think the GP was talking more about existing genetic defects leading to sudden issues down the line though.
- masklinn 5y ago
  Surely they’d already the case? There’s tons of latent bugs which are only revealed because the conditions to trigger them have not been encountered yet. Every 4 years code breaks all over in leap days. A program crashing after not crashing is essentially “the system self destroying”.

Zababa 5y ago

It's intersting to see that some people add randomness to fight this, for example with maps in Go. It seems like it's the right choice.

MaulingMonkey 5y ago
Inserting randomness can help prevent denial of service attacks as well, by making it harder to manufacture pathological hash collisions (which can turn ~O(1) operations into O(N) operations).
ncmncm 5y ago
Right, like every release of any component should vary some detail that the spec doesn't guarantee. Especially, all hash functions should change on every release -- at least when building in debug mode.
- vlovich123 5y ago
  Hash functions should use a random seed on every new container instance (or at least once per launch). Those hash tables that need specific properties of the hash should inject it in that way (cryptographic, deterministic, DOS-resistant, etc).
jeffbee 5y ago
Another place to insert randomness that could have uncovered this would be in the allocator size classes. In non-optimized builds, if your allocator has size classes, just pick them randomly. In my experience this uncovered a lot of bugs in programs linked against tcmalloc.
yxhuvud 5y ago
Other people fight it by adding a defined iteration order. That works just as well and don't introduce randomness.
- wizzwizz4 5y ago
  But prevents optimisation, if that optimisation would lose the iteration order. If you need defined ordering in your type, use it. Otherwise, don't specify it.

tialaramex 5y ago

There's even a CPPCon talk about Google's "Swiss" tables with interruptions by Hyrum each time the new code's observable behaviour changes because, at Google, they internally have enough users for Hyrum's law to kick in all the time: https://www.youtube.com/watch?v=JZE3_0qvrMg https://www.youtube.com/watch?v=JZE3_0qvrMg The talk was presumably better live because Hyrum doesn't have a microphone, so his interjections are hard to follow, but it's a good way to illustrate. Some of the examples are much like this story, you design this sophisticated, heavily optimised unordered container for millions of items, and then your users put three items into it, and they depend on the order of those items and you "broke" their code by not having this behaviour you never promised and it made no sense to depend on. And the defence mentioned in this thread (randomise things which aren't guaranteed to have stability) is introduced because these are Google employees, they know about Hyrum, it just isn't enough. Sure the code failed when I tried to store 40 items due to your randomisation, but I found it worked OK with ten items as then the randomisation was defeated, so now I store ten items, and then your latest change broke that... The pathological use of data structure is why stuff like making the constructor for empty strings very cheap has a big effect on some codebases. Rust const-ified String::new() because an empty string doesn't need any heap store. So this means code which loops over a large array setting all the members to the empty string is only about as expensive as looping over an integer array setting all the integers to zero, it doesn't incur a heap allocation, or a function call. Of course modifying these strings now takes on the expense of allocating, but guess how often people who do stuff like this never actually touch the string...

rasz 5y ago
>they depend on the order of those items and you "broke" their code by not having this behaviour you never promised and it made no sense to depend on reminds me of a time my extension started glitching because localStorage stopped returning results in same order they were put in :o) Now that I think about it it happened somewhere around 2017-2018, did google drop it into Chrome at this point?