--- title: Google's Rust Style Guide | daily.dev description: This is Google's style guide for writing Rust code across its codebases, including google3, Android, ChromeOS, Fuchsia, and Chrome. It covers API design,... canonical: https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Google's Rust Style Guide | daily.dev og:description: This is Google's style guide for writing Rust code across its codebases, including google3, Android, ChromeOS, Fuchsia, and Chrome. It covers API design,... og:url: https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm og:image: https://api.daily.dev/og/posts/uoc0KUidm.png og:image:alt: Google's Rust Style Guide og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Google's Rust Style Guide **[Hacker News](https://daily.dev/sources/hn)** · 32 min read · 4 upvotes · 2 comments ## Summary This is Google's style guide for writing Rust code across its codebases, including google3, Android, ChromeOS, Fuchsia, and Chrome. It covers API design, module and crate organization, naming conventions, error handling, and documentation practices. Specific rules include preferring unique ownership over Rc/Arc, avoiding dyn Trait in libraries in favor of generics, marking public enums and structs #[non_exhaustive], and preferring expect over unwrap. Chromium code must not use async/.await, and panic::catch_unwind is prohibited in first-party code. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Should I use Rc or Arc for ownership in Rust, or prefer borrowing? Prefer unique ownership and borrowing over Rc and Arc for managing memory in Rust. Rc and Arc add runtime overhead and their own complexity, and engineers coming from other languages may reach for them too quickly. An exception applies when the alternative ownership and borrowing structure would be unreasonably complex to write, understand, or maintain, which should be a judgment call made during code review. _daily.dev surfaces style guidance like this for developers settling Rust ownership debates on real codebases._ ### Why does Chromium disallow async/await in its Rust code? Chromium's Rust style guide states that async/.await should not be used in Chromium code, instead preferring to use sequences over threads. The guide does not give further justification for this specific restriction beyond this directive in the Chromium-specific section of the style rules. _teams adopting Rust in Chromium-style codebases can track such platform-specific constraints via daily.dev._ ### When should I use Option versus Result versus panic! for error handling in Rust? Use Option for simple failures where the cause is obvious and the caller wouldn't benefit from further detail, like integer overflow in checked_add. Use Result for recoverable failures where the caller needs context, such as io::Error from open_file, distinguishing NotFound from PermissionDenied. Use panic! to report bugs and violated invariants, such as an out-of-bounds index, since these indicate defects that must be fixed in code, not handled at runtime. _developers deciding on Rust error-handling patterns can keep style references like this handy on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 139 comments across hackernews, lobsters (as of 2026-10-22). **TL;DR:** Most of the discussion drifts away from the style guide itself into a broader argument about whether Rust is actually used in production versus C/C++, while a smaller thread digs into specific style choices like small crate sizes, getters/setters conventions, and Rc/Arc usage. **Sentiment:** 20% positive · 45% mixed · 35% skeptical **The case for** - Some find the enum-over-bool guidance genuinely useful for avoiding boolean-flag bugs. - Small, fine-grained crates are seen as helping incremental build caching and enforcing stricter public API boundaries. - The getter/setter and qualified-import conventions are viewed as reasonable defaults that reduce namespace noise. **The pushback** - Many argue Rust's real-world production footprint is still tiny compared to C/C++, making the premise of a big-vendor style guide feel overstated to some. - Several think the preference for many tiny crates over few larger ones is awkward outside Google's internal build tooling and conflicts with normal Cargo-based workflows. - Disagreement over discouraging Rc/Arc in favor of lifetimes, with some saying shared ownership is often simpler for data that outlives the call stack. - Skepticism that style guides matter much anymore given increasing reliance on LLM-generated code. **By community** - hackernews (heated): The thread is dominated by a contentious tangent on whether Rust is a 'real' production language versus C/C++, alongside sharper but calmer debates over specific style rules like crate granularity and Rc/Arc usage. - lobsters (mixed): A smaller, more technical discussion that pushes back on the small-crate-size recommendation while acknowledging it may make sense for Google's specific build system. **Hottest debate:** Whether Rust has achieved meaningful real-world production adoption compared to C/C++, which consumed most of the debate energy. **Open questions** - Does the small-crate-per-file guidance make sense outside Google's internal Blaze/Bazel-style build tooling, e.g. for Cargo-based projects? - How much do style guides matter going forward if more code is LLM-generated rather than hand-written? **Highlights** > You have a point but it's just hyperbole in the other direction. Yes, Rust is only a small fraction of the code in use every day, but it has nonetheless achieved deep penetration into critical infrastructure. Cloudflare's network routing code is predominantly Rust. Massive parts of AWS and Azure are Rust (including crown jewels like S3 and Lambda). Multiple car manufacturers have shipping Rust code in their production cars for years, albeit yes it's a slow process intoroducing it into regulated industries. Airbus and Boeing are putting up job openings for Rust development. As mentioned critical pieces of Windows and Android are now written in Rust. If you use Discord - that's Rust. If you use Amazon Prime Video or Disney+, that's Rust. I could go on. When like 40% of internet traffic and 75% of end user devices are using Rust in some capacity, to say that it's "not production" is just ignorant, arrogant nonsense. > — [dralley on hackernews](https://news.ycombinator.com/item?id=50190464) > I have a huge disagreement here. You should absolutely be using Arc and Rc for any references *that live outside of the call stack.* Don't do weird crap with lifetimes to try and convince the compiler that what you're doing is ok, just throw Rc/Arc on it and be done with it. The Rc/Arc advice also applies to C++ IMO, though you use different constructs, std::shared obviously, but there is a strong argument to be made for a std::shared_st or something which is single threaded. It would not surprise me if this advice comes from experience with C++ where there is no Rc so reference counting is very expensive. Even so, you can greatly reduce the expense by passing things by ref where lifetimes are simple which is the vast majority of the time. > — [slaymaker1907 on hackernews · 3 comments](https://news.ycombinator.com/item?id=50187239) > Can anyone expand on the chromium specifc guidelines on super tiny crates, particularly no nesting of modules/source files? That feels like the ~2010 era of people saying that functions should be as small as possible. That lead me to reviewing a lot of code where every function was one or two lines and you couldn't actually see what was going on anymore through the layers of unneeded abstraction. I want to give chrome the benefit of the doubt, but that seems really goofy. > — [monocasa on hackernews · 9 comments](https://news.ycombinator.com/item?id=50186755) > Getters and setters is the one I'm most at disagreement with. // Mine let label = Label.text("Hello Wold"); let label_text = label.get_text(); // Theirs let label = Label.set_text("Hello Wold"); let label_text = label.text(); A method is a way to accomplish a specific task. Emphasis on specific not generic. The getter task is to always return. The setter task is specific. So the method should be the setter - `text`, `color`, `fill`. In Rust the getter can't have same name, so prefix it. Not the other way around. > — [incrediblers on hackernews · 3 comments](https://news.ycombinator.com/item?id=50187233) > I like to consider my Rust to be pretty stylish, but there are definitely recommendations here I could implement. For instance, I tend towards complicated iterator chains when a for loop is easier to read, and I'm guilty of putting iterator combinators in loop headers. I think I'm a point-free Haskeller at heart :) I disagree with Google about crate size, though. Maybe it's more ergonomic with Google's internal build tooling, but with Cargo I would definitely rather crates contain more than a few `.rs` files if the complexity is warranted. Tbf, this section seems to only apply to Chrome, and I know nothing about their build system. > — [novedevo on lobsters · 1 points, 2 comments](https://lobste.rs/s/9jgl3x/google_s_rust_style_guide#c_yrtxmg) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50186010) · 233 points · 132 comments - [lobsters](https://lobste.rs/s/9jgl3x/google_s_rust_style_guide) · 23 points · 7 comments ## Community discussion Top comments from developers on daily.dev. **@pdfopsdev** · 0 upvotes > expect over unwrap is good advice but only if people actually write a message that explains the invariant, not just slap expect("x") everywhere to satisfy a linter. the non_exhaustive default for public enums is the one I wish more crates outside google adopted, saved me from a few breaking changes that shouldn't have been breaking. **@dani\_akash\_** · 0 upvotes > created a neat little prompt on how to adopt this into existing rust projects > > [https://daniakash.github.io/Google-Rust-Style-Guide/](https://daniakash.github.io/Google-Rust-Style-Guide/) ## Similar posts on daily.dev - [Guideline: Rust Style](https://daily.dev/posts/guideline-rust-style-rxs5ftv9c) · Lobsters · 4 upvotes · 0 comments - [Practical Rust API Design](https://daily.dev/posts/practical-rust-api-design-qwmqrnfyi) · corrode · 51 upvotes · 7 comments - [Rust vision group seeks enumeration of language design goals](https://daily.dev/posts/rust-vision-group-seeks-enumeration-of-language-design-goals-qzq4ehofk) · InfoWorld · 0 upvotes · 0 comments --- Tags: [#google](https://daily.dev/tags/google), [#architecture](https://daily.dev/tags/architecture), [#rust](https://daily.dev/tags/rust) [View this post on daily.dev](https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Google's Rust Style Guide","url":"https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm"},"datePublished":"2026-10-21T20:43:07.717Z","dateModified":"2026-10-22T03:26:44.905Z","description":"This is Google's style guide for writing Rust code across its codebases, including google3, Android, ChromeOS, Fuchsia, and Chrome. It covers API design,...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"google,architecture,rust","timeRequired":"PT32M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Google's Rust Style Guide"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm","comment":[{"@type":"Comment","text":"expect over unwrap is good advice but only if people actually write a message that explains the invariant, not just slap expect(“x”) everywhere to satisfy a linter. the non_exhaustive default for public enums is the one I wish more crates outside google adopted, saved me from a few breaking changes that shouldn’t have been breaking.","datePublished":"2026-10-23T18:03:53.422Z","url":"https://daily.dev/posts/uoc0KUidm#c-FNfMmk0HR","author":{"@type":"Person","name":"PDFops","url":"https://daily.dev/pdfopsdev","image":"https://media.daily.dev/image/upload/s---8isRBKc--/f_auto/v1782922291/avatars/avatar_orjMeK8QKaaVZwGq7ScPz?_a=BAMAMicg0"}},{"@type":"Comment","text":"created a neat little prompt on how to adopt this into existing rust projects\nhttps://daniakash.github.io/Google-Rust-Style-Guide/","datePublished":"2026-10-23T06:57:03.532Z","url":"https://daily.dev/posts/uoc0KUidm#c-lVpfEfNit","author":{"@type":"Person","name":"Dani Akash","url":"https://daily.dev/dani_akash_","image":"https://avatars3.githubusercontent.com/u/6841445?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/google-s-rust-style-guide-uoc0kuidm#faq","mainEntity":[{"@type":"Question","name":"Should I use Rc or Arc for ownership in Rust, or prefer borrowing?","acceptedAnswer":{"@type":"Answer","text":"Prefer unique ownership and borrowing over Rc and Arc for managing memory in Rust. Rc and Arc add runtime overhead and their own complexity, and engineers coming from other languages may reach for them too quickly. An exception applies when the alternative ownership and borrowing structure would be unreasonably complex to write, understand, or maintain, which should be a judgment call made during code review. daily.dev surfaces style guidance like this for developers settling Rust ownership debates on real codebases."}},{"@type":"Question","name":"Why does Chromium disallow async/await in its Rust code?","acceptedAnswer":{"@type":"Answer","text":"Chromium's Rust style guide states that async/.await should not be used in Chromium code, instead preferring to use sequences over threads. The guide does not give further justification for this specific restriction beyond this directive in the Chromium-specific section of the style rules. teams adopting Rust in Chromium-style codebases can track such platform-specific constraints via daily.dev."}},{"@type":"Question","name":"When should I use Option versus Result versus panic! for error handling in Rust?","acceptedAnswer":{"@type":"Answer","text":"Use Option for simple failures where the cause is obvious and the caller wouldn't benefit from further detail, like integer overflow in checked_add. Use Result for recoverable failures where the caller needs context, such as io::Error from open_file, distinguishing NotFound from PermissionDenied. Use panic! to report bugs and violated invariants, such as an out-of-bounds index, since these indicate defects that must be fixed in code, not handled at runtime. developers deciding on Rust error-handling patterns can keep style references like this handy on daily.dev."}}]} ```