Google has published a comprehensive Rust style guide that governs usage across google3, Android, ChromeOS, Fuchsia, and Chrome. On the surface it reads like a formatting document. Underneath, it is an infrastructure manifesto: every rule is shaped by the requirement that code must be machine-refactorable at planetary scale through Large-Scale Changes (LSCs). The guide's five stated goals are revealing in their ordering. Readability and maintainability over writeability comes first. Automation-friendliness comes second. Ecosystem consistency is third. Weight-pulling — every rule must justify its cognitive tax — is fourth. Resolving bikeshed disputes is last and explicitly minimized. This is a style guide written by people who have been burned by ambiguity at scale, not by people optimizing for developer happiness in the small. Architecturally, the guide makes strong bets. It mandates small crates in Chromium, flat file layouts (deliberately breaking Cargo convention), no glob imports, no async/await in Chrome, no spawning threads via the standard library, and avoidance of Rc/Arc in favor of borrows. Each of these trades developer convenience for mechanical predictability. A codemod tool can rewrite a flat, single-directory crate far more reliably than one with nested module trees and glob re-exports. The API design section draws a clean line between library code (rules are binding) and application code (strong recommendation, favor simplicity). This distinction acknowledges a real tension: library APIs in a monorepo are load-bearing infrastructure used by thousands of downstream consumers, while application code is local and disposable. The guide explicitly warns against premature generalization in application code — a rare admission from a company that loves abstraction. Notable specifics: prefer enum over bool in APIs, implement standard library traits instead of custom methods, pair From impls with explicit constructors, apply #[nonexhaustive] to public enums and structs, prefer pattern matching over check-then-unwrap, use expect over unwrap with context strings. These are not aesthetic preferences — they are defenses against the failure modes that emerge when thousands of engineers touch the same codebase: opaque booleans in call sites, missing trait implementations discovered at LSC time, exhaustive matches that break on new variants. The concurrency section is the most opinionated. No async/await in Chrome, no std::thread spawning in Chrome, use fuchsiasync::Mutex on Fuchsia — these are hard constraints driven by platform-specific runtime requirements. They signal that Google treats Rust concurrency as a platform concern, not a language concern, and wants the style guide to enforce platform-appropriate primitives rather than leaving it to developer judgment. What this guide reveals about Google's Rust strategy is more important than any individual rule. Rust at Google is not a grassroots developer movement — it is a managed infrastructure investment where code consistency, tooling compatibility, and refactorability at scale are first-order design constraints. The guide is generous to the broader Rust ecosystem (follow public rules where they don't conflict) but unapologetic about diverging when Google's scale demands it.
