Seems very much like your goal was to rain on a parade.

Not trying to rain on someone's parade, but the only reason I would care about HN comments nowadays is to feed them to my model of choice and let it generate the contrarian hot takes it's supposed to be generating. So it's not like I am willing to read through this thread and think to myself "I cannot wait to pick up some new ways of complaining about documentation." I'm the Editor-in-Chief to my synthetic pundit army now.

I guess you would type out a comment manually every now and then for your own enjoyment, but at that point do you really care about comments at scale?

---

EDIT (above is a joke) It's very important that every time you find something that is of no use to you, you write a comment explaining that this link is of no interest to you, discouraging people from things you have no interest in. Monoculture for all!

What have you produced with your agentic army? Would you like to share with the class?

The point of style guides is to optimize for readability despite a cognitively diverse workforce coding in the same repos.

I would think they're probably even more meaningful in an agentic world.

Shitty generals can't review meaningfully review the work of their troops.

On top of that all, I just enjoy programming itself. It's less and less of the meat of a software job over time, but I was coding before I got paid for it, and I'll probably keep coding well after I can get paid for it.

First paragraph: “includes guidance on API and implementation design”

It seems to me that if the intent is not just to produce code but also to operate it, having the different pieces behave in a similar, predictable way is kind of nice. Whether the software is written by AI or humans.

I'm not sure I really agree with your main point (I think it's probably still important for LLM-generated code to be generally human-understandable, at least if you care about long-term maintainability), but setting that aside to answer this question:

I think they're still quite valuable in that case, for a couple reasons:

- When learning a new language (which happens much more frequently when writing code "for pleasure," as it were), "written for scale" guidelines still translate pretty well to "written for oneself" IME. At the very least, they tell you what to expect in code you read, and give you a reasonable starting point as you develop your own taste and stylistic preferences.

- I've noticed some open source projects beginning to institute anti-AI contribution guidelines, and such projects still benefit from codified style guides. Google obviously doesn't fall under this category themselves, but in other language ecosystems, their style guides tend to find use in OSS projects.

Are you saying that you don't ever look at the code once it's been generated?

This is what we do in my company, give the guidelines to the model. Unfortunately, the model isn't always following them and it's impossible to enforce them manually. There's too much code to review, the code is generally low quality, and is more often than not auto-approved by AI.

Unless you're working on your own project on which you have full control, or you have a strong authority figure in your company who cares about that, it's a lost battle.

It's sad for anyone who love their craft, but tbh I'm not even sure it matters anymore for most projects.

This is a sub-case of the general one that is narrowing the interpretation of things. A big infinite amount of things can be true or false, only one can be a Rust variant.

I've been extracting a lot of verified C from theorem provers recently.

C++ seems alive and well in the defense space. The big contractors near me have tons of C++ job postings and I don't think I've seen a single one looking for Rust.

Plenty of new C++ going on at my BigCorp employer.

I'm pretty sure most big software projects (Windows, Linux, Chrome, gcc, LLVM, AAA game engines, ...) are still writing a lot of new C and C++. Pretty much everyone in the embedded world is as well.

As a solo programmer, I still prefer C and C++. In fact, as I've incorporated LLMs in to my workflow, I've been increasingly drawn toward C and its simplicity. A lot of the QoL features of C++ simply aren't needed when you're writing less code manually.

C/C++ is still relevant for HPC, where you want to carefully optimize memory management.

Yes mine is, because they have a huge amount of C++ already and none of it is publicly accessible so security isn't a concern. (Obviously there are many other reasons to prefer Rust, but that is a big one.)

Far from it. Until Rust can read C++ code seamlessly, there will be more code written in C++ than Rust for the foreseeable future. HPC, Finance, AI, Games, Databases, Hardware all continue to be written in C++.

Today I went over a TODO comment from 2007 in a C++ codebase that is still evolving very vividly, year after year. Trust me, for well established projects C++ is there to stay.

Games, anything that depends on LLVM, GCC, CUDA, SYSCL,....

Ah and Rust's compiler backend dependency on LLVM and in the future GCC as well.

Unfortunately for me, yes. Some companies are very risk adverse and would rather stick with the devil they know. They have no idea what they are sacrificing.

Cloudflare is all in on Rust, it's used everywhere by default, and C++ leftovers are being actively torn down.

