←back to thread

Hyrum’s Law in Golang

(abenezer.org)
317 points thunderbong | 5 comments | 21 Nov 24 07:12 UTC | HN request time: 6.395s | source
Show context
kibwen ◴[21 Nov 24 13:08 UTC] No.42203962[source]▶
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.

replies(9): >>42204203 #>>42204851 #>>42205110 #>>42205152 #>>42206063 #>>42206661 #>>42207782 #>>42209267 #>>42216851 #
1. bluGill ◴[21 Nov 24 15:21 UTC] No.42205152[source]▶
That used to be a problem in the 1980s. Thus PCs came with a turbo button to slow them down, and 8 bit computers went the entire decade without upgrading their speed even though faster CPUs were available. These days nearly everything runs on more than one CPU and so nobody relies on function runtime (other than is if fast enough). Even in embedded they have been burned by their one CPU going out of production and so try to avoid that dependency because it cannot be relied on anymore.
replies(3): >>42207038 #>>42210679 #>>42211902 #
2. hinkley ◴[21 Nov 24 18:16 UTC] No.42207038[source]▶
I found a used copy of Warcraft III and found it was unplayable because the scrolling algorithm ran as fast as possible with no minimum time. Any map bigger than 2x2 screens you could not scroll to the middle.
replies(1): >>42210201 #
3. marcus_holmes ◴[22 Nov 24 00:53 UTC] No.42210201[source]▶
I used to enjoy Wing Commander back in the 90's. Then I upgraded my PC and it became unplayably fast - 1 second after I took off the "you died" screen appeared.
4. outworlder ◴[22 Nov 24 02:39 UTC] No.42210679[source]▶
In the 8 bit computer era, we knew exactly how much time any given instruction took. Retrieving some precision clock (not available!) and computing the time delta between runs - as is trivially done today - would probably be more computing power than they had at the time. Every cycle counted. Not very surprising that it wasn't done at that era. Also, there wasn't a "winning" instruction set or compilers able to target different architectures, so there was far more at stake than just clock speeds. If they changed the processor, you lost all your software.

DOS didn't have any precision clocks either as far as I know (it seems that there's interrupt 1A but it only updates 18 times a second, which is an eternity). Apparently there's 8254 based timer code after a few PC generations.

Windows 95 came up with QueryPerformanceCounter() and that simplified life quite a bit.

5. thayne ◴[22 Nov 24 07:43 UTC] No.42211902[source]▶
> nobody relies on function runtime

Maybe not intentionally.

But there have been several times where I've seen bugs where two tasks are done concurrently, but task A always takes longer than task B, then someone makes A faster, and that exposes some race condition or deadlock that only occurs if A completes before B.