←back to thread

Hyrum’s Law in Golang

(abenezer.org)
317 points thunderbong | 3 comments | 21 Nov 24 07:12 UTC | HN request time: 0.89s | 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. materielle ◴[21 Nov 24 15:17 UTC] No.42205110[source]▶
I think everything you said is totally correct for open source library owners.

But let me offer a different perspective: Hyrum’s law is neither a technical contract nor a social contract. It’s an emergent technical property in a sufficiently used system.

How you respond to that emergent property depends on the social context.

If you are a FOSS maintainer, and an optimization speeds up 99.99% of users and requires 0.01% to either fix their code or upgrade to a new API, you ship it.

If you are working at a big tech company, you need both the optimization and breaking 0% of the company. So you will work across teams to find the sweet spot.

If you are an enterprise software company, and you change breaks 0.1% if users, but that user is one of the top 5 contracts, you don’t ship.

replies(2): >>42205395 #>>42206806 #
2. uoaei ◴[21 Nov 24 15:39 UTC] No.42205395[source]▶
> It’s an emergent ... property in a sufficiently used system

This is also a sufficient description of "social contract" for this context.

3. kmacdough ◴[21 Nov 24 17:54 UTC] No.42206806[source]▶
Seems like you're saying the same thing, just using "social contract" differently. I think they use social contract not to mean binding, but to highlight the fact that Hyrums Law must be taken in the social context of the project. In the case of large SW company, the social contract would be to not break services, even when folks are misusing an API. And for a popular open source project, it would mean not breaking a widely used behavior, even if it isn't specified or officially supported. Determining the social contract seems to be precisely what you describe as "not a social contract".