Rust is eating C/C++.

In a few years, Claude Mythos will be remembered as the moment C++ died. I am serious, very senior people are really scared of LLM found vulnerabilities and are pushing strongly for Rust.

Console/PC gaming is mostly C++ (and scripting/blueprints/etc).

I have been porting our Odin code to C(23) lately because it's better than anything else I've found in terms of language simplicity + tooling quality. 75% of our new code right now is C and in my estimation that'll be 100% in about a month, and we'll likely be done porting ~150 kLoC into a similarly sized C code base.

Even disregarding tooling I'm actually happier writing C than (even) Odin because it's really just a natural end state of changes I'd made to how I write code over the past 7-8 years and what I expect from a language (to not do much, and to not get in the way).

It's hard to compete with the tangibles of writing/using C:

- Somehow it has shorter compile times than everything else still, particularly for release builds?

- Everything that matters (to me) has C bindings.

- All the tools just work and they work well (and a lot of them are made specifically for C anyway).

- The compilation model is actually better, more straight forward and easier to make fast than languages that try to "fix" it, unless you sit there fighting it and overcomplicate it with overwrought build systems. (`make` is better than I used to give it credit for, though).

I think Ada is the only language that could peel my attention away from C at the moment, which is ironic given my "Don't do much, get out of my way" stance. It turns out you can do more if you're sensibly designed, have the right escape hatches and actually provide real, useful features (basically every feature regarding arrays in Ada and their interplay with other features like index types, etc.). Ada is not as easy to port from Odin, though, and Ada would be a much bigger gamble than C in so many ways. We don't mind writing the code we use ourselves (we in fact prefer it), but in Ada a lot of that code would be decidedly alien to how Ada seems to work in many ways.

With that said, I do have an Ada port of a game I was working on that does illustrate a lot of upsides. It's a different possible end state.

P.S. I've tried Zig, I wrote Zig for several years before I started using Odin, it's what got me back to imperative, small, native languages. It's what started this journey back to C.

Google probably, also lots of video game devs

Maybe one or two line functions are a totally different scale than "all source code files in a crate"? So like, one is problematic in a way the other is not. And the guidance is "prefer small," not "always super tiny." See: "Larger crates are allowed" later on. And also see: "Rationale: Fine-grained library targets are recommended in Chromium due to the massive size of our codebase, non-local effects of adding dependencies in the build graph, and to improve performance of parallel compilation and build caching."

Compilation speed?

It might have to do with optimizing compile times. A crate is the unit of compilation, so small crates increase the likelihood that you won't end up recompiling a lot of unrelated code.

I guess smaller crates and avoiding nested modules could also help optimize for making the code greppable by coding agents without blowing up context windows.

In Cargo-built Rust, a crate is costly in terms of abstraction because it needs its own directory, Cargo.toml, src/ subdir, etc. In the Google build systems I've worked with in the past (and it looks like Chromium follows) they instead put source files in the same directory mixing languages and with finer-grained libraries as they see fit.

Given that a crate is the unit of build parallelization in Rust, there's a benefit to more crates especially when they don't cost much cognitive overhead. You could imagine using crates in the way you'd typically use separate mods in a normal Rust project.

I dug around in their code search to find some examples but didn't see much Rust in there, seems still early. I think https://source.chromium.org/chromium/chromium/src/+/main:tes... has ~4 Rust files that end up separate crates though. (One of them defines a proc macro so even in a Cargo built Rust project it would need to be in its own separate crate, I think!)

The granularity of crates shouldn't really impact what kinds of abstractions you build. You can still have as many modules and types as you need, and as big of functions as you need, but its saying you should organize the modules into separate crates instead of one large crate. They even call out the trait coherence rules, saying that you can just make your library bigger instead of forcing a more awkward design in the pursuit of a smaller crate.

I think one benefit of small crates is that it gives you more granularity in linking and dependency graphs, which is especially relevant for rebuilds. At a previous job we had a monolithic "utilities" crate, and this caused problems when you tried to depend on it for the IP address utilities but this brought in the radio frequency utilities. When one of these submodules got an update the versioning would excessively propagate downstream to every consumer. If this was organized as small "net-utils" and "rf-utils" crates then maybe it would not have been as much of an issue.

This being Google, I assume everything goes into a single gigantic monorepo that gets thrown at Blaze. If the unit of compilation is the crate, it makes sense for them to prefer that crates are as small as possible.

