5 ms·

Hyrum's law: > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will b

Hyrum's law: > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

ronsor 1y ago
This is why you should randomize all behaviors which should not be depended on. Change things quickly and often if you're not making any promises.
- drdaeman 1y ago
  While I can imagine some edge cases where this approach can be meaningful, isn't that generally counterproductive? Not only one has to be actively aware about all the behaviors they don't document (which is surely not an easy task for any large project), they have to spend a non-negligible amount of time adding randomness to it in a way that would still allow all the internal use cases to work cohesively. This means you spend less time on doing something actually useful. Instead of randomizing, it should be sufficient to just figure out the semantics for clearly communicating what's the public APIs and stable, and what's internal and subject to change at whim. And maybe slap a big fat warning "if something is not documented - it's internal, and $deity help you if you depend on it, for we make no guarantees except that it'll break on some fine day and that day won't be so fine anymore". Then it's not your problem.
  - evertedsphere 1y ago
    until the day when the person/project/company whose code it breaks has a sufficient amount of pull over you/your team that it becomes your problem that's why you prevent it from ever coming into existence if you can
- madars 1y ago
  TLS does this with GREASE (Generate Random Extensions And Sustain Extensibility) - https://www.rfc-editor.org/rfc/rfc8701.html https://www.rfc-editor.org/rfc/rfc8701.html . HN discussion: https://news.ycombinator.com/item?id=39416277 https://news.ycombinator.com/item?id=39416277 (19 points, 8 comments) Go's implementation of JSON format for protobufs also does this: https://protobuf.dev/reference/go/faq/#unstable-json https://protobuf.dev/reference/go/faq/#unstable-json > To avoid giving the illusion that the output is stable, we deliberately introduce minor differences so that byte-for-byte comparisons are likely to fail.
  - koito17 1y ago
    Go also randomizes the iteration of map keys, to emphasize that maps are unordered and code should not rely on insertion order. For demonstration: package main import "fmt" func main() { m := map[string]int{"a": 1, "b": 2, "c": 3} for k, _ := range m { fmt.Println(k) } for k, _ := range m { fmt.Println(k) } } Sample output: c a b a b c Each run may produce different key orders.
    - metaltyphoon 1y ago
      I was under the assumption most languages to this.
      - db48x 1y ago
        Very few do, and only quite modern ones. Although I believe there are hashtable libraries where the iteration order is unspecified but generally consistent, only changing when a resize shuffles the elements into different buckets.
keybored 1y ago
Certain discussions on HN are just diagrams thanks to Laws(tm) and various one-liner tier references. - Hyrum’s Law (85%) - Emacs spacebar overheating (15%) The only way to prevent the decision diagram is to anticipate them and spell them out in the last paragraph. But on the other than that doesn’t very fun right.
- keybored 1y ago
  > But on the other than that doesn’t very fun right. When you write something an hour after your bedtime.

Hyrum's law: > With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

ronsor 1y ago

This is why you should randomize all behaviors which should not be depended on. Change things quickly and often if you're not making any promises.

drdaeman 1y ago
While I can imagine some edge cases where this approach can be meaningful, isn't that generally counterproductive? Not only one has to be actively aware about all the behaviors they don't document (which is surely not an easy task for any large project), they have to spend a non-negligible amount of time adding randomness to it in a way that would still allow all the internal use cases to work cohesively. This means you spend less time on doing something actually useful. Instead of randomizing, it should be sufficient to just figure out the semantics for clearly communicating what's the public APIs and stable, and what's internal and subject to change at whim. And maybe slap a big fat warning "if something is not documented - it's internal, and $deity help you if you depend on it, for we make no guarantees except that it'll break on some fine day and that day won't be so fine anymore". Then it's not your problem.
- evertedsphere 1y ago
  until the day when the person/project/company whose code it breaks has a sufficient amount of pull over you/your team that it becomes your problem that's why you prevent it from ever coming into existence if you can
madars 1y ago
TLS does this with GREASE (Generate Random Extensions And Sustain Extensibility) - https://www.rfc-editor.org/rfc/rfc8701.html https://www.rfc-editor.org/rfc/rfc8701.html . HN discussion: https://news.ycombinator.com/item?id=39416277 https://news.ycombinator.com/item?id=39416277 (19 points, 8 comments) Go's implementation of JSON format for protobufs also does this: https://protobuf.dev/reference/go/faq/#unstable-json https://protobuf.dev/reference/go/faq/#unstable-json > To avoid giving the illusion that the output is stable, we deliberately introduce minor differences so that byte-for-byte comparisons are likely to fail.
- koito17 1y ago
  Go also randomizes the iteration of map keys, to emphasize that maps are unordered and code should not rely on insertion order. For demonstration: package main import "fmt" func main() { m := map[string]int{"a": 1, "b": 2, "c": 3} for k, _ := range m { fmt.Println(k) } for k, _ := range m { fmt.Println(k) } } Sample output: c a b a b c Each run may produce different key orders.
  - metaltyphoon 1y ago
    I was under the assumption most languages to this.
    - db48x 1y ago
      Very few do, and only quite modern ones. Although I believe there are hashtable libraries where the iteration order is unspecified but generally consistent, only changing when a resize shuffles the elements into different buckets.

keybored 1y ago

Certain discussions on HN are just diagrams thanks to Laws(tm) and various one-liner tier references. - Hyrum’s Law (85%) - Emacs spacebar overheating (15%) The only way to prevent the decision diagram is to anticipate them and spell them out in the last paragraph. But on the other than that doesn’t very fun right.

keybored 1y ago
> But on the other than that doesn’t very fun right. When you write something an hour after your bedtime.