Guía de estilo de Rust

Artículo original ↗ Discusión en Hacker News ↗

La nueva guía de estilo de Rust de Google está provocando un debate sobre si las convenciones estrictas orientadas a humanos siguen importando cuando los grandes codebases se escriben y revisan cada vez más con ayuda de IA. Muchos comentaristas sostienen que las APIs consistentes, la estructura de crates y patrones (como preferir enums frente a bools, crates pequeños y una propiedad clara frente a Rc/Arc) son aún más importantes para la legibilidad, la seguridad y la coordinación en equipos grandes, especialmente en monorepos y sistemas distribuidos. El hilo también se amplía hacia un argumento más general sobre el papel de Rust frente a C y C++, el mantenimiento a largo plazo en un mundo asistido por IA y cuánto peso dar hoy a las directrices de ingeniería de Google.

Papel de las guías de estilo en una era de LLM/“agentic”

  • Algunos sostienen que las guías de estilo son menos relevantes porque el código será generado por LLM y se leerá sobre todo mediante explicaciones de IA, no directamente por humanos.
  • Otros replican con fuerza que:
    • El estilo sigue importando para la legibilidad, el mantenimiento a largo plazo y el trabajo entre equipos.
    • Un diseño consistente de la API y de la implementación es útil independientemente de quién escriba el código.
    • En un mundo “agentic”, reglas claras ayudan a los humanos a revisar y controlar de forma significativa la salida de la IA.
  • Algunos cuentan que les dan guías de estilo a los LLM; los modelos no siempre las siguen, y hacerlas cumplir manualmente es difícil sin una autoridad fuerte o linters automatizados.

Rust frente a C/C++ y el futuro

  • Debate sobre si todavía se sigue escribiendo nuevo C/C++:
    • Muchos dicen que sí: defensa, sistemas embebidos, HPC, juegos, grandes bases de código existentes y proyectos importantes siguen usando C/C++ de forma intensa.
    • Otros afirman que Rust está “comiéndose” a C/C++, especialmente en sistemas nuevos y sensibles a la seguridad, con algunas empresas “all in” con Rust.
  • Contraargumentos:
    • Los ecosistemas (por ejemplo, desarrollo de juegos) tardarán muchos años en migrar, si es que alguna vez lo hacen.
    • Ciertos dominios (rendimiento extremo, diseños orientados a datos) pueden encontrar el borrow checker de Rust costoso ergonómicamente en comparación con C++.
    • Algunos creen que los LLM harán que la elección del lenguaje importe menos, o incluso relegarán Rust a una representación intermedia.

Reglas específicas de estilo en debate

  • Enums vs bools: Muy apreciados; los enums restringen la interpretación y evitan banderas confusas.
  • Rc/Arc vs lifetimes:
    • Un bando: usar Rc/Arc libremente para datos que salen de la pila; los lifetimes son “raros”.
    • Otro bando: la propiedad compartida oculta quién posee qué; los lifetimes son más claros y Rc/Arc debería reservarse para necesidades genuinas de compartición.
  • Nombres de getters/setters:
    • La guía prefiere nombres de método desnudos para los getters y set_/estilo builder para los setters, en línea con la stdlib/protos de Rust.
    • Algunos prefieren lo contrario por fluidez y coherencia en APIs de estilo builder para UI/TUI.
  • Enums #[non_exhaustive]:
    • Críticos: socavan la comprobación de exhaustividad y convierten la seguridad en tiempo de compilación en errores en tiempo de ejecución.
    • Partidarios (especialmente a “escala Google” y en sistemas distribuidos): necesarios para la evolución de APIs y para evitar cambios rompientes masivos entre muchos equipos; combinados con lints para señalar patrones omitidos.

Prácticas específicas de Google/Chromium

  • Preferencia por muchos crates pequeños y por evitar anidamientos profundos de módulos:
    • Justificación: compilaciones más rápidas y paralelizables; dependencias más granulares; mejor capacidad de caché con Blaze/Bazel (sin compilación incremental de crates).
  • Desaconsejar async/await en Rust para Chromium por ahora.
  • Énfasis en distinguir entre código de biblioteca y de aplicación, y en reglas que sean aplicables de forma uniforme a escala de gran empresa, aunque no siempre sean “ideales” para proyectos pequeños.

Detalles de herramientas y nombres

  • rustfmt existe, pero la guía cubre preocupaciones más amplias de diseño/estilo.
  • Hay desacuerdo sobre:
    • Importar tipos sin calificar frente a usar nombres totalmente calificados para mayor claridad.
    • El uso de mayúsculas/minúsculas en literales hexadecimales (la guía prefiere minúsculas) y otros pequeños ajustes de legibilidad.