IMO it is nice to mention the code, which is deliberately put only to mitigate it. Google is known for those tricks and I know two examples from golang community:
* map in golang has a randomized iteration order based on a random number generated at each program startup. Thus your code will break, if you depend on a specific order
* https://github.com/protocolbuffers/protobuf-go/blob/30f628eeb303f2c29be7a381bf78aa3e3aabd317/internal/detrand/rand.go#L5 is used to input random spaces (or not) to a JSON text output in the same fashion. The goal is to break your code, if you except that the output will always looks the same
map in golang has a randomized iteration order based on a random number generated at each program startup.
That is far from the entire story, and also a misunderstanding: go’s hashmap is keyed / seeded as most languages are these days but that is in order to mitigate hashdos attacks (some languages actually have per-map seeds). The randomisation of iteration order is a side-effect of that.
However Go also starts hashmap iteration at a random offset (wrapping around), this is specifically designed to limit / break reliance on hashmap iteration order.
In much the same way that Newton’s law of gravity isn’t a commandment to never jump out a window, just a description of what happens if you do.
Jokes aside — there is a lot of value in just saying “this is a thing that happens, it’s a fact of life, how you deal with it is up to you”, without immediately jumping on a specific “solution” to the problem.
Yes, another great design decision on Go's early days was to rely on content of error messages, instead of having proper error handling infrastructure.
This was improved later on, yet it hardly improves the situation given how many packages in the wild still use strings for errors.
Revolutionary_Ad7262@reddit
IMO it is nice to mention the code, which is deliberately put only to mitigate it. Google is known for those tricks and I know two examples from golang community: *
mapin golang has a randomized iteration order based on a random number generated at each program startup. Thus your code will break, if you depend on a specific order * https://github.com/protocolbuffers/protobuf-go/blob/30f628eeb303f2c29be7a381bf78aa3e3aabd317/internal/detrand/rand.go#L5 is used to input random spaces (or not) to a JSON text output in the same fashion. The goal is to break your code, if you except that the output will always looks the samemasklinn@reddit
That is far from the entire story, and also a misunderstanding: go’s hashmap is keyed / seeded as most languages are these days but that is in order to mitigate hashdos attacks (some languages actually have per-map seeds). The randomisation of iteration order is a side-effect of that.
However Go also starts hashmap iteration at a random offset (wrapping around), this is specifically designed to limit / break reliance on hashmap iteration order.
aldld@reddit
Joke's on them, my crypto library uses a special random number generator based map iteration.
kbielefe@reddit
Just keep in mind, Hyrum's law is not a commandment to never change a minor public API, it's an observation warning you of the consequences.
pdpi@reddit
In much the same way that Newton’s law of gravity isn’t a commandment to never jump out a window, just a description of what happens if you do.
Jokes aside — there is a lot of value in just saying “this is a thing that happens, it’s a fact of life, how you deal with it is up to you”, without immediately jumping on a specific “solution” to the problem.
pjmlp@reddit
Yes, another great design decision on Go's early days was to rely on content of error messages, instead of having proper error handling infrastructure.
This was improved later on, yet it hardly improves the situation given how many packages in the wild still use strings for errors.
TooManyBison@reddit
Relevant xkcd https://xkcd.com/1172/