You get stricter enforcement of public APIs and dependencies. You can't import anything you haven't declared as a dep, and cycles are impossible. Rustdoc by default shows only your intended public API.

OTOH if you have one crate with lots of modules, it's tempting to import anything anywhere and use pub(crate). Rustdoc needs to be configured to show private items if you want to see internal APIs.

Forces better code structure in my experience (ignoring orphan rule). modules can have dependency cycles and things get tangled together. crates disallow cycles.

blaze/bazel doesn't support incremental crate compilation. It also can't, by design, as incremental compilation depends on incremental change to local build artifacts which isn't deterministic.

So a single crate has to be as small as possible so builds are fast & cachable.

Their style is pervasive in Rust, such as in the standard library, so I would personally apply a when-in-rome philosophy. FWIW something like `.text("hello")` I would expect to see in a builder-pattern but not in a setter for an object that's already built.

That being said I don't particularly understand your conception of a method. They are both methods. The getter ought to have a shorter name since it is probably called more frequently and because it inherently has less of an impact -- this goes along with the principle that names that demand attention should be larger and easier to notice.

This style is aligned with protocol buffers, which is aligned with the style of protos in C++.

https://protobuf.dev/reference/rust/rust-generated/

I think which to use in general Rust code depends on the purpose of your type.

A builder type like `Command` will have unqualified setters and `get_` qualified getters.

For record-like-structs, I think unqualified getters becomes preferred and `set_` qualified setters.

I think using refcounting can allow you to get lazy with your object graphs, throwing referencing to objects around everywhere and then losing the ability to conceptualize who owns what and who is responsible for who (so to speak). Sticking to a stricter ownership graph forces you to be more deliberate with how your types are designed and this can lead to better architecture in the long run.

I find using lifetimes to be simpler and easier to follow than reference counting, unless you're in a situation where you actually need a shared lifetime.

Adding Rc/Arc is just another layer of indirection and noise that makes the code hard to read.

Agree. I think for the limited scopes such as in a mod/function, using Rust's borrow checker semantic makes sense as it is easier to fit in our mental model. If you have to pass those data structures around to the outside of your limited scopes, I would prefer Rc/ARc more. I also think the style guide has a catch all phrase there when it says "OK to use Rc/ARc depending on the complexity...". For me, having to pass a shared reference around is enough complexity to reason about.

But there's a rustfmt already. Anyway, the style guide is larger in scope than just code formatting.

It says below that that in cases of things like `io::Error` it should be used as that though, as in “cases of ambiguities”. It specifically speaks of not using `regex::Regex` but just `Regex` which seems more reasonable to me.

Honestly I think having blanket rules in either direction is a bad idea. Sometimes it makes sense to qualify things, sometimes it's clearer if you don't.

Having (hobby) worked with ObjectiveC/Cocoa and then later in Swift, I must say that although NSString looks ugly, it's glorious when it comes to trying to search for anything compared to String.

"This rule largely exists to avoid reviewer disagreements."

OT, but it was interesting. Some old typewriters didn't have a separate 1 a lower case L key. They had keys for the other numbers, but you were expected to just type a lower case L for 1.

Which companies would you look up to nowadays? Genuinely curious

The impression I got when I worked at Google is that most their stuff was state of the art in like 2008 at the latest. There's always something they excel in at some point in time, like TF 1.0, but they're behind on all the less hyped areas and keep saying NIH.

I 100% guarantee that this source of truth for this is either in google3 or git-on-borg and is being mirrored to GitHub for external use. There aren't a lot of public catch-all repos or public micro repos published by Google. Given that, GitHub is a reasonable choice.

Not useful at all. It uses up context. You need all the context you can get for the LLM read the code later for you later.

The corollary to your point is that you have to be extremely cautious what enums you make into public API if you want to be serious about backwards compatibility… likely wanting to include more flexible variants like “unknown” or “generic”, to make your API more flexible. But this ends up being the same problem by a different name, because it still turns things into runtime bugs, just like non-exhaustive enums do.

It’s the eternal struggle between flexibility and strictness that doesn’t really have a silver bullet answer. Or maybe it’s better framed as “flexibility, safety, backwards compatibility, pick any two”?

