Guia de Estilo de Rust

Artigo original ↗ Discussão no Hacker News ↗

O novo guia de estilo de Rust do Google está provocando debate sobre se convenções rígidas orientadas a humanos ainda importam quando bases de código grandes são cada vez mais escritas e revisadas com ajuda de IA. Muitos comentaristas argumentam que APIs consistentes, estrutura de crates e padrões (como preferir enums a bools, crates pequenos e ownership claro versus Rc/Arc) são ainda mais importantes para legibilidade, segurança e coordenação entre grandes equipes — especialmente em monorepos e sistemas distribuídos. A discussão também se amplia para um argumento mais amplo sobre o papel de Rust em relação a C e C++, a manutenção de longo prazo em um mundo assistido por IA e o peso que se deve dar hoje às diretrizes de engenharia do Google.

Papel dos Guias de Estilo em uma Era de LLM/“Agentic”

  • Alguns argumentam que os guias de estilo são menos relevantes porque o código será gerado por LLMs e lido principalmente por meio de explicações de IA, não diretamente por humanos.
  • Outros contrapõem fortemente que:
    • O estilo ainda importa para legibilidade, manutenção de longo prazo e trabalho entre equipes.
    • Um design consistente de API e de implementação é útil independentemente de quem escreve o código.
    • Em um mundo “agentic”, regras claras ajudam humanos a revisar e controlar significativamente a saída da IA.
  • Alguns relatam fornecer guias de estilo aos LLMs; os modelos nem sempre os seguem, e a aplicação manual é difícil sem forte autoridade ou linters automatizados.

Rust vs C/C++ e o Futuro

  • Debate sobre se ainda se escreve novo código em C/C++:
    • Muitos dizem que sim: defesa, embarcados, HPC, jogos, grandes bases de código existentes e projetos importantes ainda usam bastante C/C++.
    • Outros afirmam que Rust está “devorando” C/C++, especialmente em sistemas novos e sensíveis a segurança, com algumas empresas “all in” em Rust.
  • Contra-argumentos:
    • Ecossistemas (por exemplo, desenvolvimento de jogos) levarão muitos anos para migrar, se é que o farão.
    • Certos domínios (desempenho extremo, designs orientados a dados) podem achar o borrow checker de Rust ergonomicamente custoso em comparação com C++.
    • Alguns acreditam que LLMs tornarão a escolha da linguagem menos importante, ou até relegarão Rust a uma representação intermediária.

Regras de Estilo Específicas em Debate

  • Enums vs bools: Amplamente apreciado; enums restringem a interpretação e evitam flags confusas.
  • Rc/Arc vs lifetimes:
    • Um lado: use Rc/Arc livremente para dados que escapam da stack; lifetimes são “estranhos”.
    • Outro lado: ownership compartilhado obscurece quem possui o quê; lifetimes são mais claros e Rc/Arc devem ser reservados para necessidades reais de compartilhamento.
  • Nomenclatura de getters/setters:
    • O guia prefere nomes de método simples para getters e set_/estilo builder para setters, alinhando-se com a stdlib/protos do Rust.
    • Alguns preferem o oposto por fluidez e consistência em APIs no estilo builder de UI/TUI.
  • Enums #[non_exhaustive]:
    • Críticos: enfraquece a verificação de exaustividade e transforma segurança em tempo de compilação em bugs em tempo de execução.
    • Defensores (especialmente em “escala Google” e em sistemas distribuídos): necessário para evolução de API e para evitar mudanças quebradoras massivas entre muitas equipes; combinado com lints para sinalizar padrões omitidos.

Práticas Específicas de Google/Chromium

  • Preferência por muitos crates pequenos e por evitar aninhamento profundo de módulos:
    • Justificativa: builds mais rápidos e mais paralelizáveis; dependências mais granulares; melhor cacheabilidade com Blaze/Bazel (sem compilação incremental de crate).
  • Desencorajar async/await no Rust do Chromium por enquanto.
  • Ênfase em distinguir código de biblioteca de código de aplicação e em regras aplicáveis de forma uniforme em escala de grande empresa, mesmo que nem sempre sejam as “ideais” para projetos pequenos.

Detalhes de Ferramentas e Nomenclatura

  • rustfmt existe, mas o guia cobre preocupações mais amplas de design/estilo.
  • Há discordância sobre:
    • Importar tipos sem qualificação vs usar nomes totalmente qualificados para clareza.
    • Caixa das letras em literais hexadecimais (o guia prefere minúsculas) e outros pequenos ajustes de legibilidade.