Rust Style Guide

Original Article ↗ Hacker News Discussion ↗

Google’s new Rust style guide is prompting debate over whether strict human-oriented conventions still matter when large codebases are increasingly written and reviewed with help from AI. Many commenters argue that consistent APIs, crate structure, and patterns (like preferring enums over bools, small crates, and clear ownership vs. Rc/Arc) are even more important for readability, safety, and large-team coordination—especially in monorepos and distributed systems. The thread also widens into a broader argument about Rust’s role relative to C and C++, long-term maintainability in an AI-assisted world, and how much weight to give Google’s engineering guidelines today.

Role of Style Guides in an LLM/“Agentic” Era

  • Some argue style guides are less relevant because code will be LLM‑generated and mostly read via AI explanations, not directly by humans.
  • Others strongly counter that:
    • Style still matters for readability, long‑term maintenance, and cross‑team work.
    • Consistent API and implementation design are useful regardless of who writes the code.
    • In an “agentic” world, clear rules help humans meaningfully review and control AI output.
  • A few report giving style guides to LLMs; models don’t always follow them, and manual enforcement is hard without strong authority or automated linters.

Rust vs C/C++ and the Future

  • Debate over whether new C/C++ is still being written:
    • Many say yes: defense, embedded, HPC, games, big existing codebases, and major projects still heavily use C/C++.
    • Others claim Rust is “eating” C/C++, especially for security‑sensitive and new greenfield systems, with some companies “all in” on Rust.
  • Counter‑arguments:
    • Ecosystems (e.g., game dev) will take many years to move, if they ever do.
    • Certain domains (extreme performance, data‑oriented designs) may find Rust’s borrow checker ergonomically costly compared with C++.
    • Some believe LLMs will make language choice less important, or even relegate Rust to an intermediate representation.

Specific Style Rules Under Debate

  • Enums vs bools: Widely liked; enums narrow interpretation and prevent confusing flags.
  • Rc/Arc vs lifetimes:
    • One camp: use Rc/Arc freely for data escaping the stack; lifetimes are “weird.”
    • Other camp: shared ownership obscures who owns what; lifetimes are clearer and Rc/Arc should be reserved for genuine sharing needs.
  • Getters/setters naming:
    • Guide prefers bare method names for getters and set_/builder‑style for setters, aligning with Rust stdlib/protos.
    • Some prefer the opposite for fluency and consistency in UI/TUI builder‑like APIs.
  • #[non_exhaustive] enums:
    • Critics: undermines exhaustiveness checking and turns compile‑time safety into runtime bugs.
    • Supporters (especially at “Google scale” and in distributed systems): necessary for API evolution and avoiding massive breaking changes across many teams; combined with lints to flag omitted patterns.

Google/Chromium‑Specific Practices

  • Preference for many small crates and avoiding deep module nesting:
    • Rationale: faster, more parallelizable builds; finer‑grained dependencies; better cacheability with Blaze/Bazel (no incremental crate compilation).
  • Discouraging async/await in Chromium Rust for now.
  • Emphasis on distinguishing library vs application code and on rules that are uniformly applicable at large‑company scale, even if not always “ideal” for small projects.

Tooling and Naming Details

  • rustfmt exists but the guide covers broader design/style concerns.
  • Some disagreement on:
    • Importing types unqualified vs using fully‑qualified names for clarity.
    • Hex literal letter case (guide prefers lowercase) and other minor readability tweaks.