Sensible attitude for a one-team codebase, but much harder in a google3-sized megarepo…plus the policy matches protobuf enum semantics.

It's a double edged sword because without #[non_exhaustive], adding a variant becomes a major semver breaking change. It depends on your priorities. I think that there is probably a subtle difference between enums that are expected to gain variants in minor releases (a common example is error types) and enums that are expected to be closed (something like Option or SocketAddr).

Honestly what I tend to see is that most enums are not exposed publicly at all besides maybe error types and configuration options (where the user usually constructs but does not match on them). In both cases #[non_exhaustive] is valid. For all of the non-public enums you get to enjoy the compiler exhaustiveness enforcement.

Why? Their justification seems reasonable to me. If other teams depend on your enum then you could end up in two really bad cases. First is that you end up having to fix a ton of code just to update your enum, which has it's own headaches. Second is another team's build starts to fail when they update dependencies. Horrible churn to cause for your org. Better to just have them design around non_exhaustive.

It's usually not too hard to work around stuff like this - wrap it and map it to an exhaustive type, and use tests to ensure that your `unreachable!()` is correct.

This is from the people who make mandatory protobuf fields "optional".

I just fundamentally disagree with Google on how to evolve data structures. Sloppy open-domain protobuf field presence, enum values, whatever are illusory extension points. Better to have discrete versions of a data structure --- Foo1, Foo2, Foo3, etc., and rigid checking in each one than to have just one "Foo" with optional-everything that changes implicitly over time.

What people seem to be missing here is that enums are just a reflection of functionality. If you make your enum non exhaustive then add a field, and something stops working because it's now missing critical messages, it's still a breaking change!

It's always up to callers to decide to handle everything, or decide that additions are non-fatal and use a wildcard branch to ignore them. The same enum could need to be exhaustive for one use case, or subset matched by another.

FWIW this future lint `non_exhaustive_omitted_patterns` will help a bit: https://github.com/rust-lang/rust/issues/89554

At Google, the bottleneck is that a team changing a commonly used enum will not know how to update all the broken use sites, since it can be affecting dozens or hundreds of teams.

It is better to decouple the enum change from the use site change and let consuming teams update on their own schedule.

At scale, `#[non_exhaustive]` is the right default for public enums that are part of your API model when working on a distributed system. You should still be able to opt into exhaustive enums when needed but in practice it's way rarer.

I'm working at a company with a very large Rust codebase with thousands of endpoints. We use multiple repos and each service publishes its API as crates. A few years ago those were manually written and teams used exhaustive enums frequently in their API. It did not prevent runtime issues as older clients could receive responses with new variants from newer servers. It also made versioning painful because semver would dictate a major bump, but Rust's nominal typing means that types from different major versions get different identities, making it very inconvenient to integrate with these types (think shared helper functions, extension traits, ...). This caused people to release new variants in feature bumps and wreck havoc in the dependency tree by breaking compilation of intermediate libs.

Since then we switched to code generation from an IDL for the API model. I was leading this project and decided to produce non_exhaustive enums for the Rust code: it was 2 years ago and the situation drastically improved.

We have a CI step running lints with `non_exhaustive_omitted_patterns` mentionned in an other comment. That's the right approach for such a public API. The big difference is that is that warnings are local to the crate you're working on, so they're more actionable than errors.

This was all in the context of modeling the API of a distributed system. I still tend to use non_exhaustive more often now even for regular helper libraries. It always requires some thought as you need to plan for the forward compat of your code.

It's important to note that within the compilation unit where the enum is defined, a non_exhaustive enum doesn't require the catch-all arm when matching. In other words, this code compiles and checks for exhaustiveness as usual:

    #[non_exhaustive]
    enum Foo {
        Bar,
        Baz
    }
    
    fn main() {
        let foo = Foo::Bar;

        match foo {
            Foo::Bar => (),
            Foo::Baz => ()
            // no `_` arm necessary here
        }
    }

I agree with you, although other responders make good points.

Something I've been wanting in Typescript (and I guess it's the same thing here in Rust) is to type-check exhaustiveness of the known enum values, but also enforce that unknown values are handled. I've made utils for that but they're a bit awkward to use compared to native constructs like switch/case.

and even more interesting, how many that can't be enforced by a linter can be enforced by Typesafe's Jev?

I'm reminded of Rob Pike (one of the inventors of Go) saying "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."