Google Standardizes Enterprise Rust Practices Across Monorepos and Client Platforms

Google has established a formal Rust Style Guide targeting systems code across Android, Chromium, Fuchsia, ChromeOS, and internal google3 repositories. The guidance balances standard ecosystem conventions against corporate build mechanics, explicitly prioritizing automated refactoring and compile-time isolation.

Core Objectives and Scope

Google's formal Rust Style Guide governs language usage across core infrastructure and client platforms, including `google3`, Android, ChromeOS, Fuchsia, and Chromium. While code formatting defaults to `rustfmt`, the style guide codifies binding rules for library APIs and strong recommendations for application logic.

The guidance is structured around supporting Large-Scale Changes (LSCs), which are automated, codebase-spanning refactorings common in Google's monorepos. To ensure tooling can reliably parse and modify code, style rules prioritize readability and maintainability over initial authoring speed. Divergence from the upstream Rust ecosystem is intentionally minimized to reduce developer cognitive load while maintaining deterministic build targets.

Crate Layout and Module Architecture

Crate boundaries in client codebases like Chromium are tightly coupled to build system rules (`rust_static_library`). The guide mandates small, fine-grained crates, often consisting of a single source file exposing a single abstraction. Fine-grained targets isolate the build graph, maximize parallel compilation, and improve build caching efficiency.

Chromium explicitly diverges from standard Cargo layout conventions. Sources belonging to a single `rust_library` must reside in a flat directory layout without nested module subdirectories. If a crate requires nested directories for file organization, it is considered oversized and must be partitioned into separate crates. An exception is made only for external dependencies located in `//third_party`.

Module organization demands strict isolation. Leaf modules and source files must be named after their primary user-defined item, and non-leaf modules must not contain API implementations. Import hygiene bans glob imports, restricts each `use` statement to items from a single module, requires qualifying top-level functions at the call site, and mandates importing type names unqualified.

Concurrency and Platform Constraints

Platform environments enforce strict constraints on execution and concurrency models. Within Chromium targets, developers are prohibited from using `async` / `.await` syntax and cannot spawn new threads through the Rust standard library. Systems code targeted at Fuchsia must use `fuchsia_sync::Mutex` for synchronization rather than standard library equivalents.

Across all platforms, running code prior to `main()` via static initialization hooks is prohibited. For runtime unwinding and interop safety, calling `panic::catch_unwind` is forbidden, ensuring uniform panic behavior across language boundaries.

Type Design and Implementation Mechanics

API design rules favor explicit type semantics over implicit convenience. The guide instructs engineers to avoid `Rc` and `Arc` smart pointers unless shared ownership is strictly required, favoring stack borrows over deep copy operations. Function signatures must accept flexible references for immutable data and prefer explicit `enum` types over booleans to clarify parameter semantics.

To preserve ABI and source compatibility during automated refactorings, public enums and structs with public fields must carry the `#[non_exhaustive]` attribute. Functions and types with actionable return values must be annotated with `#[must_use]`.

Implementation guidance mandates clear failure modes and predictable control flow. Code must prefer `expect` over `unwrap` to supply contextual assertion strings. Developers are directed to avoid excessive type inference, avoid checking condition states before unwrapping, and replace complex iterator combinator chains with direct loops whenever doing so improves readability.