Strong summary
Google’s newly public Rust Style Guide is worth reading, but it should not be copy-pasted into every team handbook. Google says the guide goes beyond formatting into API and implementation design, and it is meant to work alongside the official Rust Style Guide and Rust API Guidelines where they do not conflict. That matters because the biggest decisions are not aesthetic; they are about code ownership, API stability, unsafe-code discipline, and whether a large-company policy still fits a smaller Cargo project.
The right question is not “Is Google right?” It is “Which rules reduce friction in our codebase, and which rules would create unnecessary process, churn, or abstraction debt?” For many teams, the answer will be a selective adoption model: copy the high-signal guardrails, adapt the parts that depend on org structure, and reject the parts that would make your code harder to evolve.
What Google actually published
Google says Rust is used across google3, Android, ChromeOS, Fuchsia, and Chrome. The guide’s current scope also says Android, Chromium, and other codebases were consulted and intend to begin applying it, but each codebase may decide how strict to be. In other words, even inside Google this is not presented as a single universal enforcement model.
The page is also explicit that it follows the public Rust Style Guide and Rust API Guidelines where they do not conflict. That is an important clue: the Google version is not trying to replace the Rust ecosystem’s norms, but to add a company-scale policy layer on top of them.
The discussion around the guide on Hacker News is useful as demand evidence, but not as authority. Interest from a technical audience suggests people want to read it; it does not prove the rules are optimal for your team or for production outcomes.
8 decisions teams should make before adopting it
Use the table below as a policy checklist. The point is not to mirror Google’s defaults automatically, but to decide whether each rule matches your codebase, review culture, and release discipline.
- 1. Formatter and line-width policy — Google’s guide says to use the appropriate formatter. For style-guide authors it documents max_width = 100, while noting a codebase may skip options unavailable on its stable Rust toolchain. Why it helps: consistent diffs and fewer style arguments. When a non-Google team might choose differently: an existing repo standard, generated code, or stable-toolchain constraints. Adoption test: can CI apply the chosen policy with little churn and clearly documented exceptions?
- 2. Imports and glob-import exceptions — Google’s default: prefer explicit imports, with narrowly defined exceptions for glob imports when they improve clarity or reduce repetitive boilerplate. Why it helps: clearer dependencies and fewer name collisions. When a non-Google team might choose differently: utility crates, heavily namespaced modules, or pattern-heavy code where explicit imports become clutter. Adoption test: do review comments about imports decrease after standardization, or do developers spend more time managing import lists than reading code?
- 3. Ownership, Rc/Arc, and cloning — Google’s guide prefers unique ownership and borrowing over Rc/Arc, allowing reference counting when the alternative would be unreasonably complex. It also warns against using clone as a substitute for borrowing, while permitting pragmatic cloning when borrow relationships become excessive. Adoption test: does the rule expose real ownership without forcing harder-to-maintain designs?
- 4. Standard traits and defaults — Google’s guide favors standard-library trait implementations over look-alike custom methods, pairs important From implementations with discoverable constructors, and recommends Default for options structs. Why it helps: familiar APIs and less caller boilerplate. When a team might differ: experimental or domain-specific interfaces. Adoption test: can callers predict construction, conversion, and default behavior without project-specific lore?
- 5. #[non_exhaustive] for cross-team public enums/structs — Google’s default: use #[non_exhaustive] on public types that other teams consume so future variants or fields can be added without breaking downstream code. Why it helps: preserves forward compatibility and reduces semver pain. When a non-Google team might choose differently: internal-only APIs, closed-world binaries, or crates where exhaustive matching is a deliberate design signal. Adoption test: is the type consumed outside the owning team, and do you expect new variants or fields to appear often enough that backward compatibility matters more than exhaustive matching convenience?
- 6. Unsafe code isolation plus SAFETY comments and technical justification — Google’s default: isolate unsafe code, require SAFETY comments, and demand a technical explanation for why the unsafe block is sound. Why it helps: unsafe becomes reviewable engineering, not folklore. When a non-Google team might choose differently: very small teams may not need a heavyweight process, but they still need explicit justification. Adoption test: can a reviewer verify each unsafe block against a local invariant, or is the code relying on implicit knowledge no one wrote down?
- 7. Stable versus unstable features — Google’s default is explicit: do not use unstable features, with limited codebase-specific exceptions such as certain Android embedded needs and narrowly approved Chrome/Fuchsia cases. Why it helps: lower upgrade risk. When a non-Google team might differ: compiler experiments or controlled internal tools. Adoption test: is the benefit large enough to own breakage and migration if the feature changes?
- 8. Codebase-specific build and test rules — Google’s guide includes rules that are explicitly scoped to Chrome or Fuchsia, including test frameworks and some concurrency/build constraints. Why it helps there: integration with each codebase’s tooling. Why a non-Google team may differ: ordinary Cargo projects usually need simpler defaults. Adoption test: is the exception solving a measured build/test problem, or merely importing Google’s organizational context?
Staged adoption plan
- Inventory: map where Rust lives in your org, which crates are public, which are internal, and where unsafe code or shared ownership already appears.
- Decide: choose which of the eight rules become hard policy, soft guidance, or explicit exceptions.
- Automate: use rustfmt, linting, CI checks, and review templates so policy is enforced by tools where possible.
- Pilot: apply the draft policy to one representative service or library before rolling it out broadly.
- Measure review friction and build impact: track formatting churn, review comments, compile times, test times, and the number of policy exceptions requested.
- Document exceptions: record why a team departs from the default, who approved it, and when it should be revisited.
- Revisit: reassess after a release cycle, a major compiler upgrade, or a significant architecture change.
What not to copy blindly
Do not assume Google’s internal scale problems are your problems. Some rules exist because a company with many code owners, many downstream consumers, and many long-lived repositories needs guardrails that a smaller Rust project may not need. For example, #[non_exhaustive] is a strong compatibility tool when multiple teams consume a public API, but it can reduce exhaustive matching ergonomics in a small crate where the whole codebase is controlled by one team.
Do not treat a large-company build policy as a virtue by itself. A 100-column limit may be useful, but a smaller project can often get the same benefit with a simpler formatting standard or no width rule at all beyond rustfmt defaults. Likewise, a cautious stance on unstable features is sensible, but if your team’s mission depends on experimenting early, a strict stability rule may slow valid work.
Most importantly, do not confuse interest with evidence. Hacker News discussion shows that engineers care about the guide, but it does not tell you whether the guide will improve your team’s quality, velocity, or maintainability. That decision still requires local data.
Is Your Team Ready to Adopt Google's Rust Style Guide?
Source links
