Exemplo de aplicação da Lei de Hyrum em Golang

• Lei de Hyrum e Golang

  • Ao explorar recentemente o Gocodebase, foi encontrado um comentário interessante
  • Exemplo de código com o comentário: "Por causa da Lei de Hyrum, este texto não pode ser alterado"
  • No método Error() da struct MaxBytesError, é retornada a mensagem de erro "http: request body too large"

• Lei de Hyrum

  • Princípio nomeado em homenagem a Hyrum Wright, engenheiro de software do Google
  • Quando muitos usuários utilizam uma API, todo comportamento observável do sistema acabará sendo alvo de dependência por alguém
  • Todo comportamento observável no código, seja intencional ou acidental, acaba sendo utilizado por alguém
  • Explica por que alterar mensagens de erro pode quebrar código existente

• Casos em Golang

  • Também foram encontrados comentários mencionando a Lei de Hyrum nos pacotes crypto/rsa e internal/weak
  • Exemplos de comentários em crypto/rsa/rsa.go e crypto/rsa/pss.go
  • Exemplo de comentário no pacote internal/weak

• Observações

  • Isso não se limita ao Golang
  • Fenômeno semelhante também pode ser observado no processo de evolução do JavaScript
  • Esse fenômeno é chamado de Lei de Hyrum

• Considerações finais

  • Serve como lembrete para ter cuidado ao alterar código do qual outras pessoas podem depender
  • É importante projetar sistemas de forma que comportamentos não intencionais não se tornem dependências
  • É preciso lembrar que pequenas mudanças podem ter grande impacto

[GN⁺]

Opiniões do Hacker News

• A Lei de Hyrum é uma observação útil, mas é preciso tomar cuidado para não tirar conclusões erradas. O tempo total de execução de uma função também é uma propriedade observável, então otimizar uma função para torná-la mais rápida pode ser bom para 99,99999999% dos usuários, mas ainda assim pode ser uma mudança que quebra compatibilidade. Portanto, é preciso entender que uma "mudança incompatível" é um contrato social, não um contrato técnico. Autores de bibliotecas devem documentar quais partes da API não vão mudar e ter empatia com os usuários. Consumidores de bibliotecas devem entender que usar interfaces não documentadas pode ser arriscado e também ter empatia com os autores

• Na linguagem Go, a Lei de Hyrum e a compatibilidade retroativa são levadas muito a sério. Por exemplo, MaybeReadByte é usado na função GenerateKey para que o algoritmo não fique fixo. Estão trabalhando para resolver problemas com chaves ECDSA. A ordem de iteração de mapas é aleatorizada para não expor detalhes internos. A saída de rand.Rand é tratada como parte da promessa de compatibilidade, então muito esforço é feito para melhorá-la. Há sempre discussões sobre quais promessas fazer na documentação e quais comportamentos negar

• Como solução para certos problemas, recomenda-se usar erros sentinela em vez de erros baseados em string. Devem ser usados valores de erro, tipos ou constantes predefinidos para que consumidores da API não dependam de strings não técnicas. A Lei de Hyrum existe, mas seu impacto pode ser mitigado

• Uma forma de combater a Lei de Hyrum é adicionar aleatoriedade. O protocolo QUIC define campos não utilizados com valores aleatórios para evitar que roteadores passem a depender deles para identificar pacotes. Isso é chamado de "greasing" e ajuda a evitar a "ossification"

• Os projetistas de Go não queriam exceções, mas erros informais trazem problemas. É preciso discutir como lidar com erros estruturados sem pattern matching

• Houve uma experiência em um trabalho em que foi encontrado e corrigido um erro de digitação em uma mensagem de erro, mas a dependência desse erro tipográfico era tão profunda que não foi possível manter a correção e foi necessário reverter ao estado original

• Os erros de Go poderiam ter sido transformados em tipos enumerados, mas strings foram usadas como tipo, então não há como saber de que forma os consumidores vão depender disso. É uma decisão antiga de design, apesar de existirem alternativas melhores

• A Lei de Hyrum é o oposto exato do Princípio da Robustez/Lei de Postel. Se você for liberal no que aceita, precisa entender e documentar esse comportamento. A intenção é projetar APIs para que não sejam liberais no que aceitam

• A Lei de Hyrum aparece com frequência em testes. Vários tipos de teste quebram por causa de suposições sobre comportamentos não garantidos. Exemplos incluem mudanças na ordem dos elementos de um hashmap, mudanças em mensagens de erro e mudanças na forma de lidar com anos bissextos

• Alguns autores de pacotes podem ser ainda mais receptivos à Lei de Hyrum. Nos comentários do pacote json, foi observado que, embora sejam detalhes internos, pacotes amplamente usados acessam isso por meio de linkname