-
La ley de Hyrum y Golang
- Mientras exploraba recientemente la base de código de Go, encontré un comentario interesante.
- Un ejemplo de código con un comentario que dice: "No se puede cambiar este texto por la ley de Hyrum".
- El método
Error() de la estructura MaxBytesError devuelve el mensaje de error "http: request body too large".
-
La ley de Hyrum
- Un principio nombrado en honor a Hyrum Wright, ingeniero de software de Google.
- Dice que, si muchos usuarios usan una API, alguien terminará dependiendo de todo comportamiento observable del sistema.
- Todo comportamiento observable en el código, ya sea intencional o accidental, eventualmente será usado como dependencia por alguien.
- Explica por qué cambiar un mensaje de error puede romper código existente.
-
Casos en Golang
- También se encontraron comentarios que mencionan la ley de Hyrum en los paquetes
crypto/rsa e internal/weak.
- Ejemplos de comentarios en
crypto/rsa/rsa.go y crypto/rsa/pss.go.
- Ejemplo de comentario en el paquete
internal/weak.
-
Observaciones
- No es algo limitado solo a Golang.
- Se puede observar un fenómeno similar en la evolución de JavaScript.
- A este fenómeno se le llama la ley de Hyrum.
-
Pensamiento final
- Nos recuerda que hay que tener cuidado al cambiar código del que otras personas podrían depender.
- Es importante diseñar sistemas para evitar que se dependa de comportamientos no intencionales.
- Hay que recordar que un cambio pequeño puede tener un gran impacto.
1 comentarios
Comentarios de Hacker News
La ley de Hyrum es una observación útil, pero hay que tener cuidado de no sacar conclusiones equivocadas. El tiempo total de ejecución de una función también es una propiedad observable, así que optimizar una función para hacerla más rápida puede ser bueno para el 99.99999999% de los usuarios, pero aun así puede ser un cambio que rompe compatibilidad. Por lo tanto, hay que entender que un "breaking change" es un contrato social, no un contrato técnico. Quienes escriben librerías deben documentar qué partes de la API no van a cambiar y tener empatía con los usuarios. Quienes consumen librerías deben entender que usar interfaces no documentadas puede ser riesgoso y tener empatía con quienes las mantienen
En Go, la ley de Hyrum y la compatibilidad hacia atrás se consideran muy importantes. Por ejemplo, en la función GenerateKey se usa MaybeReadByte para que el algoritmo no quede fijado. Se está trabajando para resolver problemas con las claves ECDSA. El orden de iteración de los mapas se aleatoriza para no exponer detalles internos. La salida de rand.Rand se considera parte de la promesa de compatibilidad y se ha invertido mucho esfuerzo en mejorarla. Siempre se discute qué promesas hacer en la documentación y qué comportamientos negar explícitamente
Como solución para ciertos problemas, se recomienda usar errores centinela en lugar de errores basados en cadenas. Para evitar que quienes consumen la API dependan de cadenas no técnicas, se deben usar valores de error predefinidos, tipos o constantes. La ley de Hyrum existe, pero su impacto puede mitigarse
Una forma de contrarrestar la ley de Hyrum es agregar aleatoriedad. El protocolo QUIC establece campos no utilizados con valores aleatorios para evitar que los routers dependan de ellos para identificar paquetes. A esto se le llama "greasing" y sirve para prevenir la "ossification"
Los diseñadores de Go no querían excepciones, pero los errores informales tienen problemas. Hace falta discutir cómo manejar errores tipados sin pattern matching
Alguien contó que en un trabajo encontró y corrigió un error tipográfico en un mensaje de error, pero la dependencia de ese typo era tan profunda que no se pudo mantener la corrección y hubo que revertirlo al estado original
Los errores de Go podrían haberse cambiado a un tipo enum, pero se usó string como tipo y no se puede saber de qué forma van a depender de eso quienes consumen la API. Es una decisión de diseño antigua, aunque existían alternativas mejores
La ley de Hyrum es lo opuesto al Robustness Principle/Postel's Law. Si se es liberal en lo que se acepta, hay que entender y documentar esas formas. Se intenta diseñar APIs que no sean liberales en lo que aceptan
La ley de Hyrum aparece con frecuencia en las pruebas. Distintos tipos de tests se rompen por suposiciones sobre comportamientos no garantizados. Por ejemplo, cambios en el orden de los elementos de un Hashmap, cambios en mensajes de error o cambios en la forma de manejar años bisiestos
Algunos autores de paquetes pueden aceptar más la ley de Hyrum. En los comentarios del paquete
json, se menciona que, aunque es un detalle interno, se descubrió que paquetes muy usados acceden a ello mediante linkname