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

71–80 of 190 posts

Re: Hyrum’s Law in Golang

#71

Post by majewsky »

sixfiveotwo wrote: post #57

Quite interesting, thank you. However, in this specific instance, even if the text cannot be changed, couldn't the error itself in the server be processed and signaled differently, eg. by returning a Status Code 413[1], since clients ought to recognize that status code anyway? [1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413

Since the caller gets this as an error object, instead of as a plain string, it seems likely that this is within the same process, i.e. a library function returns the MaxBytesError to a level higher in the business logic, without a network transmission inbetween.

Re: Hyrum’s Law in Golang

#72

Post by mseepgood »

simiones wrote: post #66
indulona wrote: post #23

This is why we have semantic versioning.

Semantic versioning does nothing to help here. If you don't realize that people are depending on such a behavior, you won't increment the major version number.

And if you realize it (as in this case) you probably don't want to increase the major version number either, but leave it as-is (unless you follow the CADT model of maintainership).

Re: Hyrum’s Law in Golang

#73

Post by OskarS »

boloust wrote: post #58
FiloSottile wrote: post #21

Hah, I wrote the crypto/rsa comments. We take Hyrum's Law (and backwards compatibility [1]) extremely seriously in Go. Here are a couple more examples: - We randomly read an extra byte from random streams in various GenerateKey functions (which are not marked like the ones in OP) with MaybeReadByte [2] to avoid having our algorithm locked in - Just yesterday someone reported that a private ECDSA key with a nil public…

Ironically, I once wrote a load balancer in Go that relied on the randomized map iteration ordering.

Man, you really can’t escape Hyrum’s Law ever! Now we have people depending on the iteration order being random!

Re: Hyrum’s Law in Golang

#74

Post by kibwen »

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 would probably appreciate having code that runs faster for no effort on their part.

Therefore it's unavoidable that what constitutes a "breaking change" is a social contract, not a technical contract, because the alternative is that literally nothing is ever allowed to change. So as a library author, document what parts of your API are guaranteed not to change, be reasonable, and have empathy for your users. And as a library consumer, understand that making undocumented interfaces into load-bearing constructs is done at your own risk, and have empathy for the library authors.

Re: Hyrum’s Law in Golang

#75

Post by LudwigNagasena »

hambes wrote: post #70
LudwigNagasena wrote: post #55

Earlier quoted context omitted.

So the people who decided to make a stringly type error with `errors.New("http: request body too large")` and make you suffer, now can remove a stringly typed error and make you suffer even more? What would the lesson be? What would consumers learn?

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".

Re: Hyrum’s Law in Golang

#76

Post by vitus »

lovasoa wrote: post #48

An interesting topic is how to fight Hyrum's law. A possibility is to add randomness in things you don't want people to rely on. If I remember well, this is what the QUIC protocol does. Some fields are unused in the current version, but required by the specification to be set to random values, not null bytes, so that routers don't start relying on them to identify the packets. EDIT. I think I found the source: https:…

> I think they call it "greasing"

This is a reference to RFC 8701, which coined the acronym GREASE ("Generate Random Extensions And Sustain Extensibility"), first in the context of TLS.

https://www.rfc-editor.org/rfc/rfc8701.html

(The earliest draft of the RFC dates back to mid-2016, which is likely the first public mention of the term: https://datatracker.ietf.org/doc/html/draft-davidben-tls-gre...)

Re: Hyrum’s Law in Golang

#77

Post by djoldman »

mormegil wrote: post #63
djoldman wrote: post #61

One interesting metric for LLMs is that for some tasks their precision is garbage but recall is high. (in essence: their top 5 answers are wrong but top 100 have the right answer). As relates to infinite context, if one pairs the above with some kind of intelligent "solution-checker," it's interesting if models may be able to provide value across absolute monstrous text sizes where it's critical to tie two facts that…

This probably didn't belong here?

It didn't! Thanks

Re: Hyrum’s Law in Golang

#78

Post by ahoka »

OskarS wrote: post #73
boloust wrote: post #58

Earlier quoted context omitted.

Ironically, I once wrote a load balancer in Go that relied on the randomized map iteration ordering.

Man, you really can’t escape Hyrum’s Law ever! Now we have people depending on the iteration order being random!

That's why it's totally stupid to randomize it.

Re: Hyrum’s Law in Golang

#79

Post by atsjie »

FiloSottile wrote: post #35
mkesper wrote: post #24

Earlier quoted context omitted.

The nil key case really makes me wonder how sane it is to support these cases. You will be forced to lug this broken behavior with you forever, like the infamous A20 line ( https://en.wikipedia.org/wiki/A20_line ).

> You will be forced to lug this broken behavior with you forever Yep, welcome to my life.

Wouldn't that broken behaviour be a potential security issue by itself?

I do remember Go making backwards incompatible changes in some rare scenarios like that.

(and technically the loopvar fix was a big backwards incompatible change; granted that was done with a lot of consideration)

Re: Hyrum’s Law in Golang

#80

Post by klabb3 »

lovasoa wrote: post #48

An interesting topic is how to fight Hyrum's law. A possibility is to add randomness in things you don't want people to rely on. If I remember well, this is what the QUIC protocol does. Some fields are unused in the current version, but required by the specification to be set to random values, not null bytes, so that routers don't start relying on them to identify the packets. EDIT. I think I found the source: https:…

This is wonderful. I’m quite familiar with QUIC but hadn’t heard about this.

Nothing like waking up after 10 years, realize you now really need those bits, and 20 different routers from 10 brands have decided that those bits must be a certain way.

Bonus points for checksums/crypto that breaks on the other end if the bits have been messed with. Curse those middle-boxes and their “clever hacks”.

Post reply on HN