First screen, captured 4 days ago.

Rust Style Guide

What HN thinks

A style guide about Rust conventions, debated mostly as a referendum on whether Google-scale problems are your problems, with a long detour into whether C++ is dead yet.

non_exhaustive enums sacrifice compile checks
Many argue marking public enums #[non_exhaustive] throws away Rust's exhaustiveness checking and turns missed cases into runtime bugs.
At scale, forward compatibility wins
Others, citing monorepos and distributed systems, say breaking dozens of downstream teams on every variant addition is worse, and lints like non_exhaustive_omitted_patterns recover much of the safety.
Google rules fit Google
Several note the guide optimises for uniform application across huge teams and build systems like Bazel, explaining small crates and import rules, not for personal preference.

Consensus: Most agree the guidance reflects Google-scale constraints and that the right choice on enums and crate size depends on whether you control all consumers; there is no consensus on whether that applies to everyone else.

Recommended in the comments

rust-analyzer (tool): Its prefer_underscore_import attribute makes extension traits auto-import as `_`.
pyxis ↗ (tool): Suggested for matching existing C++ memory layouts from Rust.
Miri (tool): Cited as stronger verification of unsafe code than C++ sanitizers.

Summarised by Claude from the comment thread 3 days ago.

Points: 359
Comments: 249
Best rank: #3
Posted: 2026-10-21 by kaycebasques
Category: Programming

rust style-guide google coding-conventions chromium android fuchsia

All captures:

Full page

Captured 4 days ago. Click for the whole screenshot. The page is longer than 12,000px, so the screenshot stops there: read the rest on google.github.io ↗