Exemples d’application de la loi de Hyrum dans Golang

• La loi de Hyrum et Golang

  • En explorant récemment Gocodebase, l’auteur est tombé sur un commentaire intéressant
  • Exemple de code avec un commentaire disant : « À cause de la loi de Hyrum, ce texte ne peut pas être modifié »
  • La méthode Error() de la structure MaxBytesError renvoie le message d’erreur « http: request body too large »

• La loi de Hyrum

  • Principe nommé d’après Hyrum Wright, ingénieur logiciel chez Google
  • L’idée est que lorsqu’un grand nombre d’utilisateurs utilisent une API, tout comportement observable du système finira par être utilisé comme dépendance par quelqu’un
  • Dans le code, tout comportement observable, intentionnel ou accidentel, finit par être utilisé comme dépendance par quelqu’un
  • Explication de la raison pour laquelle changer un message d’erreur peut casser du code existant

• Exemples dans Golang

  • Des commentaires mentionnant la loi de Hyrum ont aussi été trouvés dans les packages crypto/rsa et internal/weak
  • Exemples de commentaires dans crypto/rsa/rsa.go et crypto/rsa/pss.go
  • Exemple de commentaire dans le package internal/weak

• Observation

  • Ce n’est pas limité à Golang
  • Un phénomène similaire peut aussi être observé dans l’évolution de JavaScript
  • Ce phénomène est appelé la loi de Hyrum

• Réflexion finale

  • Cela rappelle qu’il faut être prudent lorsqu’on modifie du code dont d’autres peuvent dépendre
  • Il est important de concevoir les systèmes de façon à éviter que des comportements non intentionnels ne deviennent des dépendances
  • Il faut se souvenir qu’un petit changement peut avoir de grandes conséquences

[GN⁺]

Avis Hacker News

• La loi de Hyrum est une observation utile, mais il faut veiller à ne pas en tirer de mauvaises conclusions. Le temps d’exécution total d’une fonction est lui aussi une propriété observable, donc optimiser une fonction pour la rendre plus rapide peut être bénéfique pour 99,99999999 % des utilisateurs, tout en constituant malgré tout un changement cassant. Il faut donc comprendre qu’un « changement cassant » relève d’un contrat social, et non d’un contrat technique. Les auteurs de bibliothèques doivent documenter ce qui, dans leur API, est garanti stable et faire preuve d’empathie envers les utilisateurs. Les utilisateurs de bibliothèques doivent comprendre qu’utiliser une interface non documentée peut être risqué et faire preuve d’empathie envers les auteurs

• En Go, la loi de Hyrum et la rétrocompatibilité sont prises très au sérieux. Par exemple, GenerateKey utilise MaybeReadByte afin que l’algorithme ne soit pas figé. Des efforts sont en cours pour résoudre les problèmes liés aux clés ECDSA. L’ordre d’itération des maps est rendu aléatoire pour éviter d’exposer les détails internes. La sortie de rand.Rand est considérée comme faisant partie de la promesse de compatibilité, ce qui demande beaucoup d’efforts pour pouvoir l’améliorer. Il y a toujours des discussions sur ce qu’il faut promettre dans la documentation et sur les comportements dont il faut explicitement nier la garantie

• Comme solution à certains problèmes spécifiques, il est recommandé d’utiliser des erreurs sentinelles plutôt que des erreurs fondées sur des chaînes de caractères. Il faut employer des valeurs d’erreur, types ou constantes prédéfinis afin que les consommateurs d’API ne dépendent pas de chaînes non techniques. La loi de Hyrum existe, mais son impact peut être atténué

• Une façon de lutter contre la loi de Hyrum consiste à ajouter de l’aléatoire. Le protocole QUIC définit les champs inutilisés à des valeurs aléatoires afin que les routeurs ne s’appuient pas dessus pour identifier les paquets. Cela s’appelle le « greasing » et permet d’éviter l’« ossification »

• Les concepteurs de Go ne voulaient pas d’exceptions, mais les erreurs informelles posent problème. Il faut discuter de la manière de gérer des erreurs structurées sans pattern matching

• Quelqu’un raconte avoir repéré et corrigé une faute de frappe dans un message d’erreur au travail, avant de devoir revenir à la version d’origine, car des dépendances s’appuyaient sur cette faute de manière trop profonde pour qu’elle puisse être corrigée

• Les erreurs de Go auraient pu être transformées en types énumérés, mais les chaînes ont été utilisées comme type, si bien qu’on ne peut pas savoir comment les consommateurs vont en dépendre. C’est une ancienne décision de conception, alors qu’il existe de meilleures alternatives

• La loi de Hyrum est à l’opposé du principe de robustesse / loi de Postel. Si l’on est libéral dans ce que l’on accepte, il faut comprendre et documenter cette façon de faire. Il faut essayer de concevoir des API qui ne soient pas trop libérales dans ce qu’elles acceptent

• La loi de Hyrum apparaît souvent dans les tests. Divers types de tests cassent à cause d’hypothèses sur des comportements non garantis. Par exemple, un changement de l’ordre des éléments d’une hashmap, une modification d’un message d’erreur ou un changement dans la manière de gérer les années bissextiles

• Certains auteurs de packages peuvent être plus enclins à accepter la loi de Hyrum. Un commentaire du package json mentionne qu’il s’agit d’un détail interne, mais que des packages largement utilisés y accèdent via linkname