Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hyrum’s Law in Golang

abenezer.org

Post reply on HN
Print view View original

141–150 of 190 posts

Re: Hyrum’s Law in Golang

#141

Post by remus »

adrianmsmith wrote: post #132

It's interesting that this law is the exact opposite of the Robustness Principle / Postel's Law. > be conservative in what you send, be liberal in what you accept If you are liberal in what you accept, you'd better understand the ways in which you've been liberal, and document them (at least) internally, because you're going to have to support all those ways forever, even after huge codebase changes, due to Hyrum's L…

> I try to avoid creating APIs which are "liberal in what they accept" for exactly that reason.

That's my preference too. When you have relaxed criteria about what kind of data you accept via an API I find you inevitably end up having to make decisions about how to massage that data in to some sort of canonical format, and those decisions almost always seem to end up leading to behaviour that's surprising to users in one way or another.

Re: Hyrum’s Law in Golang

#143

Post by sublimefire »

There are cases when you need to make a choice if you want to fix the bug as it might break many people who rely on it. There is no real good answer but to be able to look forward and anticipate the misuse.

Re: Hyrum’s Law in Golang

#144

Post by ljm »

AlotOfReading wrote: post #128
ljm wrote: post #122

Earlier quoted context omitted.

I feel like this is approaching absurdity, if only because something like the total runtime of a function is not under the control of the author of the function. The operating environment will have an impact on that, for example, as will the load the system is currently experiencing. A GC pass can affect it. In short, I wouldn't consider emergent behaviours of a machine as part of an intentional interface or any kind…

It's quite common in cryptography for the runtime to be important. For example, password verification time shouldn't depend on the value of the key or the password. Systems have been broken because someone wrote a string compare that returned early.

And, since most languages short circuit on basic string comparisons, you'd have some form of `secure_compare` function that compares two strings in constant time, and that behaviour is contracted in the name of the function.

Nobody is rewriting `==` to compare strings in constant time, not because it breaks some kind of API contract, but because it would result in a massive waste of CPU time. The point is, though, that they could. But then they are deciding to sacrifice performance for this one problem.

Crypto is obviously a case of it own when it comes to optimisations and as much as I called out the parent for approaching the absurd, we can pull out many similar special cases of our own.

Re: Hyrum’s Law in Golang

#145

Post by wbl »

hinkley wrote: post #138
renewiltord wrote: post #120

Earlier quoted context omitted.

It’s a classic. Binance will give you 429 errors to back off then 418s to tell you you will be IP banned and then they’ll ban you.

Google’s spiders will punish you for giving them too many 429 responses. It’s hell for hosting sites with vanity urls. They can’t tell they’re sending you 50+ req/s. It’s practically a protection racket. Only AWS gets the money.

50 requests/sec? Did you forget a few zeros?

Re: Hyrum’s Law in Golang

#146

Post by tshaddox »

kibwen wrote: post #74

Hyrum's Law is one of those observations that's certainly useful, but be careful not to fixate on it and draw the wrong conclusions. Consider that even the total runtime of a function is an observable property, which means that optimizing a function to make it faster is a breaking change (what if suddenly one of your queues clears too fast and triggers a deadlock??), despite the fact that 99.99999999% of your users w…

> Consider that even the total runtime of a function is an observable property, which means that optimizing a function to make it faster is a breaking change

Well yeah, that's pretty much the textbook example of Hyrum's Law (or some funnier variation like "I was relying on the heat from the CPU to warm my bedroom, can you please revert your change that improved CPU performance").

Re: Hyrum’s Law in Golang

#147

Post by hinkley »

wbl wrote: post #145
hinkley wrote: post #138

Earlier quoted context omitted.

Google’s spiders will punish you for giving them too many 429 responses. It’s hell for hosting sites with vanity urls. They can’t tell they’re sending you 50+ req/s. It’s practically a protection racket. Only AWS gets the money.

50 requests/sec? Did you forget a few zeros?

Little’s law is a bitch, and you can get away with a little throttling but not much.

Also, that’s a bit dismissive for HN.

Re: Hyrum’s Law in Golang

#148

Post by fulafel »

dhosek wrote: post #110

At one job, I found a misspelling in an error message and fixing it only to discover that the web of dependencies on that misspelled text was so deep that it was impractical to fix and had to return to the misspelled text. It still bugs me.

At least in the post context there's still time to fix "Golang".

Re: Hyrum’s Law in Golang

#149

Post by estebarb »

LudwigNagasena wrote: post #75
hambes wrote: post #70

Earlier quoted context omitted.

I don't understand your point. The lesson is "don't rely on magic strings, instead rely on exported and documented constants, otherwise your code might break".

My point is that a few years ago there was no exported and document constant. The lesson should be "provide sensible tools, otherwise your consumers will have to rely on implementation details for the most basic expected stuff".

That is the kind of stuff I would have expected `go vet` to fix.
Post reply on HN