Technical article · Rust · Software engineering · Code review
Introduction
Google's Rust Style Guide is a set of guidelines for writing Rust code that is readable, consistent, maintainable and suited to large-scale projects. It is not limited to formatting: it covers module organization, API design, ownership, borrowing, concurrency, macros, documentation, testing and error handling. [[1]](https://google.github.io/styleguide/rustguide.html)
The document's defining feature is that it treats style as a matter of software engineering rather than of aesthetic preference. Its aim is to reduce ambiguity in reviews, ease maintenance and enable automated changes across large codebases.
My assessment is that the guide offers valuable recommendations for professional projects, but it must be read in context. Some rules reflect good practices broadly applicable to the Rust ecosystem; others respond to the particular needs of Google's infrastructure, build tooling and internal processes.
Core principles and recommendations
Readability and maintainability over immediate convenience
Google favours code that is easy to understand and modify, even when this demands a little more work during implementation. The idea is that the extra cost of writing explicit code can be repaid by fewer bugs, faster reviews and less maintenance effort.
This orientation matters especially for systems maintained by teams over many years. Readability, however, does not necessarily mean writing more code: a well-chosen abstraction can be clearer than a long sequence of statements.
Modular organization and explicit dependencies
The guide recommends modules with identifiable responsibilities, small crates where this makes sense, and explicit imports, avoiding indiscriminate use of use ...::*.
The intent is to make definitions easy to locate and the origin of symbols easy to identify. It also helps search and refactoring tools behave predictably.
The caveat is that excessive modularization can fragment a project and create artificial dependencies. The division should follow the conceptual boundaries of the system, not simply produce as many crates as possible.
Ownership and borrowing as design foundations
The document encourages references and borrows instead of unnecessary deep copies, and recommends avoiding Rc and Arc when conventional ownership and borrowing suffice. [[1]](https://google.github.io/styleguide/rustguide.html)
These recommendations exploit one of Rust's main strengths: representing the ownership and sharing of data explicitly, so that the compiler can rule out many classes of memory errors.
It is important, however, not to turn these guidelines into dogma. Arc, Rc and clone() are legitimate tools when they simplify the ownership model or meet concurrency and performance requirements. The guide itself admits exceptions when the alternative would be excessively complex.
Generic, expressive and safe APIs
Google favours interfaces that express the programmer's intent and impose no unnecessary constraints on the API's consumers.
| Recommendation | Example | Expected benefit |
|---|---|---|
| Accept flexible references | &str instead of &String | Accepts more forms of data without requiring ownership |
| Prefer semantically distinct types | Newtypes instead of plain aliases | Reduces confusion between values represented by the same primitive type |
| Use named fields | struct Point { x: i32, y: i32 } | Makes data clearer than positional tuples |
| Prefer enum to bool in APIs with alternatives | Mode::Read or Mode::Write | Makes the intent of the call explicit |
| Use pattern matching | match | Exposes the handled cases and the error paths |
These practices are particularly useful in public libraries, where interface decisions can affect many projects. For internal applications, Google itself recommends avoiding premature generalization and prioritizing simplicity and directness. [[1]](https://google.github.io/styleguide/rustguide.html)
Error handling and defensive code
The guide favours error messages that provide context, recommends expect() where an invariant condition should be made explicit, and discourages indiscriminate use of unwrap().
It also advises preferring match to checking a condition and then calling unwrap(), so that the check is not separated from the operation that depends on it.
The merit of this approach is that it makes the program's assumptions visible. Yet mechanically replacing every unwrap() with expect() does not solve the underlying problem: one must decide whether the situation is a recoverable error, a programming fault or a genuinely impossible condition.
Automation, macros and concurrency
The document favours automatic formatting tools, discourages macros when ordinary functions and types suffice, and requires technical justification for unsafe code. It also contains rules specific to particular codebases, such as Chromium and Fuchsia. [[1]](https://google.github.io/styleguide/rustguide.html)
These directions must be distinguished from the general recommendations of the language. For example, the ban on async/.await and the preference for sequences over new threads are explicitly marked as Chromium-specific rules, not as universal prohibitions in Rust.
The distinction is essential: copying the rules without their conditions of application can lead to poor decisions in networked applications, asynchronous servers or systems built on a different execution model.
The Rust community's view and the main criticisms
The guide's publication also sparked discussion among developers. A Reddit thread in r/learnrust, posted on October 21, 2026, drew hundreds of votes and singled out precisely the recommendations that depart most from the ecosystem's usual conventions. The comments are useful for identifying points of debate, but they do not constitute a representative survey of the Rust community as a whole. [4]
What tends to be well received
There is significant convergence between Google's guide and Rust's general principles: readability, coherent APIs, useful documentation, memory safety and judicious use of abstraction.
Rust's own official style documentation makes readability a priority, including ease of reading in diffs, in compiler messages and in environments without syntax highlighting. This shows that Google's concern with maintainability is not peculiar to its engineering culture. [[2]](https://doc.rust-lang.org/style-guide/)
The community also has good reasons to value fewer subjective debates in code review. When a team agrees in advance on formatting, naming and API structure, it can focus reviews on the correctness, safety and architecture of the program.
Where the disagreements arise
Flat layout and small crates
The recommendation to avoid subdirectories for the files of a single crate in Chromium is among the most debatable. In smaller projects, it may simplify navigation and the build system. In large systems, however, hierarchical directories can naturally represent subsystems and functional domains.
Criticism: splitting a crate whenever its internal structure calls for subdirectories can turn an organizational decision into artificial fragmentation. The criterion should be cohesion, coupling and the compilation boundary, not merely the shape of the file tree. [[1]](https://google.github.io/styleguide/rustguide.html)
Restrictions on Rc and Arc
Avoiding unnecessary shared ownership is sound guidance. These types, however, solve real problems: shared object graphs, caches, shared state and concurrent structures.
Criticism: the choice between exclusive ownership, references and sharing should follow from the data model. An initial preference for borrows is sensible; a cultural rule that discourages sharing even when it best expresses the domain is not.
The async/.await ban in Chromium
This rule is explicitly Chromium-specific. It should not be read as a general recommendation for Rust applications.
Criticism: asynchronous ecosystems are widely used in servers, networking and input/output systems. A restriction may make sense when a project already has its own execution and scheduling model, but it does not transfer automatically to other systems. [[1]](https://google.github.io/styleguide/rustguide.html)
Preferring functions and types to macros
The guide draws attention to the costs of macros: they are harder to navigate, debug and refactor. The concern is legitimate.
Criticism: declarative and procedural macros also make it possible to implement abstractions that would be impractical or excessively repetitive with ordinary functions. Avoiding them by default is reasonable; treating them as a sign of poor engineering would not be.
Emphasis on expect(), unwrap() and failures
The guide seeks to make assumptions explicit and to reduce avoidable panics. This favours more useful diagnostics.
Criticism: expect() is not intrinsically safer than unwrap(). Safety depends on the error-handling policy, the validity of the invariants and the possibility of recovery. Swapping one call for the other without revisiting the logic mostly changes the message.
An important caveat: these criticisms are technical analyses of the rules and their possible effects, not claims that Rust developers at large reject the guide. The community debate identified highlights some of these disagreements, but does not allow support for or rejection of each recommendation to be quantified.
Consolidated technical assessment
| Criterion | Assessment |
|---|---|
| Readability and maintainability | Very well founded |
| Safety and ownership | Well founded, requiring contextual judgement |
| Public API design | Very useful for libraries |
| Automation and code review | Especially suited to large teams |
| Modular organization | Dependent on architecture and build system |
| Concurrency and asynchronous execution | Specific rules should not be generalized |
| Application to small projects | Requires simplification and adaptation |
The most important point is that the document brings together recommendations of different kinds: general engineering principles, API design choices, team conventions and operational constraints of specific projects. Applying all of them as a uniform set of mandatory rules would be a methodological error.
Conclusion
Google's Rust style guide is a useful reference for anyone seeking to raise the quality of a codebase, especially in large teams, shared libraries and projects with long maintenance cycles. Its merit lies in turning recurring engineering decisions into explicit conventions, easing automation and reducing unproductive disagreement in reviews.
The most relevant criticisms concern the risk of turning contextual preferences into universal rules. A flat layout may not suit every domain; shared ownership may be necessary; macros can offer superior abstractions; and restrictions on asynchronous programming depend on the system's architecture.
My recommendation is to adopt the guide as a reference, not as dogma. For an independent Rust project, I would start with rustfmt, the language's official conventions, the API recommendations and the principles of ownership and error handling. I would then incorporate Google-specific rules only where there is a concrete justification related to architecture, maintenance or the tools in use.
Ultimately, the best style is not the one that reproduces wholesale the culture of a company, however large. It is the one that makes code easier to understand, test, modify and operate without introducing unnecessary complexity.
References
- Google. Rust Style Guide. https://google.github.io/styleguide/rustguide.html.
- Rust Project. The Rust Style Guide. https://doc.rust-lang.org/style-guide/.
- Rust Project. Rust API Guidelines. https://rust-lang.github.io/api-guidelines/.
- r/learnrust community. Discussion of Google's style guide (October 2026).