Should Your Team Follow Google’s Rust Ban on Async?
Google’s Rust guide bans async/await and restricts std threads, and your team wants to adopt it wholesale. Which of its rules were written for your kind of project?
- The guide’s async/await ban is scoped to Chromium, not every Rust project.
- Threading and synchronization rules also carry codebase labels, while library and application API guidance has different force.
- Turn relevant rules into a combination of design review, rustfmt checks and individually selected Clippy lints.
The codebase label is part of the rule
Google's Rust Style Guide, recently shared on GeekNews, governs Rust usage at Google. Several restrictions name a particular codebase:
| Rule | Scope |
|---|---|
| No async/await | Chromium |
| No new threads through the standard library; prefer sequences | Chromium |
| Use fuchsia_sync::Mutex | Fuchsia |
The guide also distinguishes binding library API rules from strong recommendations for applications, where simplicity matters. These are not blanket language restrictions for unrelated Rust projects.
A call should reveal what its arguments mean
The Rust API Guidelines recommend meaningful types in place of ambiguous arguments. A boolean tells you which of two values was selected, but may say little about the choice itself.
For an illustrative save operation, compare save(true, false) with save(Overwrite::Allow, Backup::Skip). The second makes the intended choices visible. This is an explanatory example; the types a real API needs depend on the choices it exposes.
The guidelines also demonstrate separate newtypes for miles and kilometers. Both can contain a number, while their distinct types prevent a caller from silently passing one unit where the other is expected. The compiler can require an explicit conversion.
Formatting checks settle formatting questions
For a Cargo project, rustfmt supports cargo fmt -- --check. It reports differences and returns a failing status when formatting changes are needed; no required changes produces a successful status. That makes it suitable for a CI formatting gate.
This says nothing about whether a function has the right responsibility or whether an argument deserves its own type. Those remain review decisions. The formatter also documents limitations around areas including macros and comments, so its formatting guarantees have a defined scope.
More restrictions do not automatically make a better policy
According to the Clippy usage guide, cargo clippy runs the default lint set. Optional groups change that policy. The more opinionated pedantic group can flag intentional code and may need local exceptions.
The restriction group needs individual selection. Clippy explicitly advises against enabling the whole group: some rules can conflict with other lints. Choose the patterns your team intends to prohibit and enable the corresponding checks.
Frequently asked questions
Does passing cargo fmt validate an API?
No. It establishes that no formatting change is needed. Argument meaning and function boundaries still require review.
Should a strict project enable all restriction lints?
Clippy recommends selecting individual restrictions instead of enabling that entire group.
For each adopted rule, record its scope, how it is checked and which exceptions are acceptable. That gives a team a usable policy instead of a copied list of prohibitions.