Rendered at 21:29:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
japgolly 19 hours ago [-]
Apply #[non_exhaustive] to publicly-exposed enums seems like a crazy recommendation to me. So much of the power of enums is that when you add a new case the compiler will flag all pattern matches that you need to update, which is a good thing because you're forced to consider each case. Having a catch-all saves dev-time but it risks not appropriately handling new cases becoming a runtime issue instead of a compile time error.
demurgos 12 hours ago [-]
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.
infogulch 7 hours ago [-]
Same-binary / external service seems to be the split.
If you're building one binary you can choose when to update and fix all the referents at the same time. A distributed system does not have that luxury and it makes more sense to require forward compatibility.
I guess another option is a two-phase update where you first update all the services to accept the new enum variant without ever emitting it, then you can phase in services that use it. The downside with this strategy is that you're locked into upgrades and you can't roll back individual service versions, so to be safe you probably need to delay use of the new enum variant by 2-3 releases (at some point rolling back is not a viable option and you have to publish fixes in a new release anyway).
So in a service world the only options are either "require forward compatibility" or "delay rollout of a new feature to 3 release cycles after all services in distributed system are updated" which is like a month minimum. I can see why forward compatibility is the default, and also that you might want to keep the two-phase deployment strategy for certain cases.
techsystems 8 hours ago [-]
Interesting! Thanks for the share
i2talics 18 hours ago [-]
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.
hmry 9 hours ago [-]
Without #[non_exhaustive], adding a variant is always a semver breaking change.
With #[non_exhaustive], adding a variant is not a breaking change, but only if that variant can safely be ignored. If it can't be, then it's still a breaking change, BUT you don't get a compiler error. That's a very big drawback IMO.
This makes me think of how the PNG format handles this. For context, PNG files consist of a list of chunks of different types (image data, color profile, text comment, etc). Each chunk has some flag bits that tell you whether it can be safely ignored when decoding the image, safely retained when the image data is changed, etc. That way the decoder can ignore unknown ignorable chunks and error on unknown non-ignorable ones.
13 hours ago [-]
williamdclt 8 hours ago [-]
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.
ninkendo 18 hours ago [-]
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”?
rendaw 15 hours ago [-]
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.
alfiedotwtf 15 hours ago [-]
Adding a field and it stops compiling > adding a field and it stops working
froh 14 hours ago [-]
can't you explicitly express a catch-all in a check?
edit: I don't know rust. in other languages he's such catch all patterns exist and you have to either capture each possible value explicitly or you express "here in this fu, I take care of these and all others I do that..."
mort96 13 hours ago [-]
Yes you can, but if a new enum value appears, there's probably something you want to do in response which your default case didn't do.
galangalalgol 8 hours ago [-]
The suggestion seems to be for api changes where the api is generated from an idl. So proto or something. If my service was built several versions prior to that value being added then I by definition don't care about it. The catch all is fine. If other services care that I don't care, they can file a ticket. You could be nice and leave out the catch all and then the deserialization will panic or throw and error. And the mect CI pipeline where the new IDL gets used will fail to compile. Both ways it is a runtime error at first. If you don't require exhaustive at all, that just lets you persist the situation without migrating my old service to the new api... Non exhaustive is the one option I can't agree ever makes sense.
eptcyka 14 hours ago [-]
Swift gas a facility for this type of thing, Rust could adopt it too.
smallnamespace 12 hours ago [-]
> the compiler will flag all pattern matches that you need to update
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.
berkes 12 hours ago [-]
I am not familiar with this flag, but will it force, or at least alert these " consuming teams" that the enum they expected has changed?
smallnamespace 12 hours ago [-]
No, but Google already has internal tools that can identify use sites and email affected teams.
Note that teams generally manage their own deployments, so even a repo wide code change doesn’t force the update of an older deployed binary.
Sensible attitude for a one-team codebase, but much harder in a google3-sized megarepo…plus the policy matches protobuf enum semantics.
ekidd 10 hours ago [-]
I can't speak for Google-sized organizations, but Protobuf enum semantics are an invitation to broken, flaky and incorrect systems.
There are reasons why Google pays this price! But I think it's one of the worst practices for much smaller organizations to adopt.
quotemstr 16 hours ago [-]
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.
Groxx 16 hours ago [-]
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.
14 hours ago [-]
kibwen 8 hours ago [-]
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
}
}
The non_exhaustive attribute only applies to users outside of the compilation unit, because it's a tool for expressing a promise about the external API.
zeroCalories 17 hours ago [-]
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.
Pavilion2095 15 hours ago [-]
There is already a catch-all option if you don't need exhaustiveness in some part of your code.
zelphirkalt 15 hours ago [-]
The first one is not a "really bad case", but the intention of having a strict enum. You want to be force to update, in order to not miss any places, where the change could cause an error. That's the very benefit of it.
Second case is the same. The other team needs to definitely know, that their assumptions expressed in their current code are broken and need to be adjusted.
We just need to stop to take whatever shit Google is doing as the one bar to measure all others, and need to understand that they may be different requirements than a typical business. We are not Google.
zeroCalories 6 hours ago [-]
Those are horrible cases if you're anything more than a hobbyist.
I don't want to update every place someone matches on my enum, when it's something not even in my project, just to get my PR to merge. Three teams use it? Fine. Ten? More? Not fine. You are adding cases into someone else's code just to unblock your own work.
The second case is actually not the same at all. Realistically, they will just pin your dependency to an older version. Now they can't benefit from new features and security fixes without going in and adding in a new case. Massive waste of time for them.
And of course I'm not just taking whatever Google says at face value. I read their justification, and it makes total sense for anyone that works on a non-trivial project. It follows how any stable public API is supposed to be designed.
zelphirkalt 5 hours ago [-]
> I don't want to update every place someone matches on my enum, when it's something not even in my project, just to get my PR to merge. Three teams use it? Fine. Ten? More? Not fine. You are adding cases into someone else's code just to unblock your own work.
Then don't upgrade your dependency onto the other crate.
Anything more than a hobbyist will have properly pinned versions, and not just sling around version ranges loosely. At the very least will not update lock file just like that, without considering, that there may be consequences.
ragall 3 hours ago [-]
In any distributed system beyond toy size, forcing an update is not possible.
alfiedotwtf 15 hours ago [-]
> 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
If you really don’t care about compiler warnings, what’s the actual point of using Rust?
dathinab 8 hours ago [-]
Most important reading context:
- this are rules created to be (kinda/mostly) uniformly applied across all projects at a Google Scale company
Having used rust at work since roughly ~1.0 days I have come to a realization:
- the style guides which work best for "blindly uniformly applied across all kind of projects/teams/people" are not the same as "my preferred style" _in a lot of ways_
- similar they are often not "the best" in every case but they are "uniformly applicable without having to make opinionated decisions" i.e. they don't cause frictions in review or when writing the code due to "style only"-decision without a clear good answer
As a more generic example. There are a lot of frameworks/style guides which lead to related logic being split across 3+ small files in different folders instead of having related code "close together". And this can be a huge pain and isn't how I would manage personal projects. BUT putting code close together will sometimes just not work for various reasons (often shared logic/cross cutting concerns) at which point you will have to make some compromise where/how to place the code which has no simple "no brain used schema-f" solution you can blindly apply no matter what. This can lead to friction. Once too many people touch the same code this tend to become a huge mess, too. So the companies use style guides which split things apart. Even through the outcome is for all the simple cases noticeable worse to work with. As it does scale to large teams, very varying skill levels and many people working on the same code.
antonchekhov 6 hours ago [-]
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."
flossly 27 minutes ago [-]
Best part of Golang ihmo; first time I saw a language mandate it's formatting. Fast compiles are also nice, but not exclusive to Go (C, C++, OCaml, also compile fast).
I find it interesting that Google uses Rust. I know they work on Rust-based kernel code for Android. I'm curious to know if they also use it for networked application code, and why they picked it over Go.
Personally I prefer Rust over Go for it's types, and I never use it in big projects, so compile time does not bother me. But Google basically created Go for it's networked application code.
monocasa 1 days ago [-]
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.
evmar 1 days ago [-]
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!)
evmar 1 days ago [-]
It looks like there's some macro-based import that does import by path, so crate names are generated:
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.
i2talics 1 days ago [-]
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.
vvillena 1 days ago [-]
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.
loeg 1 days ago [-]
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."
hugmynutus 19 hours ago [-]
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.
pornel 24 hours ago [-]
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.
tcdent 24 hours ago [-]
Exactly. Being able to organize your code in a way that provides distinct responsibilities per crate is just good practice.
And then the ability to enforce a formalized layer between crates and the way that they assemble into your application (i.e. the public API) is powerful for comprehension and maintainability. I go as far as documenting each crate with its own README that presents it as a standalone component with usage instructions, much like an open source library, even if it's only ever used in a single system.
skavi 23 hours ago [-]
Forces better code structure in my experience (ignoring orphan rule). modules can have dependency cycles and things get tangled together. crates disallow cycles.
dnautics 1 days ago [-]
Compilation speed?
epage 1 days ago [-]
> Type names should be imported and used unqualified
This just pushes people to have redundant information in types (`IoError` instead of `io::Error`).
Unless a type is widely recognized (like `HashMap`), I prefer to have them fully qualified so I have the contextual meaning for it. If I am working with a generic name like `Source`, what does that mean? I shouldn't have to look up in the imports to understand the code (or only understand it through an LSP).
Reducing imports also reduces unnecessary merge conflicts.
egl2020 42 minutes ago [-]
"This rule largely exists to avoid reviewer disagreements."
Blikkentrekker 24 hours ago [-]
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.
B-Con 22 hours ago [-]
Google's style guides tend to reduce namespace redundancy.
Everyone remembers finding some hideous name like foo.widget.widgetBuilder.widgetFactory in Java or something. It's nice to have naming rules, or at least guidelines, focused on trimming redundancy and keeping the signal high.
cobbzilla 16 hours ago [-]
> some hideous name like foo.widget.widgetBuilder.widgetFactory in Java or something
That guideline is in response to an API design. I'm speaking to how the default stance (import types) feeds back into API design.
wtetzner 24 hours ago [-]
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.
boxed 14 hours ago [-]
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.
preommr 24 hours ago [-]
Google has lost a lot of it's sheen for me. It's not really the 2010s anymore where their brand really used to mean something as a step above all the other tech companies.
Nowadays, I care about their recommendations as much as the ones from microsoft, or ibm.
Still big companies, lots of smart people, but nothing above norm.
mahboi 1 hours ago [-]
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.
nsib96 17 hours ago [-]
Which companies would you look up to nowadays? Genuinely curious
mahboi 1 hours ago [-]
Cloudflare, OpenAI, Anthropic, and even Amazon each in its own way
yhavin 16 hours ago [-]
Deserves its own Ask HN.
chungus 13 hours ago [-]
I'll kick it off:
Oxide computing.
afdbcreid 22 hours ago [-]
Here's a tip most Rust users don't know about extension traits: if you put `#[rust_analyzer::prefer_underscore_import]` above your trait (and you're using rust-analyzer and not RustRover), autocompletion and the import assist will import the trait `as _` by default, which is very useful for extension traits.
tcallred 1 days ago [-]
I really appreciate that they distinguish between library code and application code. Rust gets too much of a bad rap for its complicated generic code, but in most application scenarios you are not writing code nearly that complex or generic.
petcat 1 days ago [-]
At this point, is anybody writing new C or C++? It seems like they are sunset languages even at the big corps.
fasterik 1 days ago [-]
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.
loeg 21 hours ago [-]
Using LLMs to write C feels a little silly to me. (Unless you really need C.) LLMs are still imperfect; you're still going to get a lot of UB bugs like human-authored C.
fasterik 19 minutes ago [-]
It's fine as long as you set up sane style guidelines (only allocate memory at init, always use explicit buffer lengths, etc.), and you have a mandatory test pass running with UBSan/ASan/Valgrind.
Groxx 16 hours ago [-]
Particularly because so much of the code they're trained on has those flaws.
anthk 22 hours ago [-]
Chrome should be ported to Rust long ago. on Windows, half of the UI can migrate tomorrow with ease.
boredatoms 20 hours ago [-]
With the ram shortage they could start by removing all the web-views that should have been native
pjmlp 15 hours ago [-]
Windows is more likely to keep being a mix of .NET and C++ than anything else.
Other than a few examples given in the past, the Rust adoption among WinDev doesn't seem to be really taking off like in Azure.
Indeed C# is getting more low level coding features, and the unsafe memory model is being redone in .NET 11 for a reason.
flossly 15 minutes ago [-]
Cannot really compare C# to Rust.
C# to me compares to Java and Kotlin (they have a large runtime or VM and implement GC).
Rust compares to C, C++, Zig or Odin (compile to native, memory is more self-managed).
anthk 10 hours ago [-]
Yes and No. Tons of core C++ Windows stuff will be Rust based. C# will be more suited for some control panel/configuration settings where the performance won't matter much, as they are seldomly used. The rest will be pretty much Rust instead of C++.
pjmlp 6 hours ago [-]
That isn't what many reports assert, in fact the roadmap for Visual Studio is being the best C# and C++ plus AI IDE, see latest roadmap announcements for VS 2027.
Apparently outside WinUI efforts, that many don't care about, there isn't much going on, the Rust action is all on Azure side.
anthk 6 hours ago [-]
OFC C# it's tied to VS, it's basically the platform. And, still, Windows internals rewritten in Rust are the best bet. Even the IDE being rewritten in Rust would outperform C# in speed while giving more security.
Rust for systems programming, C# for non-performing bound tasks (control panels, launchers, light gaming, GUI's on top of Windows CLI tools) and C++ for raw performance. And, still, I won't let any modern codec for A/V to be written in C/C++ for obvious reasons. And I am a diehard Unix+C user in the infamous N270 netbook. but dark times with automatic AI attacks are comming ahead. That's why I migrated from Mutt to Aerc, while keeping my Maildir and msmtp/isync.
At least I will be able to reencode potential harmful media for 420p/720@30FPS for the netbook in the NUC if FFMPEG (or FFMPEG based tools) were converted into Rust without hitting several vulns, because they will be everywhere:
- qemu/libvirt
- imagemagick/graphicsmagick, both the tools and libraries
- any libav* codec/parser
- libpng/libgif and similar
- zip/7z/tar/pax
- PS/PDF, of course. Especially PS, for obvious reasons.
- Some DOC/XLS formats pre DOCX are raw memory dumps and maybe they can be partially executed.
- Some other formats can act like a mini-VM bytecode too, such as RAR.
I even compiled Bubblewrap too so I can jail some of these, and yet I don't trust them 100%. Some recent exploits bypassed the chroot like nothing.
npalli 1 days ago [-]
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++.
simonask 22 hours ago [-]
Serious people in all of those industries are thinking about whether and how Rust is a fit for their needs.
Like, I agree that C++ will be around for a long while, but the writing is on the wall.
loeg 21 hours ago [-]
I agree momentum for Rust is growing, but disagree that it is obvious the writing is on the wall for C++. Like, Java and C# didn't kill C++, either. In all likelihood, these languages will all coexist for a long, long time.
afdbcreid 3 hours ago [-]
Java and C# did kill C++. They just did it only in places they were feasible. People forget that before them, it was very common to write application and even serve code in C++. Now Rust is targeting its remaining niche(s).
flossly 11 minutes ago [-]
Yes, at least Rust and Zig have answers for the remaining niches.
Rust's type system is making it's compile times bigger than C, C++ and Zig. This does keep it away from some code that's currently C or C++.
20k 22 hours ago [-]
For game development its hard to see how Rust can really replace C++ in practice. It'll take 15 years at minimum to replace the current development ecosystem for building games
simonask 11 hours ago [-]
Large game engines consist of many medium to large software libraries stitched together. What you're likely to see is that each such library is gradually either rewritten or replaced by Rust code, with an FFI compatibility layer matching the existing ABI where possible.
There's no reason to think that current game engines will have their fundamental APIs around scene management, serialization, entity composition, and so on, ported directly to Rust, because these things are typically designed around available language features. For example, an engine written in C++ might have its own version of `dynamic_cast` and RTTI, and that's going to be an extremely awkward design in any other language.
I think 15 years is too high, but I agree that it will be a while, because a triple-A game engine is a huge investment.
rudedogg 19 hours ago [-]
Also, the language just isn’t suited well to making games. Can anyone point me to a successful Rust game? Bevy game?
Successful as in they completed building the game, or successful as in lots of copies sold?
19 hours ago [-]
tonyhart7 21 hours ago [-]
"It'll take 15 years at minimum to replace the current development ecosystem for building games"
15 years of pre LLM or post LLM ?????
npalli 22 hours ago [-]
Strange position in 2026. If there is any writing in the wall it is this. Nobody is going to be writing Rust code from scratch given where LLMs are already now, much less in 5 years. A golden rule of software is fresh coding is a small part of the lifecycle most of it is maintenance. You may be able to get people to write Rust code (vibe code it), however a tiny minority of them will want to maintain LLM generated Rust code!! Rust will most likely be an intermediate representation - a security/formality check of sort - before converted into the appropriate heterogenous code across GPU/CPU/TPU/XPUs. Even there some other better representation will supplant it as Rust's ideas will be found too limiting. The idea that you as a programmer will sit and write Rust source code is just going to look very archaic. Thank god for LLMs for saving everyone just in time.
simonask 11 hours ago [-]
I keep seeing this take, but oddly only on Hacker News, never anywhere else. It's still utterly delusional.
mahboi 1 hours ago [-]
Google probably, also lots of video game devs
skohan 1 days ago [-]
C/C++ is still relevant for HPC, where you want to carefully optimize memory management.
vlovich123 1 days ago [-]
Hate to break it to you but Rust is equally capable of doing all the same memory management optimizations.
skohan 1 days ago [-]
I mean you can, but C/C++ is way more ergonomic for dealing with memory layouts.
Philpax 1 days ago [-]
Is it? How so?
smj-edison 18 hours ago [-]
You don't have to deal with Rust's aliasing rules for &mut and &.
FuckButtons 20 hours ago [-]
It doesn’t have a stable abi, how could it be easier? I would argue that the vast majority of what rust gives you comes at a direct cost of precisely the ergonomics of manual memory management. It’s a tradeoff that makes sense much of the time, but it’s still very obviously a tradeoff.
vlovich123 18 hours ago [-]
It’s easier in that you can cordon off the tricky parts being unsafe and define safe mechanics. Proof point: the Linux kernel using more and more rust and at once the platform support gets there more if the core memory management and what not will start getting ported too.
There’s also work actively ongoing to make certain constructs even easier to express more ergonomically and letting user programs implement some of the magic that’s currently restricted to the standard library
skohan 15 hours ago [-]
The Linux kernel has to balance security and performance concerns, security probably being primary, so it makes sense to make the tradeoff for more safety with worse ergonomics for memory management.
If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
tialaramex 13 hours ago [-]
> If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
If you actually care about performance where you'd start is with measurements. What we see so much from C++ isn't measurements it is dogma. Things C++ forces on you must dogmatically be imagined as free without measuring them, things C++ does not have get treated as expensive, again without measuring so as to justify their absence.
For example, the unstable sort in C++ (std::sort) is typically implemented in a way which introduces Undefined Behaviour if your ordering isn't coherent either because you didn't realise that was mandatory or through some minor programming error. In contrast all of Rust's unstable sort implementations have been entirely safe even in the face of such mistakes.
And your dogma might tell you OK, but the C++ sort must be faster. That's why we're doing unsafe things, it must be faster. Except, nope, slower. Slower, but unsafe. Pointlessly worse. Only acceptable because of dogmatic belief.
skohan 13 hours ago [-]
With all due respect, are you sure you're not the one being dogmatic here?
90% of the code I write these days is Rust. It's a great tool, and the performance/safety balance, as well as general developer experience makes it well-suited to a wide variety of applications.
But in the past I've also built an ECS implementation. For that to optimize performance (and yes I did measure this) you want to do bulk memory allocations memory, pack bytes in order to minimize cache misses, and dispatch multiple threads to read and write concurrently over your memory pool. You can do all that in Rust, and people have, but it's a pain in the ass.
And for example, if I were working on a high-frequency trading application, where every millisecond of additional latency represents millions of dollars of lost revenue, I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
Rust is an amazing tool, but that doesn't mean it's the optimal tool for every job.
vlovich123 6 hours ago [-]
You’ve played sleight of hand with the argument saying it’s easier to do it in C++ whereas before you were claiming it’s faster. I don’t disagree with the easier part and no one on this thread has. But it’s also super easy to shoot off your own foot with a hairline trigger. Rust at least has better tooling to both verify your unsafe code is safe for memory access (Miri is a stronger proof than sanitizers) while letting you define careful interfaces for using said memory safely.
Again - no one takes issue with the ease argument. The only issue was claiming that c++ somehow let you go faster. Indeed, it’s likely not the case because rust has stronger aliasing protections that let it emit more efficient code, closer to Fortran - that’s why the old math libraries you’re probably using in c++ are written in Fortran and not c++ (rust didn’t exist and Fortran enforces no aliasing whereas c++ doesn’t).
skohan 5 hours ago [-]
[dead]
Philpax 11 hours ago [-]
I suspect that the additional friction in doing these things in Rust is still largely outweighed by everything else. I won't deny the friction - it's definitely there - but it has never been large enough for me to consider using anything else (especially reverting to C++!)
With that being said, I did write a compiler to specifically help me match C++ memory layouts in Rust [0], so I might be an outlier case :-)
> I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
I understand your argument as "it's easier to botch an implementation in C++ than in Rust", which is true and that is actually an argument in favour of Rust.
I strongly believe it is harder to write a C++ implementation that is sound and does not rely on UB.
skohan 8 hours ago [-]
You misunderstood my argument.
The point is, there are some domains (data-oriented programming) where Rust actively resists the kind of work you need to do to solve the problem in an optimal way, and it makes sense to use a language built around the type of memory management required.
There's no point in using Rust when 90% of your work is deactivating the benefits Rust provides and working around its default behavior.
tialaramex 11 hours ago [-]
> With all due respect, are you sure you're not the one being dogmatic here?
Obviously like Michael Burry it is always possible that I'm wrong and I can't see why. But I did give you a specific example where the dogma says well we have to choose this unsafe way to do it, but the reality is that's not only unsafe it's also slower. It is just worse.
I am glad to hear that you measured. I've been yelling at people for not measuring for much longer than Rust has existed - if people measure and choose C++ because the numbers were better I feel a lot better about that outcome.
As to being the right tool, I firmly believe we should use a lot more niche languages which do only one narrow thing very well. One common thing you'll see argued about the Memory Safe languages is that they need runtime bounds checks and such checks are a performance cost the unsafe languages do not incur. WUFFS illustrates that if we're willing to give up generality we can have a language which is entirely safe but doesn't do runtime bounds checks - because it proved mathematically at compile time that your code has no bounds misses so such checks are needless.
Arguably for HFT in particular the dirty secret is that if things go badly enough wrong you just say "Oops" and get a do-over because money isn't real.
anthk 6 hours ago [-]
Redox OS, Asterinax. PD: my first distro was Debian Woody, comparable to Slackware with a 2.2 kernel back in the day, 2.4 was optional. So I've seen everything.
Rust will replace C++. C will we kept as a "low level ASM" similar to what inline ASM was for C.
Still, I can perfectly predict Rust based Qemu and FFMPEG's being rewritten from Bellard et all replacing the former C base. Legacy users can just use legacy machines with Hyperbola (and I'm one of them), but Rust will be almost mandatory to be protected against automatic AI attacks. Kinda like blaster/sasser but much worse. Multiplatform virii written in Golang for instance.
Servers getting poisoned media targetting ImageMagick/GM and FFMPEG on purpose, and VM's too. Thus, rustifying Qemu/Libvirt and FFMPEG will almost be a mandatory task.
SkiFire13 13 hours ago [-]
> It doesn’t have a stable abi
No, Rust _has_ a stable ABI, it's the C ABI. It just isn't the default.
I can confirm that this has been sufficient for all of my memory layout needs, including interfacing with existing C/C++ code in memory.
59nadir 12 hours ago [-]
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.
flossly 7 minutes ago [-]
> P.S. I've tried Zig [...]
Why not Zig then, and C instead?
As a C/Zig outsider, I'd much rather read Zig.
tialaramex 8 hours ago [-]
But why not write assembly then?
If you've sworn off actually getting any value from the programming language so much that you even went from Odin to C it feels like just writing raw assembler is a sensible choice at this point?
59nadir 7 hours ago [-]
> If you've sworn off actually getting any value from the programming language
I haven't sworn off getting value from programming languages, I've just concluded that most languages are not useful and good enough to make me deal with the problems they have with tooling, complexity and so on over C.
Your suggestion to use assembly may be you trying to be hyperbolic, but I don't think it's nearly as hyperbolic and ridiculous as it'll sound to a lot of people. I personally think I get plenty of value out of the facilities C provides now, especially with later editions, but it may also be that it'd be holistically better to simply write assembly.
Because that's really what it comes down to: The big picture version of a lot of languages are that while the languages themselves may seem like an upgrade, their interaction with debuggers, etc., are not. A concrete example of this in Odin is that debuggers do not work particularly well with tagged unions (tagged unions have concrete integer values for tags in Odin, and the unions are generated anonymously and are not clear regarding which case is which), so whichever upside you have with language support for tagged unions, you'll still pay for it at debugging time. Meanwhile, in C with real enum types as you have in C23, your tag will be whichever enum value you have, i.e. readable and understandable, and your actual union cases will be exactly what you named them.
For just about every feature I like in Odin I have a similar story of where it falls apart with regards to tooling and other things. A "good language" doesn't mean that actually developing with it is any better than developing with an arguably less featureful and "worse" language.
tialaramex 6 hours ago [-]
I was absolutely serious about assembler.
I spent a considerable portion of my career writing C. But for the past few years I write only Rust in my free time (I do write little snippets in other languages, including Odin, but nothing serious)
Debugger support is like any other tooling problem, you need somebody who agrees with you about what the tools ought to do - to do the work. In C there have been decades for somebody to put together the rudimentary pieces needed to debug C and that's hardly a tall order
In the specific case you cited (tagged unions) you need a better pretty printer and you need Odin to emit the debugging info so that the debugger can understand these types and the pretty printer can display them to you. Without that you're staring at raw data and no surprise it doesn't feel like C would be less useful.
59nadir 58 minutes ago [-]
Sure, but all of this comes down to "Which reality do we live in and do you want to do the work to get the reality you prefer?". I don't think Odin provides enough of an upside for me to "fix" tooling. If I can get a simpler, even less ambitious language, and I can have my tools just work that way as well, this seems like a pretty winning scenario.
So yeah, it's not that you can't have a debugger that understands all of Odin perfectly, it's more like the reality we do have is one where basically none of them understand Odin perfectly, one has built-in (read-only) support for just slightly better Odin-specific views/functionality, two have read-only support (no interaction with built-in types because they use magic intrinsics behind the scenes and magic syntax) for Odin with custom scripts you have to load and everything else is just looking at C.
I've written Odin for 4+ years at this point, so it's not really as if this is a knee-jerk reaction to initial friction. I've spent the time and at this point I am very certain that I don't want to spend any more time with languages where tools are always bad or leaning towards bad, because I've realized that tools are really much more important to me than the languages themselves. I might even start using a language server again because C has one that's ridiculously fast in comparison to what you get with Odin, and it probably won't crash several times a day as soon as you get over some mild threshold like 25k lines, or a "whopping" 5k line file.
j1elo 1 days ago [-]
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.
loeg 1 days ago [-]
Plenty of new C++ going on at my BigCorp employer.
pjmlp 1 days ago [-]
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.
tkz1312 1 days ago [-]
I've been extracting a lot of verified C from theorem provers recently.
xedrac 1 days ago [-]
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.
redox99 17 hours ago [-]
Console/PC gaming is mostly C++ (and scripting/blueprints/etc).
neutronicus 1 days ago [-]
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.
tormeh 21 hours ago [-]
The new drone companies seem to favor Rust more. Helsing sponsors a lot of Rust conferences and stuff. Quantum Systems has job postings for embedded Rust. For companies that don't have a lot of legacy influencing their decisions, Rust is pretty much always going to be in their software stack. The big primes will probably come around to it in a decade or so.
neutronicus 4 hours ago [-]
I'm in the DC area so I think it's more established players I'm looking at.
thomashabets2 1 days ago [-]
Do you know if the code bases are of the kind where dynamic memory (among many other features) is disallowed?
3eb7988a1663 21 hours ago [-]
Defense industry can work around that.
This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.
From the job postings, many of them seem to be physics simulations of various kinds where (in my experience) memory is allocated on the heap without a second thought. Well, there are second thoughts, but those second thoughts are about performance.
debo_ 21 hours ago [-]
C++ requires defensive programming, so I guess it fits that defense requires C++ programming.
pornel 1 days ago [-]
Cloudflare is all in on Rust, it's used everywhere by default, and C++ leftovers are being actively torn down.
nchie 14 hours ago [-]
Going all in on Rust doesn't have to mean you'll rewrite everyone's firmware drivers in Rust, nor does it mean rewriting everyone's OS in Rust or rewriting the platform on which Rust is compiling.
flossly 5 minutes ago [-]
No, "CloudFlare going all in on Rust" means that the code they write and maintain is rewritten.
pjmlp 15 hours ago [-]
So they will remove LLVM from rustc and throw away V8?
m00dy 14 hours ago [-]
It's just a matter of time.
pjmlp 14 hours ago [-]
Yeah, sure. Cranelift isn't making that much progress, and Google is in no hurry to RIIR V8.
m00dy 14 hours ago [-]
As far as I know, someone outside Google rewrote the TypeScript compiler in a week in Rust, and according to the benchmarks, it’s better than the Go version. The same thing will happen here. There’s no time to wait for Google. Someone else will do it.
mahboi 1 hours ago [-]
Someone also rewrote an entire certain JS runtime in Rust
pjmlp 13 hours ago [-]
Yes, and the TypeScript team said, thanks but no we not taking it.
IshKebab 1 days ago [-]
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.)
m00dy 18 hours ago [-]
Rust is eating C/C++.
pjmlp 15 hours ago [-]
While depending on a compiler framework written in C++, the irony.
pipe01 11 hours ago [-]
Not if you use Cranelift
pjmlp 6 hours ago [-]
Yeah, but that isn't what the reference compiler uses.
m00dy 15 hours ago [-]
We’re at a point where you can build anything in any language, and Rust is eating everything because its strict guarantees help cover the weaknesses of AI-assisted development.
mahboi 1 hours ago [-]
Also, even if you don't care a ton about safety, Rust has a nice modern toolchain and standard lib. I did find the Rust language itself more cumbersome than C or C++, but now the lang being cumbersome isn't much of an issue.
pjmlp 14 hours ago [-]
One less reason to care about Rust then, I rather go straight to machine code.
> Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub.
The eating everything part is only the usual hype cycle as folks update their CVs, in this fashion driven industry.
Except this time around AI makes language knowledge meaningless, we can vibe code anything into any language.
m00dy 14 hours ago [-]
Assembly, C, and C++ all fall into the unsafe category. They don’t offer the same memory-safety and concurrency checks Rust does when AI-generated code gets things wrong. Sorry, but this industry is more competitive than ever, and it’s starting to look like there’s no room for amateurs.
pjmlp 14 hours ago [-]
You mean when AI generates Rust code full of unsafe code blocks and calls it a day, yeah.
m00dy 14 hours ago [-]
No, I mean Rust is the final nail in the coffin for C/C++ developers. In Darwinian terms, they’re a species that’s already hit its evolutionary peak and is now heading toward extinction.
pjmlp 6 hours ago [-]
So when will Khronos release their standards for Rust instead of C and C++?
This kind of arguments is what gives raise to the Rust Evangelism Strike Force memes.
pjmlp 13 hours ago [-]
Looking forward to that LLVM rewrite into Rust then, to save Rust from being dragged into extinction.
Naturally everyone around the globe that contributes to LLVM will gladly contribute the rewritten version as well.
anthk 7 hours ago [-]
Check Rustpython. Not bad at all...
Also, there's some C compiler in Rust, enough to build some crates.
neutronicus 3 hours ago [-]
If I "go extinct", we both know that LLMs were the first and last nails in the coffin, and all of the nails in between.
In some hypothetical LLM-free world where Rust is displacing C++, hiring managers will still consider C++ experience a strong signal. As is, see you at the bread lines, comrade.
anthk 7 hours ago [-]
I love Unix and C, and I use Hyperbola GNU/LInux daily, but if the current AI stance on security is like the one frmo cyberpunk movies, keeping my N270 based netbook with hbola just barely connected (or with NPF rules with just I2PD and YGG networks enabled) and getting mail/usenet in batch mode will be the norm, because my biggie AMD64 Intel NUC machine for sure will be more and more Rust bound, at least for work/security/banking and whatnot.
I expect migrating my MUTT setup against isync/mbsync with some Golang written MUA targeting my maildir folder. I will lose some speed but I'm not at mail 24/7 in the netbook and Slashem doesn't demand a lot for gaming. Oh, and S9 Scheme and Klong for sure they work with very little, same with MupDF, sxiv for images and MPV. But, as I said, batch-mode communications will be mandatory on that device. Download, upload, disconnect. Every answer to discussion threads will be done offline.
AERC as a mail client it's written in Go and it's supports Maildir, so that's it.
Also, if someone created some SLRN fork rewritten in Go it would work in the exact same way. Slrnpull to fetch, some Go based reader pointing to the caché folder. Secure and not as slow as anyone would think.
Given how many vulns are discovered maybe even pledge/unveil under OpenBSD won't be enough. Call me crazy, but if all the OBSD people migrated to Redox OS keeping the MIT license it could be a crazy move and maybe a surreal end to the BSD Unix mythos, but it might be a much needed evolution, kinda like plan9/9front was against the old plain Unix philosphy. Evolve or die.
icase 1 days ago [-]
[flagged]
thomashabets2 1 days ago [-]
Are you just being snarky, or do you have something more specific to say about something that's choosing C?
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
mahboi 1 hours ago [-]
C without UB is basically impossible, but C that does the right thing based on assumptions about the platform is possible. I'm not against Rust taking over, just can see C holding out quite long because it's really not that bad.
clifflocked 1 days ago [-]
> Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB
Undefined behavior does not mean that a language is useless. C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Also, it is possible to verify that the types of UB that you are referring to do not occur: see the seL4 project, which provides machine-checked proofs for an OS kernel that no execution can reach a state that is undefined by the language specification.
thomashabets2 1 days ago [-]
> Undefined behavior does not mean that a language is useless.
Never said it was useless. But it's pretty damning that literally nobody can write correct code in the language. And my point is that it's been enough time that it can't be seen as a skill issue.
> C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Absolutely. I think in order to understand programming you need to be able to write C, and be able to read assembly.
C isn't "high level assembly", with the whole discussion about the spec talking about the abstract machine, but one does not need to be a C language lawyer to be a good programmer.
But to your point about checking the output: That goes for Rust too, and godbolt.org supports Rust too, for this workflow.
So I'm not saying C is useless. But I am saying that if someone were to decide to write their greenfield project in C, then if it plans to have actual users (as opposed to a fun project), then it's basically misconduct.
Cf. Steve Gibson writes his software in assembly, still. Because he enjoys it, and his enjoyment is the primary user. I respect that. But I would NEVER hire someone to write whole applications like that in assembly. Or C.
dnautics 1 days ago [-]
> who can write C without UB
Sel4?
3eb7988a1663 21 hours ago [-]
NASA, They Write the Right Stuff. Essentially: go very slowly and carefully. Not at all like the typical cowboy coding in your typical software.
They aren't being snarky, they're stating a fact. Rust, rounding to the nearest percent, does not exist. It's a trendy language among the Silicon Valley types that HN draws, but 99.9% of the world runs on C/++, OSes written in C/++, and language VMs implemented in C/++. Maybe some day it will change, but hanging around here too much will give you a very skewed idea of how widely adopted it is.
thomashabets2 1 days ago [-]
Well, "grownups with important jobs write C" can be taken in two ways. Non-snarky, sure. There are MANY people who write C professionally.
Not as many as there are Python, Java, JS, or C++ programmers. Depending on the survey, C seems to be neck and neck with PHP.
I read the comment the other way, though. The way that says that those other more popular languages are not serious, and NOT for grownups with important jobs.
Python, Java, and JS are all implemented in C/++. C++ is an extension of C. Taken strictly, sure, not everyone is literally writing C. But C powers everything. It is still the systems language of the world, that is the foundation of all of our systems, including both embedded and phone/PC OSes. Then there's a bit of COBOL and Fortran for mainframes, Ada for military hardware, and a whole notta Rust anywhere.
Think about what Rust software people actually use. Codex CLI, uv, ripgrep, and what else? That's three pieces of software, all development tools for development nerds. Normal people aren't engaging with any of this stuff. Your metaphorical grandma has never used software written with Rust in her life.
thomashabets2 1 days ago [-]
Cobol powers the world's money and international travel. Not sure how that matters.
> Think about what Rust software people actually use
More and more Chrome, Google, Android, Cloudflare, Prime Video, and phone basebands, parts of Linux kernel, and many other things.
Normal users literally use those all day every day.
Are they 100% Rust? Of course not (well, I don't actually know if some phone basebands are, by now. Naturally very closed source). But they're not 100% another-language either.
If C disappeared from the world, the world would stop, yes. Same with Cobol. Same with Java. Same with C++. Same with assembly.
If I were to guess (completely without basis for my guess) about the number of lines of code that normal users exercise in a normal day (counting each line just once), my bet would be on Java or JS.
Would the Java be able to run without the C code? No. But normal users would not be able to do anything if only C was left. And all banks would be gone.
And in any case C would not be able to do anything without transistors.
dwattttt 1 days ago [-]
Rust is in use in more places than you may expect. Does the hypothetical grandma use Windows' kernel? Android? Firefox? Chrome?
anonymous908213 1 days ago [-]
1% of code in some obscure module that's barely used being written in Rust does not give one claim to those things being written in Rust. Even Firefox is only 10% Rust despite the language being designed by Mozilla, and they abandoned their project to write a new browser engine in Rust.
aero_code 1 days ago [-]
It's not "some obscure module" that is written in Rust. Just some examples I know of:
- Windows' DirectWriteCore for font handling is also now written in Rust.
- Firefox's whole CSS engine and GPU 2D rendering engine are written in Rust.
thomashabets2 1 days ago [-]
What is your point?
I pointed to a jetbrains study, and then there's a stackoverflow survey[1] showing C neck and neck with PHP at 11th place among professional developers.
We all know there's lots of important C code out there. I don't see anyone going "RIIR!!!" in this thread.
But obviously yes, the 11th place language will have MANY programmers working on it. Not as many as JS by far. But many. In that survey Go is just after PHP. There are also many many Go programmers.
We are not yet at risk of running out of C programmers, like the Cobol situation. Nor do I want us to.[2]
But what point are you trying to make by so strongly defending C and the comment "grownups with important jobs write C"?
The point I am trying to make is that C is a production language and Rust is not a production language, so the original comment is pretty much correct if you take adults with jobs to mean writing software used in production. People use JS, your JS engine is written in C++, running in a browser written in C++, running on an OS written in C/++. Whatever higher-level language you use, it's powered by C/++. Your game engines are written in C/++. Your fucking car is written in C. It's not even an argument about what is better or what people should use or anything like that. It's just acknowledging reality. You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era when in actuality the world around you is a world written entirely in C with, rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
dralley 19 hours ago [-]
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.
dwattttt 22 hours ago [-]
> Rust is not a production language
Your argument was that the only Rust projects there are are little developer tools, so Rust isn't a production language. When pointed out there are large projects that every day users rely on that use Rust, and not just in corners of the codebase, code that's exercised by approximately all users, you insist it's still not production?
contact9879 23 hours ago [-]
> Rust is not a production language because so much legacy code
You must not exist, because, rounded to a whole percent, literally 0% of the lives of people in the world are directly affected by you personally
anthk 22 hours ago [-]
In less than a year tons of Chromium features will be Rust based.
Even big bases as FFMPEG will be ported to Rust, as the porters' repos already use Rust's cc to compile ASM code.
And of course Qemu will be almost a mandatory candidate for obvious reasons.
Most things in the world are not made of zinc. But to therefore say that we live in a world without zinc in production is not a correct conclusion (https://youtu.be/jWpPrWHBHcQ).
> running in a browser written in C++
As other have pointed out, that browser would not render fonts without Rust. You use your browser without fonts? I mean, it's not impossible. Some people navigate the web using screen readers.
> running on an OS written in C/++
Except the parts that are written in Rust or other languages, sure.
So tautologically, the parts that are not written in other languages, are written in C and C++. That's technically correct, the best kind of correct.
> Whatever higher-level language you use, it's powered by C/++
"Powered by" in that it runs on an OS written in C, assembly, and C++, sure. Still not relevant. Languages tend to want to "self-host".
> Your game engines are written in C/++
Well, most gaming hours in the world are probably spent on games written in C#, Java, Kotlin, Swift, and Objective-C. And JS.
JetBrains 2025 study has 40% of game development as C#. C++ just 29%.
AAA games, sure. But it's understatement of the year to say that because AAA games are written in C++ that means it's the only production language.
> Your fucking car is written in C
I think you're stuck in the past. This is no longer a categorically true statement.
The world changes. It used to be a true statement that "americans don't even have passports". In 1989 only 3% had passports, and the world could mock that figure. Today it's 48% and rising.
Just like you should no longer say "americans don't even have passports", because while the percentage may not be a record, it's no longer true, you should stop saying other things when they are no longer true.
> literally 0% of the software anyone uses being written in Rust.
As I have others have repeatedly proved to you, this is literally (actual literally, not as a rhetorical device) false.
I guess you could live in a world with 0% Rust. Your car is old, your Linux kernel was compiled to exclude Rust parts (not sure this is possible. Haven't checked), and you don't run anything Chromium-based, or Firefox. And you don't own an Android phone.
But you saying (asserting without evidence) that it's only minor systems in these omnipresent systems that use Rust, then… uh… what's your point? In a car, if C controls fuel injection and Rust controls the power steering, does that "not count", and you'd still claim "literally 0%"?
But… like, if you have an iPhone instead, do you think it doesn't run anything Objective-C or Swift?
I think it's accurate enough to say that "Cloudflare runs on Rust".
You think you, and normal people, never use Cloudflare? Cloudflare hosts like a a quarter of web traffic.
A quarter of web traffic runs on Rust. In production. Right now.
> You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era
Just like with Cobol, in an existing system it does have its place for extending existing code.
But that "new" is key.
> world around you is a world written entirely in C
Entirely? No. Nobody's saying there's no C code in existence. I don't know why you care to defend against that imagined claim.
> rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
Does it matter, if (say for example) your pacemaker or car ignition runs Rust?
Come back, zinc, come back.
scottyah 23 hours ago [-]
I doubt it, Rust developers compete only with crossfit and vegans in the race to be noticed.
dwattttt 22 hours ago [-]
You.. doubt that people use Firefox, Chrome, Windows, or Android? That it must be "attention" that's the reason those projects have Rust in them now?
anthk 22 hours ago [-]
There's RustPython and far more compatible than IronPython back in the day. C++ is NOT an extension of C, they diverged a lot.
>Codex CLI, uv, ripgrep, and what else?
RustDesk, Servo/Firefox, tons of gtk4-rs on Gnome and extra tools, Librsvg, CosmicDE (Fedora Atomic with Cosmic can be slightly faster than vanilla Gnome Silverblue),
Ruffle, Gopher64, ArtCraft (both the vibecodec cr*p and the AI powered magical multimedia IDE doing crazy stuff which is fine).
Gnome might be a Rust domain tomorrow and nobody would bat an eye. Fedora/RH/IBM can rewrite the Anaconda installer in Rust in no time.
mahboi 24 hours ago [-]
Grownups with important jobs use at least a few different languages
geertj 17 hours ago [-]
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.
zelphirkalt 15 hours ago [-]
In a few years probably no one will be thinking or talking of Mythos any longer, as it is just the next marketing item in the never ending chain of items to be released as the next scary thing.
oddCopper65 1 days ago [-]
The enum-over-bool rule is the one I'd keep even solo, saved me a reversed flag in a cert validator once.
sebastianconcpt 1 days ago [-]
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.
TimTimTim1234 36 minutes ago [-]
Is this good? Do i give this to my agent or nah?
JoeDohn 1 days ago [-]
This is nice, I have been lurking on google and meta rust projects, mimicking and picking style by prompting LLMs to distill it, taking a look at fmt & clippy configs helps too.
But it wasn't as coherent and reliable from project to project like this guide. Kudos to google on this one !
i2talics 1 days ago [-]
Much of this is very standard across the Rust ecosystem but it's very helpful to have it all in one place.
37 minutes ago [-]
slaymaker1907 1 days ago [-]
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.
i2talics 1 days ago [-]
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.
smj-edison 6 hours ago [-]
The problem with lifetimes is they become a object tree, where Rc and co let you represent an object graph (well, a DAG at least). So when your problem resembles a tree, it's great, but some problems don't like being forced into that shape.
mrbonner 22 hours ago [-]
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.
wtetzner 24 hours ago [-]
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.
hitekker 21 hours ago [-]
> Don’t use async / .await in Chromium.
That's pretty direct. IIRC, the Rust for Linux people also have that refrain informally
eviks 16 hours ago [-]
> out of automatic formatting using #[rustfmt::skip], but only in the following situations:
> Manual alignment
Guess, another decade before Rust robots can do columns?
wocram 16 hours ago [-]
There's something ironic with having project specific variants in a style guide.
solatic 10 hours ago [-]
How many of these could be enforced with a linter?
"Prefer enum over bool in APIs: Use enum function parameters instead of bool in cases where the purpose of the parameter is not obvious. If you do use bool, consider using an inline comment to document the purpose of the bool in an argument list."
So.... build a linter that refuses boolean parameters, and if there's an exception, then it'll be in the comment that disables the linter for that particular parameter?
And if it's in a linter then you find out waaaaaay faster compared to rolling the dice on whether the human reviewer remembers the rule or not?
durdn 7 hours ago [-]
and even more interesting, how many that can't be enforced by a linter can be enforced by Typesafe's Jev?
eugenedonin25 12 hours ago [-]
Very nice post
mmooss 24 hours ago [-]
> Usage of lowercase alphabets in hex literals (0xab123cdef as opposed to 0xAB123CDEF): hex_literal_case = Lower
Anytime numbers and letters are mixed, it's more readable if the letters are lowercase. It's easier to read the variable heights - numbers are usually capital letter height, sometimes with descenders - and avoids confusing 0O, I1, even 8B and 5S (think of a degraded printed serial number, poor lighting, etc.). There's only l problem that persists.
IX-103 23 hours ago [-]
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.
egl2020 32 minutes ago [-]
I learned to touch type using lower case l for 1. Later on I was "Look, ma, there's an actual number 1 on this computer keyboard."
manlymuppet 20 hours ago [-]
How useful would this be to simply feed to an LLM and say to follow strictly?
threethirtytwo 20 hours ago [-]
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.
JimTheMan 20 hours ago [-]
Could you just get a separate agent to do a pass over existing code and make conform? Like super linting.
Not a professional programmer, so it's a genuine question rather than a statement.
threethirtytwo 18 hours ago [-]
Sure you can do that. But what’s the practical point if only your agent is reading it? Your agent doesn’t care about linting.
manlymuppet 3 hours ago [-]
Presumably the agent isn't only reading, but changing the code to conform.
0xmassi 11 hours ago [-]
[flagged]
bibekadhikari 21 hours ago [-]
[flagged]
chmmohibullahpa 14 hours ago [-]
[dead]
younglunaman 1 days ago [-]
ctrl+c > ctrl+v > into my AGENTS.md for my next rust project /s
icase 1 days ago [-]
[flagged]
sebastianconcpt 1 days ago [-]
The good emotions come with the confidence in the engineering quality that it gives you as output (once you overcome the friction, which AI can help you big time to achieve).
xiaodai 23 hours ago [-]
why is google using github, a Micro$oft product?
shaftway 23 hours ago [-]
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.
holografix 1 days ago [-]
Things like this make me appreciate Gofmt so much
japgolly 19 hours ago [-]
But there's a rustfmt already. Anyway, the style guide is larger in scope than just code formatting.
24 hours ago [-]
incrediblers 1 days ago [-]
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.
i2talics 1 days ago [-]
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.
incrediblers 1 days ago [-]
My use case is a TUI framework (https://www.incredible.rs/). The setters configure elements in a chain-able manner. I grappled with the rust convention and decided to go the other way. Rational as mentioned.
But this made me think...
> "The getter ought to have a shorter name since it is probably called more frequently"
And in a code editor with a lot of ui configurations based on reusable elements
2865 setters and 206 getters.
In reactive apps on state handlers call on setters with state values. No getters involved...
afdbcreid 1 days ago [-]
That means those are probably builders and not setters. Do they change an existing object or a newly-constructed or to-be-constructed object?
incrediblers 1 days ago [-]
They are setters. They modify an element after instantiation. Mostly as part of the initial build, but then also in the event closure. Under the hood, a struct with interiorly mutable fields.
i2talics 19 hours ago [-]
This sounds a lot like a builder but the line can be blurry. For a Rust stdlib example, the `process::Command` type is considered a builder even though it is not named "CommandBuilder", and the final operation is spawning a subprocess, not returning some other data.
incrediblers 17 hours ago [-]
What I was saying is that I think a "flipped pattern" where anything that sets something sometime somewhere is the word and anything that reads is a get_* makes this fine distinction unnecessary... and that makes life easier... I came to Rust from JS where one can overload methods... I understand from other comments that the set_* convention may have arrived from C++... In any case, consistency I think beats specifics.
fwip 22 hours ago [-]
Gotcha, so in your case, users of the library will set values much more often than read them (since the reading will be done by the TUI framework for display).
trimbo 1 days ago [-]
This style is aligned with protocol buffers, which is aligned with the style of protos in C++.
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.
1 days ago [-]
23 hours ago [-]
Thanemate 1 days ago [-]
Not trying to rain on someone's parade but, the only reason why would care about style guides nowadays is to feed them to our model of choice and let it do what it's supposed to be doing.
So it's not like I am willing to read through this and think to myself "I cannot wait to pick up some new ways of doing things". I'm the general to my agentic army now.
I guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?
nimih 1 days ago [-]
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 guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?
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.
anonymous908213 1 days ago [-]
> I'm the general to my agentic army now.
What have you produced with your agentic army? Would you like to share with the class?
bigfishrunning 1 days ago [-]
my guess is a lot of heat, some water vapor....
solyin 1 days ago [-]
Why would they when the class is full of dropouts who, generously, have a 0 percent chance of going "hey, y'know what, that's actually kinda cool! I'm going to change my mind about LLMs being useless" and a 100% chance of going "ur project is total shit and you should feel bad".
nvme0n1p1 1 days ago [-]
The people you call "dropouts" have written 100% of the software that people actually use and actually keeps the real world running, so maybe you shouldn't write them off.
lioeters 20 hours ago [-]
The "all in on LLM" hypesters are as obnoxious as the "all in on Rust" hipsters.
We get it, Rust is great, and LLMs too. But sometimes it's like listening to teenage philosophers who just discovered atheism, who go on and on to disparage all religions every chance they get. They're so full of themselves that they don't realize they're missing entire areas of understanding about the world and people.
The juvenile arrogance on display in many threads in recent years is second-hand embarrassing. Meanwhile the greybeards continue getting the job done, with or without LLMs, in Rust, C++ or even C.
solyin 17 hours ago [-]
Class is full of dropouts != every single last member of the class is a dropout.
scottyah 23 hours ago [-]
Unlike Linus, Jeff Dean, DHH, John Carmack, Guido van Rossum? I really want to know who you think writes "100% of the software that people actually use and actually keeps the real world running"
nvme0n1p1 23 hours ago [-]
Have any of those people (excluding DHH) said anything even half as ridiculous as "I'm the general to my agentic army now"? Or are they adults using tools where they make sense and avoiding them where they don't?
If you think style guides don't matter anymore, I encourage you to submit patches to the people on your list whose credibility you're borrowing, and see if they agree. Tell Linus to delete https://docs.kernel.org/process/coding-style.html because it doesn't matter because we have AI now. Or ask GvR if the current Python maintainers should deprecate https://peps.python.org/pep-0008/, since agents don't need it.
vor_ 21 hours ago [-]
Linus doesn't even do much programming by his own admission. He's a release manager.
japgolly 19 hours ago [-]
That being said there was a story about him debugging an issue recently with some pretty serious help from AI.
Mawr 23 hours ago [-]
Hmm, one of those is not like the others...
smoe 1 days ago [-]
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.
monocasa 1 days ago [-]
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.
mkagenius 1 days ago [-]
> Shitty generals can't review meaningfully review the work of their troops.
Except that reviewing has become just asking your agent what that piece of code does in english. Reading code has a bit of cognitive load, that we will probably drop it in coming years
msm_ 2 hours ago [-]
>Except that reviewing has become just asking your agent what that piece of code does in english
How does this work for you?
Do you ask about specific functions ("what does this function do")? Then it sounds like more work than actually reading it.
Or do you ask about the whole PRs ("what does this PR implement")? Then how do you catch things like security vulnerabilities, bad design choices, unnecessary dependencies, wrong architecture, etc? Those are things that benefit the most from human understanding (nitpicking style was always the easy but unimportant part of code review)
u1hcw9nx 1 days ago [-]
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!
yodsanklai 1 days ago [-]
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.
scottyah 23 hours ago [-]
Either you can put it in a linter and automate/force it, or people/agents will take liberties. I feel like there's usually exceptions where a well-meaning guideline doesn't properly fit a specific scenario.
petersellers 1 days ago [-]
Are you saying that you don't ever look at the code once it's been generated?
bigstrat2003 1 days ago [-]
AI bros think you can never look at code and make good software. They're wrong, of course, but they refuse to listen and will probably never listen until the shoddy quality of their work becomes too great to paper over.
IX-103 23 hours ago [-]
If you set up a really good AI code review pipeline then you can get pretty close. I've heard a couple of tech companies are targeting 80% of changes not needing human review and they'll probably scale up from there.
bigstrat2003 13 hours ago [-]
If you aren't reviewing 100% of the code, you aren't doing engineering, you're producing slop.
gatlin 1 days ago [-]
Seems very much like your goal was to rain on a parade.
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.
If you're building one binary you can choose when to update and fix all the referents at the same time. A distributed system does not have that luxury and it makes more sense to require forward compatibility.
I guess another option is a two-phase update where you first update all the services to accept the new enum variant without ever emitting it, then you can phase in services that use it. The downside with this strategy is that you're locked into upgrades and you can't roll back individual service versions, so to be safe you probably need to delay use of the new enum variant by 2-3 releases (at some point rolling back is not a viable option and you have to publish fixes in a new release anyway).
So in a service world the only options are either "require forward compatibility" or "delay rollout of a new feature to 3 release cycles after all services in distributed system are updated" which is like a month minimum. I can see why forward compatibility is the default, and also that you might want to keep the two-phase deployment strategy for certain cases.
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.
With #[non_exhaustive], adding a variant is not a breaking change, but only if that variant can safely be ignored. If it can't be, then it's still a breaking change, BUT you don't get a compiler error. That's a very big drawback IMO.
This makes me think of how the PNG format handles this. For context, PNG files consist of a list of chunks of different types (image data, color profile, text comment, etc). Each chunk has some flag bits that tell you whether it can be safely ignored when decoding the image, safely retained when the image data is changed, etc. That way the decoder can ignore unknown ignorable chunks and error on unknown non-ignorable ones.
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.
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”?
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.
edit: I don't know rust. in other languages he's such catch all patterns exist and you have to either capture each possible value explicitly or you express "here in this fu, I take care of these and all others I do that..."
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.
Note that teams generally manage their own deployments, so even a repo wide code change doesn’t force the update of an older deployed binary.
There are reasons why Google pays this price! But I think it's one of the worst practices for much smaller organizations to adopt.
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.
Second case is the same. The other team needs to definitely know, that their assumptions expressed in their current code are broken and need to be adjusted.
We just need to stop to take whatever shit Google is doing as the one bar to measure all others, and need to understand that they may be different requirements than a typical business. We are not Google.
I don't want to update every place someone matches on my enum, when it's something not even in my project, just to get my PR to merge. Three teams use it? Fine. Ten? More? Not fine. You are adding cases into someone else's code just to unblock your own work.
The second case is actually not the same at all. Realistically, they will just pin your dependency to an older version. Now they can't benefit from new features and security fixes without going in and adding in a new case. Massive waste of time for them.
And of course I'm not just taking whatever Google says at face value. I read their justification, and it makes total sense for anyone that works on a non-trivial project. It follows how any stable public API is supposed to be designed.
Then don't upgrade your dependency onto the other crate.
Anything more than a hobbyist will have properly pinned versions, and not just sling around version ranges loosely. At the very least will not update lock file just like that, without considering, that there may be consequences.
If you really don’t care about compiler warnings, what’s the actual point of using Rust?
- this are rules created to be (kinda/mostly) uniformly applied across all projects at a Google Scale company
Having used rust at work since roughly ~1.0 days I have come to a realization:
- the style guides which work best for "blindly uniformly applied across all kind of projects/teams/people" are not the same as "my preferred style" _in a lot of ways_
- similar they are often not "the best" in every case but they are "uniformly applicable without having to make opinionated decisions" i.e. they don't cause frictions in review or when writing the code due to "style only"-decision without a clear good answer
As a more generic example. There are a lot of frameworks/style guides which lead to related logic being split across 3+ small files in different folders instead of having related code "close together". And this can be a huge pain and isn't how I would manage personal projects. BUT putting code close together will sometimes just not work for various reasons (often shared logic/cross cutting concerns) at which point you will have to make some compromise where/how to place the code which has no simple "no brain used schema-f" solution you can blindly apply no matter what. This can lead to friction. Once too many people touch the same code this tend to become a huge mess, too. So the companies use style guides which split things apart. Even through the outcome is for all the simple cases noticeable worse to work with. As it does scale to large teams, very varying skill levels and many people working on the same code.
I find it interesting that Google uses Rust. I know they work on Rust-based kernel code for Android. I'm curious to know if they also use it for networked application code, and why they picked it over Go.
Personally I prefer Rust over Go for it's types, and I never use it in big projects, so compile time does not bother me. But Google basically created Go for it's networked application code.
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.
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!)
https://source.chromium.org/chromium/chromium/src/+/main:tes...
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.
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.
So a single crate has to be as small as possible so builds are fast & cachable.
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.
And then the ability to enforce a formalized layer between crates and the way that they assemble into your application (i.e. the public API) is powerful for comprehension and maintainability. I go as far as documenting each crate with its own README that presents it as a standalone component with usage instructions, much like an open source library, even if it's only ever used in a single system.
This just pushes people to have redundant information in types (`IoError` instead of `io::Error`).
Unless a type is widely recognized (like `HashMap`), I prefer to have them fully qualified so I have the contextual meaning for it. If I am working with a generic name like `Source`, what does that mean? I shouldn't have to look up in the imports to understand the code (or only understand it through an LSP).
Reducing imports also reduces unnecessary merge conflicts.
Everyone remembers finding some hideous name like foo.widget.widgetBuilder.widgetFactory in Java or something. It's nice to have naming rules, or at least guidelines, focused on trimming redundancy and keeping the signal high.
NO, it’s beautiful! https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Nowadays, I care about their recommendations as much as the ones from microsoft, or ibm.
Still big companies, lots of smart people, but nothing above norm.
Oxide computing.
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.
Other than a few examples given in the past, the Rust adoption among WinDev doesn't seem to be really taking off like in Azure.
Indeed C# is getting more low level coding features, and the unsafe memory model is being redone in .NET 11 for a reason.
C# to me compares to Java and Kotlin (they have a large runtime or VM and implement GC).
Rust compares to C, C++, Zig or Odin (compile to native, memory is more self-managed).
Apparently outside WinUI efforts, that many don't care about, there isn't much going on, the Rust action is all on Azure side.
Rust for systems programming, C# for non-performing bound tasks (control panels, launchers, light gaming, GUI's on top of Windows CLI tools) and C++ for raw performance. And, still, I won't let any modern codec for A/V to be written in C/C++ for obvious reasons. And I am a diehard Unix+C user in the infamous N270 netbook. but dark times with automatic AI attacks are comming ahead. That's why I migrated from Mutt to Aerc, while keeping my Maildir and msmtp/isync.
At least I will be able to reencode potential harmful media for 420p/720@30FPS for the netbook in the NUC if FFMPEG (or FFMPEG based tools) were converted into Rust without hitting several vulns, because they will be everywhere:
- qemu/libvirt
- imagemagick/graphicsmagick, both the tools and libraries
- any libav* codec/parser
- libpng/libgif and similar
- zip/7z/tar/pax
- PS/PDF, of course. Especially PS, for obvious reasons.
- Some DOC/XLS formats pre DOCX are raw memory dumps and maybe they can be partially executed.
- Some other formats can act like a mini-VM bytecode too, such as RAR.
I even compiled Bubblewrap too so I can jail some of these, and yet I don't trust them 100%. Some recent exploits bypassed the chroot like nothing.
Like, I agree that C++ will be around for a long while, but the writing is on the wall.
Rust's type system is making it's compile times bigger than C, C++ and Zig. This does keep it away from some code that's currently C or C++.
There's no reason to think that current game engines will have their fundamental APIs around scene management, serialization, entity composition, and so on, ported directly to Rust, because these things are typically designed around available language features. For example, an engine written in C++ might have its own version of `dynamic_cast` and RTTI, and that's going to be an extremely awkward design in any other language.
I think 15 years is too high, but I agree that it will be a while, because a triple-A game engine is a huge investment.
15 years of pre LLM or post LLM ?????
There’s also work actively ongoing to make certain constructs even easier to express more ergonomically and letting user programs implement some of the magic that’s currently restricted to the standard library
If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
If you actually care about performance where you'd start is with measurements. What we see so much from C++ isn't measurements it is dogma. Things C++ forces on you must dogmatically be imagined as free without measuring them, things C++ does not have get treated as expensive, again without measuring so as to justify their absence.
For example, the unstable sort in C++ (std::sort) is typically implemented in a way which introduces Undefined Behaviour if your ordering isn't coherent either because you didn't realise that was mandatory or through some minor programming error. In contrast all of Rust's unstable sort implementations have been entirely safe even in the face of such mistakes.
And your dogma might tell you OK, but the C++ sort must be faster. That's why we're doing unsafe things, it must be faster. Except, nope, slower. Slower, but unsafe. Pointlessly worse. Only acceptable because of dogmatic belief.
90% of the code I write these days is Rust. It's a great tool, and the performance/safety balance, as well as general developer experience makes it well-suited to a wide variety of applications.
But in the past I've also built an ECS implementation. For that to optimize performance (and yes I did measure this) you want to do bulk memory allocations memory, pack bytes in order to minimize cache misses, and dispatch multiple threads to read and write concurrently over your memory pool. You can do all that in Rust, and people have, but it's a pain in the ass.
And for example, if I were working on a high-frequency trading application, where every millisecond of additional latency represents millions of dollars of lost revenue, I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
Rust is an amazing tool, but that doesn't mean it's the optimal tool for every job.
Again - no one takes issue with the ease argument. The only issue was claiming that c++ somehow let you go faster. Indeed, it’s likely not the case because rust has stronger aliasing protections that let it emit more efficient code, closer to Fortran - that’s why the old math libraries you’re probably using in c++ are written in Fortran and not c++ (rust didn’t exist and Fortran enforces no aliasing whereas c++ doesn’t).
With that being said, I did write a compiler to specifically help me match C++ memory layouts in Rust [0], so I might be an outlier case :-)
[0]: https://github.com/ferrobrew/pyxis
I understand your argument as "it's easier to botch an implementation in C++ than in Rust", which is true and that is actually an argument in favour of Rust.
I strongly believe it is harder to write a C++ implementation that is sound and does not rely on UB.
The point is, there are some domains (data-oriented programming) where Rust actively resists the kind of work you need to do to solve the problem in an optimal way, and it makes sense to use a language built around the type of memory management required.
There's no point in using Rust when 90% of your work is deactivating the benefits Rust provides and working around its default behavior.
Obviously like Michael Burry it is always possible that I'm wrong and I can't see why. But I did give you a specific example where the dogma says well we have to choose this unsafe way to do it, but the reality is that's not only unsafe it's also slower. It is just worse.
I am glad to hear that you measured. I've been yelling at people for not measuring for much longer than Rust has existed - if people measure and choose C++ because the numbers were better I feel a lot better about that outcome.
As to being the right tool, I firmly believe we should use a lot more niche languages which do only one narrow thing very well. One common thing you'll see argued about the Memory Safe languages is that they need runtime bounds checks and such checks are a performance cost the unsafe languages do not incur. WUFFS illustrates that if we're willing to give up generality we can have a language which is entirely safe but doesn't do runtime bounds checks - because it proved mathematically at compile time that your code has no bounds misses so such checks are needless.
Arguably for HFT in particular the dirty secret is that if things go badly enough wrong you just say "Oops" and get a do-over because money isn't real.
Rust will replace C++. C will we kept as a "low level ASM" similar to what inline ASM was for C.
Still, I can perfectly predict Rust based Qemu and FFMPEG's being rewritten from Bellard et all replacing the former C base. Legacy users can just use legacy machines with Hyperbola (and I'm one of them), but Rust will be almost mandatory to be protected against automatic AI attacks. Kinda like blaster/sasser but much worse. Multiplatform virii written in Golang for instance.
Servers getting poisoned media targetting ImageMagick/GM and FFMPEG on purpose, and VM's too. Thus, rustifying Qemu/Libvirt and FFMPEG will almost be a mandatory task.
No, Rust _has_ a stable ABI, it's the C ABI. It just isn't the default.
I can confirm that this has been sufficient for all of my memory layout needs, including interfacing with existing C/C++ code in memory.
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.
Why not Zig then, and C instead?
As a C/Zig outsider, I'd much rather read Zig.
If you've sworn off actually getting any value from the programming language so much that you even went from Odin to C it feels like just writing raw assembler is a sensible choice at this point?
I haven't sworn off getting value from programming languages, I've just concluded that most languages are not useful and good enough to make me deal with the problems they have with tooling, complexity and so on over C.
Your suggestion to use assembly may be you trying to be hyperbolic, but I don't think it's nearly as hyperbolic and ridiculous as it'll sound to a lot of people. I personally think I get plenty of value out of the facilities C provides now, especially with later editions, but it may also be that it'd be holistically better to simply write assembly.
Because that's really what it comes down to: The big picture version of a lot of languages are that while the languages themselves may seem like an upgrade, their interaction with debuggers, etc., are not. A concrete example of this in Odin is that debuggers do not work particularly well with tagged unions (tagged unions have concrete integer values for tags in Odin, and the unions are generated anonymously and are not clear regarding which case is which), so whichever upside you have with language support for tagged unions, you'll still pay for it at debugging time. Meanwhile, in C with real enum types as you have in C23, your tag will be whichever enum value you have, i.e. readable and understandable, and your actual union cases will be exactly what you named them.
For just about every feature I like in Odin I have a similar story of where it falls apart with regards to tooling and other things. A "good language" doesn't mean that actually developing with it is any better than developing with an arguably less featureful and "worse" language.
I spent a considerable portion of my career writing C. But for the past few years I write only Rust in my free time (I do write little snippets in other languages, including Odin, but nothing serious)
Debugger support is like any other tooling problem, you need somebody who agrees with you about what the tools ought to do - to do the work. In C there have been decades for somebody to put together the rudimentary pieces needed to debug C and that's hardly a tall order
In the specific case you cited (tagged unions) you need a better pretty printer and you need Odin to emit the debugging info so that the debugger can understand these types and the pretty printer can display them to you. Without that you're staring at raw data and no surprise it doesn't feel like C would be less useful.
So yeah, it's not that you can't have a debugger that understands all of Odin perfectly, it's more like the reality we do have is one where basically none of them understand Odin perfectly, one has built-in (read-only) support for just slightly better Odin-specific views/functionality, two have read-only support (no interaction with built-in types because they use magic intrinsics behind the scenes and magic syntax) for Odin with custom scripts you have to load and everything else is just looking at C.
I've written Odin for 4+ years at this point, so it's not really as if this is a knee-jerk reaction to initial friction. I've spent the time and at this point I am very certain that I don't want to spend any more time with languages where tools are always bad or leaning towards bad, because I've realized that tools are really much more important to me than the languages themselves. I might even start using a language server again because C has one that's ridiculously fast in comparison to what you get with Odin, and it probably won't crash several times a day as soon as you get over some mild threshold like 25k lines, or a "whopping" 5k line file.
Ah and Rust's compiler backend dependency on LLVM and in the future GCC as well.
From the job postings, many of them seem to be physics simulations of various kinds where (in my experience) memory is allocated on the heap without a second thought. Well, there are second thoughts, but those second thoughts are about performance.
> Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub.
https://www.phoronix.com/news/Frame-X11-Server-Assembly
The eating everything part is only the usual hype cycle as folks update their CVs, in this fashion driven industry.
Except this time around AI makes language knowledge meaningless, we can vibe code anything into any language.
This kind of arguments is what gives raise to the Rust Evangelism Strike Force memes.
Naturally everyone around the globe that contributes to LLVM will gladly contribute the rewritten version as well.
Also, there's some C compiler in Rust, enough to build some crates.
In some hypothetical LLM-free world where Rust is displacing C++, hiring managers will still consider C++ experience a strong signal. As is, see you at the bread lines, comrade.
I expect migrating my MUTT setup against isync/mbsync with some Golang written MUA targeting my maildir folder. I will lose some speed but I'm not at mail 24/7 in the netbook and Slashem doesn't demand a lot for gaming. Oh, and S9 Scheme and Klong for sure they work with very little, same with MupDF, sxiv for images and MPV. But, as I said, batch-mode communications will be mandatory on that device. Download, upload, disconnect. Every answer to discussion threads will be done offline.
AERC as a mail client it's written in Go and it's supports Maildir, so that's it.
Also, if someone created some SLRN fork rewritten in Go it would work in the exact same way. Slrnpull to fetch, some Go based reader pointing to the caché folder. Secure and not as slow as anyone would think.
Given how many vulns are discovered maybe even pledge/unveil under OpenBSD won't be enough. Call me crazy, but if all the OBSD people migrated to Redox OS keeping the MIT license it could be a crazy move and maybe a surreal end to the BSD Unix mythos, but it might be a much needed evolution, kinda like plan9/9front was against the old plain Unix philosphy. Evolve or die.
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
Undefined behavior does not mean that a language is useless. C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Also, it is possible to verify that the types of UB that you are referring to do not occur: see the seL4 project, which provides machine-checked proofs for an OS kernel that no execution can reach a state that is undefined by the language specification.
Never said it was useless. But it's pretty damning that literally nobody can write correct code in the language. And my point is that it's been enough time that it can't be seen as a skill issue.
> C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Absolutely. I think in order to understand programming you need to be able to write C, and be able to read assembly.
C isn't "high level assembly", with the whole discussion about the spec talking about the abstract machine, but one does not need to be a C language lawyer to be a good programmer.
But to your point about checking the output: That goes for Rust too, and godbolt.org supports Rust too, for this workflow.
So I'm not saying C is useless. But I am saying that if someone were to decide to write their greenfield project in C, then if it plans to have actual users (as opposed to a fun project), then it's basically misconduct.
Cf. Steve Gibson writes his software in assembly, still. Because he enjoys it, and his enjoyment is the primary user. I respect that. But I would NEVER hire someone to write whole applications like that in assembly. Or C.
Sel4?
PDF: https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...
They aren't being snarky, they're stating a fact. Rust, rounding to the nearest percent, does not exist. It's a trendy language among the Silicon Valley types that HN draws, but 99.9% of the world runs on C/++, OSes written in C/++, and language VMs implemented in C/++. Maybe some day it will change, but hanging around here too much will give you a very skewed idea of how widely adopted it is.
Not as many as there are Python, Java, JS, or C++ programmers. Depending on the survey, C seems to be neck and neck with PHP.
I read the comment the other way, though. The way that says that those other more popular languages are not serious, and NOT for grownups with important jobs.
Edit: actually, Jetbrains 2025 survey has C neck and neck with Rust: https://www.jetbrains.com/lp/devecosystem-data-playground/ . Both "below the fold" and less than 10% of Java.
Think about what Rust software people actually use. Codex CLI, uv, ripgrep, and what else? That's three pieces of software, all development tools for development nerds. Normal people aren't engaging with any of this stuff. Your metaphorical grandma has never used software written with Rust in her life.
> Think about what Rust software people actually use
More and more Chrome, Google, Android, Cloudflare, Prime Video, and phone basebands, parts of Linux kernel, and many other things.
Normal users literally use those all day every day.
Are they 100% Rust? Of course not (well, I don't actually know if some phone basebands are, by now. Naturally very closed source). But they're not 100% another-language either.
If C disappeared from the world, the world would stop, yes. Same with Cobol. Same with Java. Same with C++. Same with assembly.
If I were to guess (completely without basis for my guess) about the number of lines of code that normal users exercise in a normal day (counting each line just once), my bet would be on Java or JS.
Would the Java be able to run without the C code? No. But normal users would not be able to do anything if only C was left. And all banks would be gone.
And in any case C would not be able to do anything without transistors.
- Chrome currently uses https://github.com/googlefonts/fontations to implement its font handling, and text is the main thing on most web pages.
- Windows' DirectWriteCore for font handling is also now written in Rust.
- Firefox's whole CSS engine and GPU 2D rendering engine are written in Rust.
I pointed to a jetbrains study, and then there's a stackoverflow survey[1] showing C neck and neck with PHP at 11th place among professional developers.
We all know there's lots of important C code out there. I don't see anyone going "RIIR!!!" in this thread.
But obviously yes, the 11th place language will have MANY programmers working on it. Not as many as JS by far. But many. In that survey Go is just after PHP. There are also many many Go programmers.
We are not yet at risk of running out of C programmers, like the Cobol situation. Nor do I want us to.[2]
But what point are you trying to make by so strongly defending C and the comment "grownups with important jobs write C"?
[1] https://survey.stackoverflow.co/2025/technology#most-popular... [2] relevant comment: https://news.ycombinator.com/item?id=50187384
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.
Your argument was that the only Rust projects there are are little developer tools, so Rust isn't a production language. When pointed out there are large projects that every day users rely on that use Rust, and not just in corners of the codebase, code that's exercised by approximately all users, you insist it's still not production?
You must not exist, because, rounded to a whole percent, literally 0% of the lives of people in the world are directly affected by you personally
Even big bases as FFMPEG will be ported to Rust, as the porters' repos already use Rust's cc to compile ASM code.
And of course Qemu will be almost a mandatory candidate for obvious reasons.
For instance, quick and dirty SGI Irix emulator:
https://github.com/techomancer/iris
> running in a browser written in C++
As other have pointed out, that browser would not render fonts without Rust. You use your browser without fonts? I mean, it's not impossible. Some people navigate the web using screen readers.
> running on an OS written in C/++
Except the parts that are written in Rust or other languages, sure.
So tautologically, the parts that are not written in other languages, are written in C and C++. That's technically correct, the best kind of correct.
> Whatever higher-level language you use, it's powered by C/++
"Powered by" in that it runs on an OS written in C, assembly, and C++, sure. Still not relevant. Languages tend to want to "self-host".
> Your game engines are written in C/++
Well, most gaming hours in the world are probably spent on games written in C#, Java, Kotlin, Swift, and Objective-C. And JS.
JetBrains 2025 study has 40% of game development as C#. C++ just 29%.
AAA games, sure. But it's understatement of the year to say that because AAA games are written in C++ that means it's the only production language.
> Your fucking car is written in C
I think you're stuck in the past. This is no longer a categorically true statement.
The world changes. It used to be a true statement that "americans don't even have passports". In 1989 only 3% had passports, and the world could mock that figure. Today it's 48% and rising.
Just like you should no longer say "americans don't even have passports", because while the percentage may not be a record, it's no longer true, you should stop saying other things when they are no longer true.
> literally 0% of the software anyone uses being written in Rust.
As I have others have repeatedly proved to you, this is literally (actual literally, not as a rhetorical device) false.
I guess you could live in a world with 0% Rust. Your car is old, your Linux kernel was compiled to exclude Rust parts (not sure this is possible. Haven't checked), and you don't run anything Chromium-based, or Firefox. And you don't own an Android phone.
But you saying (asserting without evidence) that it's only minor systems in these omnipresent systems that use Rust, then… uh… what's your point? In a car, if C controls fuel injection and Rust controls the power steering, does that "not count", and you'd still claim "literally 0%"?
But… like, if you have an iPhone instead, do you think it doesn't run anything Objective-C or Swift?
I think it's accurate enough to say that "Cloudflare runs on Rust".
You think you, and normal people, never use Cloudflare? Cloudflare hosts like a a quarter of web traffic.
A quarter of web traffic runs on Rust. In production. Right now.
> You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era
Just like with Cobol, in an existing system it does have its place for extending existing code.
But that "new" is key.
> world around you is a world written entirely in C
Entirely? No. Nobody's saying there's no C code in existence. I don't know why you care to defend against that imagined claim.
> rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
Does it matter, if (say for example) your pacemaker or car ignition runs Rust?
Come back, zinc, come back.
>Codex CLI, uv, ripgrep, and what else?
RustDesk, Servo/Firefox, tons of gtk4-rs on Gnome and extra tools, Librsvg, CosmicDE (Fedora Atomic with Cosmic can be slightly faster than vanilla Gnome Silverblue), Ruffle, Gopher64, ArtCraft (both the vibecodec cr*p and the AI powered magical multimedia IDE doing crazy stuff which is fine).
Oh, and Harper to sharp your English skills:
https://github.com/automattic/harper
IronCalc looks better than LO Calc performance wise:
https://github.com/ironcalc/ironCalc
Gnome might be a Rust domain tomorrow and nobody would bat an eye. Fedora/RH/IBM can rewrite the Anaconda installer in Rust in no time.
But it wasn't as coherent and reliable from project to project like this guide. Kudos to google on this one !
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.
Adding Rc/Arc is just another layer of indirection and noise that makes the code hard to read.
That's pretty direct. IIRC, the Rust for Linux people also have that refrain informally
> Manual alignment
Guess, another decade before Rust robots can do columns?
"Prefer enum over bool in APIs: Use enum function parameters instead of bool in cases where the purpose of the parameter is not obvious. If you do use bool, consider using an inline comment to document the purpose of the bool in an argument list."
So.... build a linter that refuses boolean parameters, and if there's an exception, then it'll be in the comment that disables the linter for that particular parameter?
And if it's in a linter then you find out waaaaaay faster compared to rolling the dice on whether the human reviewer remembers the rule or not?
Anytime numbers and letters are mixed, it's more readable if the letters are lowercase. It's easier to read the variable heights - numbers are usually capital letter height, sometimes with descenders - and avoids confusing 0O, I1, even 8B and 5S (think of a degraded printed serial number, poor lighting, etc.). There's only l problem that persists.
Not a professional programmer, so it's a genuine question rather than a statement.
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.
But this made me think...
> "The getter ought to have a shorter name since it is probably called more frequently"
So i checked. Rough agent driven counts:
https://github.com/ronilan/incredible-flappy 407 setters and 183 getters.
https://github.com/ronilan/rusticon 546 setters and 5 getters
https://github.com/ronilan/shape-sorting 688 setters and 33 getters.
And in a code editor with a lot of ui configurations based on reusable elements 2865 setters and 206 getters.
In reactive apps on state handlers call on setters with state values. No getters involved...
https://protobuf.dev/reference/rust/rust-generated/
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.
So it's not like I am willing to read through this and think to myself "I cannot wait to pick up some new ways of doing things". I'm the general to my agentic army now.
I guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?
> I guess you would code manually every now and then for your own enjoyment but at that point do you care about style guides written for scale?
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.
What have you produced with your agentic army? Would you like to share with the class?
We get it, Rust is great, and LLMs too. But sometimes it's like listening to teenage philosophers who just discovered atheism, who go on and on to disparage all religions every chance they get. They're so full of themselves that they don't realize they're missing entire areas of understanding about the world and people.
The juvenile arrogance on display in many threads in recent years is second-hand embarrassing. Meanwhile the greybeards continue getting the job done, with or without LLMs, in Rust, C++ or even C.
If you think style guides don't matter anymore, I encourage you to submit patches to the people on your list whose credibility you're borrowing, and see if they agree. Tell Linus to delete https://docs.kernel.org/process/coding-style.html because it doesn't matter because we have AI now. Or ask GvR if the current Python maintainers should deprecate https://peps.python.org/pep-0008/, since agents don't need it.
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 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.
Except that reviewing has become just asking your agent what that piece of code does in english. Reading code has a bit of cognitive load, that we will probably drop it in coming years
How does this work for you?
Do you ask about specific functions ("what does this function do")? Then it sounds like more work than actually reading it.
Or do you ask about the whole PRs ("what does this PR implement")? Then how do you catch things like security vulnerabilities, bad design choices, unnecessary dependencies, wrong architecture, etc? Those are things that benefit the most from human understanding (nitpicking style was always the easy but unimportant part of code review)
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!
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.