5 million Rust LOC
One potential memory safety vulnerability found
Rust is 0.2 vuln per 1 MLOC.
Compared to
C and C++ : 1,000 memory safety vulnerabilities per MLOC.
There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it.
And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).
In my experience, the loudest critics of Rust I have heard are actually seasoned C and C++ developers who are incredibly good at one or both languages, but know almost nothing outside it.
On one hand, C++ is an incredibly complicated language that one can invest considerable amounts of time into. It also used to occupy a unique niche where you get tons of abstraction features yet as much blazing speed as you care to spend time optimising. Rust is encroaching on that niche.
On the other hand, C is an incredibly simple language, which does not allow for convenient expressions of particular abstractions. If they hated C++ because it was too hard to follow. What the code is doing, they probably hate rust for the similar levels of abstraction affordances.
When I hear the bad faith arguments from people who really should know better, what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades, and are now feeling like their skill set is at risk of being unnecessary.
It always seemed like an unproductive attitude to have in a knowledge-based industry like software development. I am also a C++ developer, but you bet I am learning Rust on the side, because I think it's a good idea to skate where the puck is headed. I also learned enough of Zig to be dangerous a few months ago because it was fun.
Either way, I would suggest those developers reflect on the reason why they have this reflexive need to throw a wrench into any conversation mentioning rust. If their intention is to slow down adoption through hostile community sentiment, it's not working.
> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades
That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable.
Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages in roughly the same space such as Zig or Nim, or occasionally Go. They whine because they think Zig or Nim should take the place of Rust.
>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages....
>They whine because they think Zig or Nim should take the place of Rust.
How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe?
Things have died down now, doesn't mean it didn't happen.
> Things have died down now, doesn't mean it didn't happen.
I have some bad news for you. In the early 90's, C++ _was_ that language. Not only that, but at the time a lot of the reactionary criticisms of C++ by annoyed C developers had a lot more weight to them.
- C++ was slower than C, because the costs of vtables and exceptions was a lot larger and compilers weren't as good at optimizing.
- C++ was bug-ridden, both because it was easy to accidentally misuse the language, but also because compilers were simply buggy due to the complexity of the language.
- Many of the STL containers you know and love were missing from pre-standard C++, and even afterwards its implementation was commonly subpar, leading developers to either use their compiler-specific proprietary containers or roll their own.
- Streams were often the only reliable thing in the C++ standard library. It also ballooned compile times to the point of being outright banned from many codebases.
- Don't get me started on the utter nightmare that was sifting through compiler errors through misuse of templates...
So yeah, I don't want to hear other C++ developers whine about how annoying Rust developers are. We were just as annoying back in the day, with a worse language. Linus banned C++ from the kernel, and honestly he was 100% right to do so at the time.
> The C++ language has evolved quickly, with a release every three years or so.
There was a revival of C++ starting with C++11 and ending around the era of C++17. It was, frankly, great. However, a few things happened around and since C++20 that has caused the language to backslide.
First, it seems like corporate support for C++ has dropped significantly. Apple, having successfully replaced GCC with Clang for their own internal use, no longer cares that much about keeping up with the latest C++ features, choosing to prioritize Swift instead. Google seems to have slowed their contributions after being blocked from any commitments that opened up the possibility of breaking ABI. Microsoft has gutted their Visual C++ team, which has significantly slowed the implementation pace of new features and fixing bugs...unless they're related to Unreal Engine. There are also persistent rumors going around that Microsoft are working on their own project in the spirit of rustc-codegen-gcc, but for Visual Studio.
Second, it seems like a lot of the new blood that the revival decade had attracted to the C++ community and standards committee have stopped participating and given up. There's probably not one or two all-encompassing reasons for this, but the disconnected stories I keep hearing about just leave me feeling sad for the future of C++. Anecdotally, the ones that I see that are most commonly cited up are the horrendous rollout of C++ modules, the drama surrounding Safe C++ vs Safety Profiles, and the circling of the wagons around rot13_content_warning("pbaivpgrq puvyq encvfg") Arthur O'Dwyer.
If I had to pick one own-goal in particular that ground my gears from a technical perspective, it's the ordeals of the developer who tried to get `std::embed` into C++. Going through the standardization process was such a nightmare for her - including trying to convince the standards committee that it was a problem worth solving in the first place - that she eventually gave up and took the idea to the C standards committee instead. After a few rounds of back-and-forth feedback, C23 now has #embed. Not only did C get the feature before C++, but the C++ standards committee gave up whatever say they had in the shape of the final product.
That's not to say that I'm not looking forward to certain modern C++ features. Concepts are great, even if they fall well short of the original proposal. I use std::span and std::expected in every project I can, even if I have to use third-party polyfill libraries to deliver them. Modules could be nice when they're more widely supported. But _man_ the future of C++ looks pretty bleak from where I'm sitting, and it seems like the people in a position most able to do something about that future aren't making wise decisions.
Agree with a lot of what you said. Definitely to a lot of corporations C++17 was the peak of the language. Apple prioritized Swift afterwards and Google started doing Carbon and begrudgingly accepted Rust.
First time hearing about the embed issue and god that person’s experience is awful: https://thephd.dev/finally-embed-in-c23 and it feels like a job for only the best project managers.
An earlier Google blog post from the same series (link in the first sentence) pointed out why: new code tend to have more vulnerabilities than established code. So it makes more sense to write new code in Rust than to rewrite old code in Rust. After all new features are still being added and new code needs to be written; it’s not like the codebase is done with features.
According to that blog post (https://security.googleblog.com/2024/09/eliminating-memory-s...), the vulnerability density for 5 year old code in Android is 7.4x lower than for new code. If Rust has a 5000 times lower vulnerability density, and if you imagine that 7.4x reduction to repeat itself every 5 years, you would have to "wait" (work on the code) for... about 21 years to get down to the same vulnerability density as new Rust code has. 21 years ago was 2004. Android (2008) didn't even exist yet.
I also feel like this is good advice when making a language shift, or any _other_ shift, even a stylistic one.
A lot of my coworkers get in this situation where, when a change in direction is made, they feel like we have to stuff the roadmap with work to rewrite everything. That work is... 0 value, in most cases, unless the decision we have made is intended to directly solve an issue in the existing code.
Many times I find that if you just do new work in the new thing, you'll "naturally" prioritize rewriting at the right rate. When we do it that way, we end up replacing, rather than rewriting, those legacy systems, which avoids the pitfall of trying to reproduce prior behavior, down to the bugs it may have had.
>So it makes more sense to write new code in Rust than to rewrite old code in Rust.
This is a general result regardless of what language you're talking about (unless you're really downgrading to assembly or something crazy). This of course presumes that the overall Rust (or other new language) situation is better than the existing one. It's not generally.
The blog post has a number of issues, including mixing C and C++. And Android C++ source code is often filled with C-style code, especially the older the code, and is not always that good in several aspects.
Many of the files in that commit have a lot of C-style code, yet are classified as C++. C and C++ are very different programming languages, and memory safety is arguably significantly easier to achieve in practice in C++ than in C, yet in the blog post, C++ is blamed for C-style code, and C and C++ are not differentiated.
Compare and contrast with https://android.googlesource.com/device/generic/goldfish/+/d... . That source code file has much more modern C++. Though even then, it contains goto, and modern C++ code reviews would normally not accept goto in my experience. I do not understand what Google Android is doing when its developers are using goto. Could they not have used lambdas in those places where they are using goto? The mixture of std::string_view and goto, modern and yuck, is disconcerting.
On a different topic, how much of the new Rust code is vendored dependencies? Is Fuchsia included?
Maybe the real value for Google Android that Rust holds, is that it mostly prevents C-style code from being written. And Rust does not support goto, and while I think an argument could be made that goto is OK to include in a toolbox, its usage should be very, very, very, very rare. Why does somewhat modern Google Android C++ allow goto?
I am not impressed by Google Android's C++ code quality. Are Google Android developers, independent of language, significantly below average?
C++ does have baggage, cruft and issues. But having strange C++ code (like goto) and also blaming C++ for C-style code, does not help paint an honest and accurate image. And if Google Android's C++ code review process accepts goto willy-nilly, I do not consider Google Android to be at all credible on any subject related to code quality, memory safety and security in any programming language.
The difference is that with Rust one can prevent unsafe in the compiler build settings.
Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language.
With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.
Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues.
> as if there isn't any other memory safe language.
But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.
Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.
And even for memory-unsafe languages like Rust, there are trade-offs.
> Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust.
What definition of memory safety are you using where (supposed) "necessity" and "prevalence" are factors, and at what thresholds for those two factors do languages cross from unsafe to safe or vice versa?
> In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
So you have Rust, which uses unsafe code for performant collections, and Java, which uses unsafe code via its JIT for performant collections. I'm not sure I see a substantial difference here.
> But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.
Everything else aside, why is no_std included here?
no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.
And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of constraints relative to resources or bugged infinite recursive calls without tail-call optimization, can do it.
> no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.
I think you're technically correct, though I also think the picture is a bit more complicated than you paint it. From my understanding, stack overflow protection needs cooperation between (at least) a language, its runtime (if present), and the environment the program is run in. In other words, I'm not sure any language can "protect the stack completely" without knowledge of the environment it's going to be run in, so at least technically speaking I don't think Rust is any different here.
That being said, rustc will insert stack probes even when compiling with no_std, so in environments where stack probes are sufficient to protect against stack overflow/stack clashes no_std is safe with respect to that particular issue.
> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.
We're decades into the global warming era. You simply can't make some people accept evidence if the conclusions from that evidence would be uncomfortable to them.
If people don't take exploitability seriously, you can't make them. Well, unless you keep pwning them.
People are worried about half-assed[0] rewrites that break functionality and introduce exciting, new vulnerabilities due to improper implementation. And they aren't wrong to fear that, given the multiple issues we've seen in just the past week with Ubuntu's Rust overhaul.
[0]: Or even whole-assed. Memory (un)safety is only one form of vulnerability.
They were half-assed in the sense that they trusted the old test suite, which turned out to be a mistake, as some edge-cases weren't covered. Hopefully they will be more rigorous going forward, but even then, these bugs were caught before being added to a stable release, so overall fine.
I'm not sure if it is the best ROI to rewrite battle-tested tools in Rust, but it isn't like people are forced to do it. People have fun writing Rust, and want to work with it more, so that's the direction these projects take. And if you don't want to use these tools, the beautiful thing about Linux is that if you don't like the direction a distribution takes, you can always switch.
I think that it would be foolish for any software engineer to completely dismiss any technology. There is a time and place for any tool, and it is a job of a competent engineer to determine what the appropriate combination of these is that would solve a certain problem within specific constraints.
That said, memory safety is one criterion out of many that could be used to make that decision. For a large number of software projects, memory safety simply isn't a major concern. Ease of use, iteration speed, developer familiarity, availability of specific libraries, and so on, are often equal or greater concerns than memory safety.
So, sure, if you're writing a kernel, operating system, or a mission-critical piece of software, then Rust might be worth considering. Otherwise, you might be better served by other languages.
We're in C23 nowadays, and in Linux distributions there are plenty of npm like drama, one apt/dnf install away with pkg-config, or vcpkg/conan for the more modern folks.
Although I imagine there are a few still stuck in ./configure land.
> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.
Because it's not a silver bullet. That safety comes at a cost; Rust is much more difficult to learn than C or Zig and the compilation time for code with equivalent semantics is an order of magnitude greater. It has also added a great deal of toolchain complexity to projects like the Linux kernel.
People have decided that the pros outweigh the cons in those particular cases, but those cons exist nonetheless.
Rust is more difficult to learn the basics of than C, but I'm not sure it's more difficult to learn to write memory-safe code in Rust than in C. It's also not clear to me it's that much harder to learn Rust than it is to learn how to write equivalently-high-level code in C++ _unless you end up in one of the areas where Rust is really hard_. But a lot of systems code doesn't end up in those areas. Some does, and then you have to go fishing for a crate that does things for you. C++ just has a lot of corners you can get sucked into, and the legacy mix of multiple generations of C++ coding styles / OO stuff makes for some really tangled messes out there.
(fwiw, I teach undergrad systems programming in C, I use Python at the startup, and I use a mix of C/C++/Rust in research.)
I would personally much prefer to use Rust for code exposed to external untrusted input than to use C. I have substantially more confidence that I would not add exploitable bugs given the same time budget.
My favorite framing for this is that rust front loads all the pain.
C and C++ are incredibly subtle languages. But you can get a lot of code written before you run into certain foot guns in C and C++. This gives those language a more enjoyable on-ramp for beginners.
In comparison, rust is a wall. The compiler just won’t compile your code at all if you do anything wrong. This makes the act of learning rust much more painful. But once you’ve learned rust, it’s a much smoother experience. There’s far fewer ways for your programs to surprise you at runtime.
At least the Rust compiler gives pretty good advice on what is going wrong. And for complete beginners, agentic AI can soften the pain a lot if used correctly. By used correctly I mean the following work flow:
1) Design in correspondence with AI. Let it criticise your ideas, give you suggestions on tools/libraries/techniques, and have concepts and syntax explained to you. Stay aware that these models are sycophantic yes-machines.
2) Implement yourself.
3) Debug in collaboration with AI. If you ask a question like "I'm getting [error], what are the most likely reasons for this happening?", you can save a lot of time finding the issue. Just make sure to also research why it is happening and how to solve it independently.
4) Let AI criticise your final result and let it offer suggestions on what to improve. Judge these critically yourself.
There is some worth in spending hours trying to fix a bug you don't understand, it builds resilience, helps you get familiar with a lot of language topics, and you probably won't make the same mistake again. But the above approach is a pretty good compromise of letting AI help where it excels, while still keeping enough control to actually learn something yourself.
I believe that Rust is the language benefiting the most from agentic AI, because the compiler is such a strong gate-keeper, and the documentation of almost all aspects of the language is comprehensive and clear. The biggest pain points of Rust are also reduced by AI: Front-loaded learning curve is softened, refactoring is something gen AI is actually decent at, and long compile times can be spent productively by already planning out the next steps.
> I believe that Rust is the language benefiting the most from agentic AI
Except in my experience, chatgpt and claude both struggle to write rust code that compiles correctly. Chatgpt is pretty good at complex tasks in typescript like "Write a simple snake game using (web framework x). It should have features X and Y". Its can be surprisingly good at some complex problems like that.
If you try the same in rust, it often fails. I've also had plenty of situations where I've had some complex borrowing error in rust code, and chatgpt just can't figure it out. It goes in loops. "Oh I see the problem. Sure, this should fix it ..." except the "fixed code" fails in just the same way.
I'm not sure why. Maybe there's just not enough rust code in the training set for chatgpt to figure it out. But rust is definitely a weakness of the current generation of models.
The pain will always remain when refactoring or changing code, with modifications cascading in the function and type definitions.
If a language is hard to write at first, it’s always hard to write. The saving grace of C++ is that one mustn’t use the overcomplicated functional aspects, template meta-programming, etc.
Through some amazing circumstances, all of the above (or their equivalents) + async is exactly what idiomatic Rust code has become.
Inside Rust there is a not so ugly language that is struggling to come to light and it is being blocked at every step.
> If a language is hard to write at first, it’s always hard to write.
That seems obviously false. Most fancy programming languages are difficult to write at first, C++ included. But they all get easier over time.
Rust got way easier to write over time for me. I'm soooo much more productive in it now compared to when I started. Does C++ not get easier to write over time too?
A significant amount of Rust’s “new” features over the last years have been “yeah if you tried to use x and y together, that didn’t work, but now it does.” From an end user perspective, a lot has been made more straightforward over time.
This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software that meets a particular set of requirements and those requirements include resilience to handling untrusted inputs.
Of course adding an additional set of tooling complicates an environment. I'm sure that was the case for Google in adding Rust to Android as well. And yet - it seems to have proved worth it. And I suspect that in the long term it will prove likewise for Linux, because Linux shares the same requirements and has a similar threat model it needs to guard against.
"This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software"
A lot of your argument assumes that you've already have an entire working build environment readily available. If this is not the case, what used to be a fairly straightforward C compile now becomes an massive ordeal
Is it harder to learn than C? For sure it is a bit harder to get started. But is it also harder to learn than writing proper C(++?) with the same amount of quality in terms of lack of bugs ?
C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.
> In C, you just need to know what a struct is and what a pointer is.
Suppose we have a team of experts busily analyzing every single state of the code. They are reading/valgrinding/fuzzing/etc.-- in real time as the intermediate developer writes code.
Each time the developer tries to compile, the team quickly votes either to a) remain silent and leave the dev alone, or b) stop compilation because someone thinks they've discovered an invalid read/write or some other big no-no that the compiler will not catch (but the Rust compiler would catch).
If they choose b, the experts stop for a bit and discuss the clearest way to communicate the hidden bug. Then they have a quick conversation with the intermediate developer. Suggestions are made, and the whole process repeats.
Is this process substantially faster than just learning Rust?
> to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.
It is misguided to say that recursive data structures should be easy to write. They are difficult to reason about and the Rust compiler is right to point this out. CS is not engineering, you should be writing those trees with a pencil on a piece of paper as Dijkstra intended, not in C.
How often do you DIY a self-balancing binary tree? Sure I wrote a few in college, but in the real world you are almost always just using an existing library. Optimizing for edge cases like that doesn't make sense.
And is your hand-written C implementation going to be safe and correct. You didn't mention any kind of locking or atomic operation, so is it going to unexpectedly break in a multithreaded environment?
The concepts of Rust are definitely more complicated, but in practice it just means that C makes it easier to shoot yourself in the foot. It's easy, but is that really the most important thing here?
This assumes a perfect student who is not going to make any mistakes while writing their code, not even a typo. If an error is introduced, things become much harder on the C side. The compiler may miss it. It could manifest as a bug that only occurs in certain non-obvious circumstances, and manifests erratically (e.g. an out-of-bounds write clobbering data of a node next to it in the heap). Rust would most likely just not allow such a bug to be introduced.
In the same vein, driving on a modern busy road requires you to know about lanes, speed limits, various signs, traffic lights, rules of turning and merging, etc, etc. A road without all of that, where a steering wheel plus two pedals suffice, of course still allows you to drive, and drive fast, but it requires much more attention from a driver; many driver's mistakes are noticed later, and lead to more dangerous accidents.
> For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics.
This assumes a self-balancing binary tree must have nodes with parent pointers. Without those you don't need reference counting and without that you don't need `RefCell` either.
It does look like a silver bullet, actually. In the context of software engineering, "silver bullet" inevitably leads to Fred Brooks:
'"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."
Reducing memory-safety vulnerabilities by 5000x compared to the prior approach is not just a silver bullet, it's an arsenal of silver bullets.
> the compilation time for code with equivalent semantics is an order of magnitude greater
The time it takes to write and run the comprehensive tests for C and Zig code to demonstrate anything even approximately in the ballpark of what Rust gives you for free is a multiple orders of magnitude greater than whatever time you spent waiting for the Rust compiler. Why care about the time it takes to compile trivially incorrect code, rather than caring about the total time it takes to produce reliable software, which is demonstrably lower for memory-safe languages like Rust?*
Who said that anyone is absolved of the responsibility to write tests for business logic when using Rust? I struggle to see anything in the comment you replied to that is anywhere close to claiming this
>"There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire."
Nah. For me it induces vomit. Any time the vulnerability is mentioned a horde will arrive promptly and sing "rewrite the ... " in Rust.
For fuck's sake. We got it. We know it is mostly memory safe with bunch of other protections baked in. So go and rewrite it and then try to sell it to your customer and have them pay for this job. If you succeed - congrats, good for you and for the "victims". If not - stop nagging people who have other things to worry about.
One who has tried the language and hates it can completely dismiss it. Memory issues can be fixed in ways that don't involve rewriting millions of lines of code and the ensuing chaos, feature degradation, retraining, etc. that goes with it.
It's not just the headaches, it's the smugness with which they tell us that C and C++ are too bad to be used and the only solution is to throw it all away and start over. I've seen some smug language evangelists before, but Rust has the worst. It's just too much work to rewrite everything and retrain everyone, for the sake of maybe preventing this one category of error. Calling memory errors "unsafe" is also a bit of a stretch.
It's one class of bugs. This is not enough information to make a technical decision. Logic bugs still exist. It's not clear if these are easier or harder to create in Rust. There is some existing evidence to suggest that object oriented programs make it easier to create logical errors and emergent bugs.
So, that's why I completely dismiss it, it fraudulently attempts to champion Rust as an obvious replacement of anything. For those who think this has something to do with Rust specifically, no, we've held these reservations for promised replacement languages for decades now. There is no evidence Rust's borrow checker alone has overcome enough of the problems of any previous example.
A short criticism of Rust is, for a supposed systems language replacement, they let far too many features and first party magic (cargo) into the language.
70% of bugs in a large mature c++ code base come from memory safety bugs. Yes it's not the only type of bug, but it sure is the majority. Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful. Rust enums make it easier to associate state with specific states, option types actually force you to check if they are valid, result types force you to check for errors, etc. Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits.
> 70% of bugs in a large mature c++ code base come from memory safety bugs.
Are 100% of those exploitable? This single ended statistic is simply not useful.
> Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful.
You have proof of this?
> Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits.
That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.
And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.
Bugs don't need to be exploitable to be a problem. The program is incorrect and invariably will fail to act correctly due to those bugs.
Modern c++ has none of the advantages I mentioned. std::variant is cumbersome to use and you cannot easily match on it exhaustively, std::optional and std::expected have UB if you look at the stored types without checking if it's valid first. I love c++ and still use it daily, but I also know I write more bugs when I use it compared to rust. I don't have hard proof that rust is less prone to other types of bugs but wouldn't be surprised if someone produces a blog post with evidence. If you're trying to make judgement without experience, then that's simply foolish.
I'm not sure why you would point to "bigness" of the language as a problem when you're fine with considering c++ a systems language. If you don't like cargo, you don't have to use it. There are other build tools that can integrate with the rust toolchain the same way you would do so with c++. If some libraries are not suitable, don't use them. There are plenty of c++ libraries like boost which I avoid because they don't work well for me too. Consider the way in which The Linux kernel is using rust the language. The key to whether a systems programming is useful is whether I can meet the constraints the software must run in, typically in terms of binary size, memory usage, and runtime performance. Rust delivers here and can be used anywhere c/c++ have found success.
> That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.
Are the advantages in those cases (option/result) properly realized when it's just piled on top as something you could do?
I still have to be wary that, for instance, std::strchr could return a nullptr which I might pass on without handling. Plus even with std::optional<T> it's on me to remember to check val.has_value(), else it's undefined behavior to access.
Whereas in Rust, s.find() must return an Option<usize> because there's no null for it to return otherwise, and accessing the inner value (`match`, `if let`, ...) requires handling the Option::None case.
> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.
Large compared to C or Zig, but not compared to C++.
Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that complexity there is extra room for non-memory safety related bugs.
There's probably also 500x more people who know c to a given level then know rust to a given level.
If we have an analyzer that can find memory safety bugs in C, we could also just put that in the CI pipeline, or as a pre-submit hook before you're allowed to add code to a code base.
This idea that if Rust doesn't have all those memory safety bugs it must somehow have loads of other bugs we haven't discovered reminds me of Americans insisting that countries which don't have their lousy gun safety problems must have the same effects by some other means they haven't detected - Like, OK England doesn't have lots of gun murders like America, but surely loads of English people are just dropping dead because someone threw a yoghurt at them, or used harsh language, and we just missed them off our statistics ?
No man, it is possible to just do better, and this is an example of just doing better. The Rust is just better software. We can and should learn from this sort of thing, not insist that better is impossible and the evidence suggesting otherwise must be a mirage.
You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all. That's just a basic requirement of what it means to write in those languages.
The graph about reverted code also addresses the "illegible bugs" argument.
As for an analyzer, that's what ASAN is. I hope I don't need to explain why that's not a universal solution (even though everyone should be using it).
The comment I'm responding to implicitly assumes memory safety violations are like other bugs where that it's meaningful to speak of programs being more or less correct depending on the number of issues. What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all. It's more like parsing paint splatters as perl [0]. You might get something resembling what you want if you're lucky, but you also might not depending on how the compiler feels that day.
The code shows main immediately calling a nullptr. What the compiler generates is a program that calls unreachable() instead. These are two different programs. If memory safety is "just" a bug, this would be a miscompilation. It's not a miscompilation though, because what I've given the compiler is something that resembles C++, but is actually some similar language where null dereferences are meaningful. The compiler only knows about C++ though and C++ doesn't have nullptr dereferences, so it assumes I haven't done that. Instead it generates a program corresponding to an execution trace that is valid C++, even if it can't see the call to NeverUsed(). If you use -O0, you get the segfault as expected.
A single instance of memory unsafety (or other UB) can take your program arbitrarily far from "correct". All other things being equal, a program with 1 violation might be just as incorrect as a program with 100. I could add a hundred more lines of safety violations after Do() without changing the compiled behavior. You don't even need to execute the unsafety to have "spooky action at a distance" cause that change.
Many Rust proponents are experienced C and C++ developers who have dealt with this situation for decades. Given the language, it's understandable that compilers make the choices that they do. It's also understandable that programmers find it unreasonably difficult to reason about code written in such a language.
> What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all.
This isn't really correct and many programming language standards (including that of C and C++) don't support this view. Many language standards define a notion of conformance. Strictly conforming programs aren't allowed to invoke behaviors that which are undefined[1].
Conforming programs do not have this requirement and basically any non-trivial C and C++ programs are written to this rather than the notion of "strictly conforming".
Most non-trivial programs are not strictly conforming (including some C compilers themselves), generally because restricting the set of targets to something smaller than "any possible C implementation" is useful.
It is perfectly legal (and very desirable in cases where the standards fall short of usefulness) for a C compiler to define undefined behavior. What you compiled is still a C program, just one that isn't portable across the entire potential set of implementations.
[1]: Or unspecified or implementation-defined, for that matter, but this part tends to get left out of discussions.
The C++ ISO document describes conforming implementations of their language, ie compilers and similar tools - that conformance isn't a property of your program at all.
So far as I can tell there is no mention of the program conformance you're describing.
There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation. In theory you could have an implementation that gives semantics to UB like Fil-C or CCured do. No mainstream implementation does that for memory unsafety due to the performance overhead, and conforming implementations are required to document those extensions. I don't think there's a sane argument for an implementation to intentionally choose the behavior in the example I provided and Clang certainly doesn't, so it's non-conformant regardless.
> No mainstream implementation does that for memory unsafety due to the performance overhead
It depends on what is considered memory safety here (especially when some of them are arguably unforced errors in the standards), but many implementations do in fact have options for this ("no delete null pointer checks" for example is an example of one such option, for example, which is used extensively by the Linux kernel for example).
The performance impact tends to be much more negligible outside of, sometimes contrived, benchmarks, especially when compared to algorithmic efficiencies or the like.
> There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation.
Perhaps it "basically" says that, but it certainly doesn't appear to literally say any such thing, so you're going to need to specify where you believe you saw this so that I can have any idea what it actually says.
A conforming program is one that is acceptable to a conforming implementation.
That definition goes all the way back to C89. The C++ standard drops it for the term "well-formed program", but adds enough clarifications in 1.4 to mean essentially the same thing.
Ah, no. Most C++ programs that compile are not well-formed programs. This functions as an escape hatch for Rice's Theorem. You see, C++ even more so than C has semantic requirements - but Rice says all non-trivial semantic requiremnts are Undecidable. So, if you want what C++ says it wants it appears that compilers would be entirely impossible and that's awkward. To "fix" that C++ says it's fine if the compiler will compile your program even though it is not well-formed, the program doesn't have any meaning of course, only well-formed programs have meaning, but it did compile, so as a programmer you're happy...
C++ has a recurring phrase in its standard document "Ill-formed No Diagnostic Required" or IFNDR which carries this intent. The compiler can't tell you made a mistake, but you didn't actually write a valid C++ program so -shrug-
Because there's no way to tell for sure without exhaustive human examination we don't know for sure how many C++ programs aren't actually well-formed but experts who've thought about it tend to think the answer for large C++ software projects is all or most of them.
Chances are, a Rust implementation of certain things may be simpler than C implementation. C is a low-level language, so you have to do more housekeeping, and express things obliquely, via implementation, vs expressing things more declaratively in Rust.
Being simpler is not a given though.
"Knowing C" as being able to read and understand what's happening is quite separate from "knowing C" as being able to write it competently. Same thing with Rust: an algorithm written in rust is far from impenetrable for a non-expert, and even someone who sees Rust the first time but has enough experience with other languages.
The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.
C is not simple, it is inept. There are so, so many bargain-bin features and capabilities that it just cannot do that it ends up creating much MORE complex code, not less complex code.
I mean, just the pretense that simple tool = simple engineering isn't necessarily true. Building a home using an excavator and drills is fairly straight forward. You know what's complicated? Trying to build a home using only a screwdriver. Yeah. Good luck with that, you're gonna have to come up with some truly insane processes to make that work. Despite a screwdriver being so much more simple than an excavator.
Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.
C++ and Rust? Easy. Templates and generics. C? Up until a few years ago, your options were: 1. copy and paste (awful) or 2. use void * (also awful).
Copy and paste means your implementations will diverge and you just artificially multiplied your maintenance burden and complexity. And void pointer completely throws away any semblance of type safety, forces you to write stupid code that's way more complex than it needs to be, and, to top it off, is horrible for performance!
That's just one example, but there's so, so many when you look around C++ or Rust enough. And these are not rare things, to me. To me, these are everyday coding problems.
Anonymous functions? There's another one. Encapsulation? Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.
> Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.
And Rust is significantly better at this than C++ for the simple reason that mut is a modifier. I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it, and, as readers, we’re left wondering whether things actually need to be mutable, or the author forgot/didn’t know to add const-ness to their code. With Rust having opt-in mutability, you know for a fact that mutability was a deliberate choice (even if sometimes the only motivation was “make the compiler happy”).
> I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it
Adding const to _function-local_ variables only really matters when you "leak" a pointer or ref, whether mutable or const, to a function or variable the compiler can't optimize away:
std::size_t sz = 4096;
const std::size_t &szRef = sz;
some_opaque_func(szRef);
if (sz != 4096) std::abort(); // cannot be optimized away unless sz is const
as there is no way to know if something obtains a mutable ref to sz down the line.
In other cases like RVO, adding const is actually detrimental as it prevents the move-constructor from being selected (likewise with the move assignment operator).
Rust _needs_ to have const by default due to its aliasing model ("only one mutable ref per object") and you can't have cheap bound checks without this. But that, too, is a tradeoff (some classes of programs are hard to code in Rust)
Pretty sure the std::abort() can't be optimized away if sz is mutable since it's legal for some_opaque_func() to cast away szRef's const and modify sz via that. sz itself needs to be const for the if statement to be removable as dead code.
> The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.
This, this, this.
C compilers are simple, but the C language is not, and let’s not even talk about C++.
>Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.
Do I?
I would simplify the problem to not need different types or generic operations.
Or if I really need generic operations, break them down to smaller operations so you don't need to take a bunch of type parameters everywhere.
For example containers, instead of having container<T>, have the container operations return an index or 'opcode', then the user applies that to their data. The container doesn't need to know about T, void pointers or sizes, just its own internal bookkeeping stuff.
I like to focus on the ways that C is actually quite complicated, especially the complications that directly provoke UB when you don't know about them. Integer promotion and strict aliasing are at the top of my list.
To be honest I feel like "this code is easier to review and less likely to require rollbacks" is even more of a valuable take from this article, just in terms of "hey, don't you like it when things don't have to be rolled back?"
Security issues are like bad etc too, just we've heard the security spiel so many times at this point. I just think it's nicer to write most stuff in Rust.
Yes, Rust's strictness makes it a lot more maintainable. It is so much more common that changing the one thing you wanted to change results in a compiler error at every single other site you need to change, without having to look at other areas of the codebase at all, and all the tests pass on the first try.
I don't know much about how it got started. I'm curious how much of Rust's capabilities depend upon recent CS breakthroughs. Could we have made Rust in 1990?
The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
No. Only massively oversimplifying, Rust could be described as a bunch of ideas pioneered among functional languages coming back to C++, the same way Java was a bunch of ideas from Lisp coming back to C. There is very little that's truly new in Rust, it's just mixing a bunch of features that were not often together before.
> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
What makes Rust slow to compile is largely independent of what makes it unique. A lot of text has been written about this, but the again massively oversimplified version is that had the designers cared about compile times when the language was being designed and the compiler written, you could have something that's very similar to Rust but also very fast to compile.
> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
As I understand it, a lot of the slowness of the rust compiler comes about from llvm. And how rust and llvm interoperate. Rustc creates and sends gigabytes of stuff to llvm - which passes all of that to its optimizer. If you skip all that work - for example by running cargo check - the compiler is an order of magnitude faster.
If rust were invented in the 90s, it wouldn’t have used llvm. Rust could still have been implemented, and we’d probably have a much faster compiler as a result. But it would have missed out on all the benefits of llvm too. It would have needed its own backend to be written - which would have been more work. And the compiler probably wouldn’t have been as good at low level optimisations. And it probably wouldn’t have out of the box support for so many target platforms. At least, not from day 1.
> The obvious(?) question is why it sends gigabytes of stuff to llvm
IIRC it's a combination of technical debt from earlier in Rust's life (it's easier to generate naive LLVM IR and let LLVM's optimizer do the heavy lifting of chewing through that) and how Rust implements generics via monomorphization
> and if that can't be reduced somehow.
I believe the technical debt bit can be (and is being!) reduced by implementing optimizations and better IR generation in rustc itself. As for the monomorphization strategy, I thought I remembered reading something about how Rust technically allows for generics to be implemented via non-monomorphization strategies like type erasure/dynamic dispatch, but I can't seem to find that post/article/whatever it was now so I'm not sure I'm not making it up. That being said, there are patterns to reduce the amount of code generated (e.g., generic facade that forwards to a non-generic implementation), but those need to be manually implemented at the moment and I don't think there's significant work towards automating that at the moment.
For the latter, the term you want to search for is polymorphization. It is about making the compiler do the work that those manual façades do, automatically.
I think the answer is probably that Rust was possible in the 1980s and 1990s, but such a thing just wasn't practical.
Rust is notoriously compiler-intensive. That wouldn't have been tolerated in the early PC era. When you needed fast compilers that "worked on my machine" and should work on yours. Ship it.
It wasn't really possible. We had neither the PL techniques nor the computational power to make something like Rust work at the time. All the answers people are throwing around showing it would have been possible rely on a garbage collector and require a runtime, or have many other unacceptable compromises (e.g. no use after free because you aren't allowed to free).
We did, it was called OCaml. If we'd had any sense we'd've rewritten all our systems code in it. But since C had bigger numbers on microbenchmarks, no-one cared.
One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system.
So the answer is no, because humans’ collective expertise of programming language theory simply isn’t enough in 1990, unless Rust developers independently invented such features instead of copying them from GHC Haskell.
> One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system.
I submit that those advanced features are at most a tiny fraction of why projects like OP are seeing benefits from moving to Rust. E.g. I wouldn't be at all surprised if this Rust on Android project isn't using type families at all, or is using them only in an incidental way that could be replaced without significantly compromising the benefits.
Any Rust code longer than ~20 lines uses Rust iterators which use type families. The Iterator trait in Rust has an associated type called Item. This is the innovation here. Classic type classes can only contain functions not types. It was in 2005 that a paper was written to show how having a type inside a type class makes sense, including how it can be type checked (via entailment of type class predicates with type equality), type inferred (by changing the standard HM system to return partial type equality constraints in addition to substitutions).
Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.
Are associated types type families? I'm not sure. They seem more similar to functional dependencies to me. But I'm only familiar with type families from Haskell so maybe I'm missing some broader context.
Yes they are type synonym families. And yes they are quite similar to functional dependencies because it is conceived as an alternative to functional dependencies but it expresses the programmer’s intent more clearly.
> Classic type classes can only contain functions not types...
> Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.
True, although I'm not sure how much difference it makes in a language with first-class modules. But more importantly, how much difference does it make at the point of use? As far as I can see the overwhelming majority of Rust iterator code looks pretty much the same as one would write in OCaml, or Java.
All of the memory safety stuff is independent of the trait system, to the best of my knowledge, but the data race protection is implemented through the Send and Sync traits. I'm unsure if there is an obvious alternative approach to this same feature, but I think it may be one innovation that is still novel to Rust and would not have existed in earlier decades.
Yes, exactly. It's tragic that the only way programming culture ever improves is when a language comes out that's better for writing software in and happens to also have bigger numbers on microbenchmarks.
I think you're generalizing a bit too much. Rust targetted the audience that wanted big numbers on microbenchmarks, but not all languages do. Typescript for example has no performance advantage against Javascript, but it became very popular due to the better dev experience. Kotlin is another example where that mattered a lot.
Yeah, I am blown away. Assuming that these stats are true/verifiable, this spells real doom for C++. What is the point of C++ in 2025 except to maintain a large, existing source code base? Else, you should be doing everything that you used to do in C++ in Rust.
> What is the point of C++ in 2025 except to maintain a large, existing source code base?
Half of useful things to do are impossible or plain cumbersome to write in rust given the semantics and constraints of the borrow checker. Try to write self referential structures in rust and you'll have a more nuanced opinion.
I’ve written self-referential structures in Rust with the ouroboros and self_cell crates. It was fine, and I got way more guarantees I got it right compared to C++.
That’s entirely the point, though. Rust compiler is of the opinion that recursive data types are hard and I don’t think it can be reasonably argued that this opinion is incorrect.
Feel free to use unsafe {} when you need it, though.
Note that N=1 for the memory safety vulnerabilities they had with Rust, so the error of the estimated average number of vulnerabilities per LOC is quite large.
Your best guess is that the true rate is 20x higher than the observed rate? This seems unlikely to me given the number of samples (outside of systematic biases towards certain types of memory safety bugs that probably apply to C++ code too). 10 per hundred MLOC is closer to what I would have guessed too, but that is because I've historically been very conservative with my assumptions about the memory unsafety rate per unsafe LOC being similar to that of C++. The evidence here suggests that the true rate is probably much lower than that.
I'm making a conservative guess, which is why I said 10 or less (10 or fewer??). So the improvement is at least a hundredfold. I might say 5 or less instead. I think the exact rate is not so important; either way, it's clear that Rust is a boon.
Large C++ codebases have the same problems that large codebases have in any language: too many abstractions, inconsistent ways of doing things, layers of legacy. It comes with the job. The difference is that in C/C++, hard-to-read code also means hard-to-guess pointer lifetimes.
If the C++ code I worked on looked like that[1] and was actually C with classes, then I’d be switching to Rust too.
For Google and Microsoft it probably makes sense to rewrite Windows and Android in Rust. They have huge amounts of legacy code and everybody’s attacking them.
It doesn’t follow that anyone else, or the majority has to follow then. But that’s predictably exactly what veteran rustafarians are arguing in many comments in this thread.
[1] Pointers getting passed all over the place, direct indexing into arrays or pointers, C-style casts, static casts.
That (PVOID)(UINT_PTR) with offsetting and then copying is ridiculous.
They found a memory safety bug in their Rust code and assumed it was the only memory safety bug in their Rust codebase. And then they compared it to the historical average in C++ code that's been around for almost two decades in production. I can't be the only one here who sees how biased this comparison is right?
Rather, they found one memory safety bug in their Rust codebase, and measured it against the legions of memory safety bugs they found in their C++ codebase. In neither case are they measuring against bugs not found, so no, it's not biased.
Except it's not an apples-to-apples comparison. The C++ code has been around a lot longer, and a lot of it was written with older versions of C++ which didn't have modern safety features. I'm sure there is a bunch of new/delete in their codebase still. And I'm sure they're actively looking for memory safety issues in C++, and probably not so hard (if at all) with Rust.
They made an earlier report where they found out that older C/C++ code has actually a lot less new vulnerabilities compared to new code, so I guess here they are comparing to new C/C++ code to get the higher ratio, meaning the comparison should actually be apples-to-apples.
Is it a usual thing you do that when you're given data about a literal thousandfold improvement, in a context where there are well-understood theoretical and practical reasons why you might have expected to see such an improvement, you make up reasons why it is actually not an improvement at all, without either investigating to see whether those reasons are actually true or demonstrating that even if they were true, they could possibly explain more than a tiny fraction of the improvement?
I usually am skeptical about a literal thousandfold improvement, yes. And I'm not saying it's impossible, but rather that the data and the way it's presented has inherent biases. Its on the people making grandiose claims to prove them.
The fact that the safe subset of Rust can indeed be made safe, and that unsafe code can be encapsulated like this, have already been formally verified. This is an empirical demonstration that matches these formal results across a large company with a large amount of code (technically, it exceeds them, but this is only under the assumption that memory safety issues per line of unsafe Rust are identical to memory safety issues per line of C, which is really an unwarranted simplifying assumption).
Do you really believe that "they're not actively looking for memory safety issues in Rust" is (1) true (at least outside of Google, there is actually a ton of security work done specifically targeting just the unsafe blocks, since those are obviously where the memory safety issues lie) or (2) could possibly be responsible for a literal thousandfold reduction in memory safety issues? Remember that the Rust code is often integrated with C++ code--there is not necessarily a way to just test the C++ part even if you wanted to. Additionally, Google has explicitly prioritized code that interacts with untrusted data (like parsers and networking code) meaning it's likely to be easier to fuzz most of this Rust code than most new C++ code.
Also remember that, again, there are mechanized proofs of memory safety for a large subset of the safe portion of Rust, which constitutes 96% of the code under consideration here. The rate of memory safety bugs would have to be 25x as high per LOC in unsafe Rust code as in C code for the number of vulnerabilities to match. It would be far more shocking if we didn't see a dramatic reduction. Google is empirically demonstrating that the observed memory safety bugs per line of unsafe Rust is actually far lower than per line of C, but my point is that even if you think that is the result of bias or them not applying the same scrutiny to Rust code (something that is certainly not true of Rust vs. C code in the wild), the effect of this underrepresentation cannot possibly explain most of the reduction they observe.
Google deployed numerous state of the art mitigations prior to adopting Rust and still found that 70% of their CVEs were due to memory safety issues--your assertion that they are engaged in motivated reasoning and just wanted Rust to work out is pretty ill-founded. In fact when I worked for Google prior to Rust's release, they were strongly averse towards adopting any new language and believed that good engineering practices, automation, and a rigorous review process always outweighed the benefits of adopting a new language past their core ones, whatever its purported reliability or performance benefits. Security researchers are highly skeptical as a rule of these sorts of claims and have a lot of say at Google. They themselves changed their minds based on this sort of internal evidence.
I agree that skepticism is warranted, because we are constantly being sold things by industry. At a certain point, though, when the effect size is massive and persistent and the mechanism extremely clear, that skepticism (not in general, but of a particular claim) becomes the unscientific position. We are well past that point with Rust wrt memory safety.
If you want something more comparable, they estimate that only 5% of their Rust code is within unsafe blocks. That makes only 5% of the code with potential for memory safety issues: that's already a 20x improvement. Let's make it 10x because unsafe blocks tend to be trickier, but you still get a lot of Rust guarantees.
The thing is with Rust, you know where to look for memory safety issues: the unsafe blocks. C and C++? GLHF that's your whole codebase. As they mentioned, you don't opt-out of all of Rust guarantees by going the unsafe route. Of course you can ditch them, but that'll be hugely visible during code review. Overall, you can be much more confident saying "yup there's no bug there" in Rust than in C or C++.
Even if they are off by a factor of 100 it's a huge win and the point stands.
It's fair to point this out and worth the mention. Still, I'd like to think that the engineers behind this can at least gauge the benefit of this endeavor with some accuracy despite the discrepancy in available data, and stating the data that is available only makes sense.
and they found 1000 memory safety bugs and assumed it was the only 1000 memory safety bugs in that code which have been in production for 2 decades. How naive can they be?
Further up they refer to Android C/C++ code, not C/C++ in general:
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code."
Which means they had a pretty poor code base. If they had spent more time on engineering and less time on features that are canceled after 12 months anyway, they could have written better C/C++.
I peruse Android system code at work and their C++ code base is not designed for safety. It’s just typical C++ code as any large company would write it.
And for a large juicy target like Android, that won’t be good enough to stay ahead of the attackers long term.
Of course, tools like Fil-C or hardware-based security might make Rust vs. C or C++ moot.
Edit: your comment makes a good point. Shame that trigger-happy (c)rustaceans are downvoting everything in sight which is not praising this PR piece disguised as a technical blogpost.
While crashing is better than exploitable behavior, catching bugs at compile time is even better. Neither hardware based strategies nor filc actually find bugs at compile time. Also the conversation with respect to security isn't about migrating old code, but what to use for new code that you write.
I will note that developers also feel more productive in rust. That's why they migrate existing things over to it even when it may not be beneficial for security.
Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore.
Of course, I am exaggerating a bit - and I am not even that experienced with Rust.
But after coding with Ruby, JS/TS and Python - it feels refreshing to know that as long as your code compiles, it probably is 80-90% there.
Rust is the most defect-free language I have ever used.
I'd wager my production Rust code has 100x fewer errors than comparable Javascript, Python, or even Java code.
The way Result<T,E>, Option<T>, match, if let, `?`, and the rest of the error handling and type system operate, it's very difficult to write incorrect code.
The language's design objective was to make it hard to write bugs. I'd say it succeeded with flying colors.
Now try an actual functional programming language. I like Rust too but those features all come from FP, and FP languages have even more features like that that Rust doesn't yet or can't have.
> Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore.
I found that at some point, the rust way kinda took over in my head, and I stopped fighting with the compiler and started working with the compiler.
One big source of bugs in TS is structural sharing. Like, imagine you have some complex object that needs to be accessed from multiple places. The obvious, high performance way to share that object is to just pass around references wherever you need them. But this is dangerous. It’s easy to later forget that the object is shared, and mutate it in one place without considering the implications for other parts of your code.
I’ve made this mistake in TS more times than I’d like to admit. It gives rise to some bugs that are very tricky to track down. The obvious ways to avoid this bug are by making everything deeply immutable. Or by cloning instead of sharing. Both of these options aren’t well supported by the language. And they can both be very expensive from a performance pov. I don’t want to pay that cost when it’s not necessary.
Typescript is pretty good. But it’s very normal for a TS program to type check but still contain bugs. In my experience, far fewer bugs slip past the rust compiler.
Appreciate it, that makes a lot of sense. I feel like I've been trained to favor immutability so much in every language that I sometimes forget about these things.
Yes, immutability is great for safety. But the copies you have to make to keep everything immutable extracts a price in copies and garbage collection.
Rust is advertised as having fearless concurrency. That's true, but not that important as concurrency is not that common. What's important to everyday programming is Rust provides fearless mutability. The fearless concurrency you get with that is just a bonus.
Fearless mutability provides Rust the same safety as a functional language in a without the speed or space cost. IMO, it's Rust's true secret sauce.
Similar. I mostly design my code around something like pipe and lifetime. The longer something needs to live the closer it is to the start of the program. If I need to mutate it, I take care that the actual mutation happens in one place, so I can differentiate between read and write access. For anything else, I clone and I update. It may not be efficient and you need to track memory usage, but logic is way far simple.
Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data.
Also, many built in functions do not have sufficient typesafey like Object.entries() for instance
That is an issue with how TS works, but it can be significantly improved upon by using a library to verify the structure of deserialized data. zod is one example, or you could use protobufs. Fundamentally, this is an issue with any programming language. But having your base "struct"-like type be a hashmap leads to more mistakes as it will accept any keys and any values.
I disagree that this is an issue in every language - the problem is that in other languages the validation against some schema is more or less required for unmarshalling, and it's optional in TS.
Seeing a deserialization error immediately clues you in that your borders are not safe. Contrast that with TypeScript, where this kind of issue can lead to an insidious downstream runtime issue that might seem completely unrelated. This second scenario is very rare in other languages.
I don't know Rust, and I'm genuinely curious: How does it improve over that problem?
When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types?
TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?
It validates the object shape at runtime, much like you can do in Typescript with a library like Zod. The key difference in this case is that Rust makes it scary to not validate data while Typescript will gladly let you YOLO it and blow your legs off, even in strict mode.
It’s not. And trying to just be a transformation of the source to JS without its own standard library (mostly, some old stuff doesn’t follow this) means it really isn’t possible with just TS alone.
That’s OK with me. I use TS because I like it and hate the total lack of safety in JS. I have to use JS on the web, so TS it is.
If I don’t need it to run on a webpage, I wouldn’t be writing it in TS. I like other languages more overall.
If you type correctly at border of your system, then TS will be very close to a formal verification of your code. This won't catch all bugs, but even broad categories for you data is helpful. If you know your input is a non-null string. Then it will warn you of every non string usage. It won't catch whether it's a name or an email, but knowing someone tries to divide it by zero is helpful.
Typescript doesn't even support notions like "unsigned integer". It is not a serious attempt at type-safety; its main claim to fame is "better than raw Javascript" which is not saying much.
I’ve never been a JS on the server person, I was used to other languages when that was developed.
Well I think I would prefer python, but simply because it’s “more traditional“ and I realize that’s specious reasoning, I prefer to use strongly typed languages whenever possible.
I would generally reach for Java since it’s the language I’m most proficient in due to my career. There’s also Go, which I played with long ago, or maybe I’d try Rust.
This is only for anything important. If I was just toying with something locally I’d probably do whatever was fastest. In that case Python or JS might be my choice for a very tiny script.
Note that Google still doesn't have official support for using Rust in Android userspace, though.
Despite all pluses on the blog, NDK only supports C and C++ tooling, same on Android Studio, and it is up to the community to do the needful work, if anyone feels like using Rust instead.
Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using Rust or anything else so long as it plays by the rules.
By first party support, would you be expecting a Rust toolchain shipped in the NDK, or maybe Rust bindings shipped in the NDK?
I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io.
Or maybe they should ship scripts that shell out to an existing Rust toolchain.
The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.
I'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated.
Both Gradle and CMake have a strong late 1990's smell to them. While CMake is sort of a necessary evil in the C/C++ world, there's no excuse for dragging Gradle into the NDK, combining both build tools leads to a complexity explosion that rarely works and tends to break after either the NDK or SDK is updated, or somebody merely looks the wrong way at the build files.
> You can use BSD Make instead of Gradle, isn't UNIX great?
So the NDK officially supports creating an APK just with a Makefile? That would be news to me (and great news at that).
It is possible to cobble together a build process that directly calls various Android SDK command line tools to build an APK directly from a C/C++ build tool without involving Gradle, but as far as I know, most of those invoked cmdline tools are deprecated and building APKs outside Gradle is not 'supported' by the Android SDK/NDK (e.g. it may stop working at any time).
Huh? "Barely"? What are you talking about? The NDK supports compiling C++ just fine. There are CMake files, among other things, ready to use --- as well as Soong native configurations. CMake is under active development. Other toolkits are within easy reach: for example, Meson works fine. Also Bazel. Hell, even autotools can be made to work.
Sure, building C/C++ code into an .so file kinda works but that's about it, try building the APK entirely with cmake, that's simply not supported, you'll have to integrate with Gradle. The result is a complexity clusterf*ck that's a nightmare to maintain.
The NDK team should take a long hard look at Emscripten to get some inspiration how native code development is integrated into a 'native-hostile' runtime platform.
I've never understood why developers fixate on having "pure" NDK-based apps. It's really not that hard to implement Activity, Service, etc. as JVM in Kotlin or Java and call the native code via JNI. What do you think the "pure native" app layer in Android is doing if not that?
It's not about the idea of writing a pure native app, but about making it easier to build a hybrid app without an exploding build process complexity.
Emscripten is again a perfect example of how it should be done: FFI calls into Javascript are trivial (it's even possible to embed JS code into C/C++ source files), and I can build a complete hybrid WASM/JS app without having to bring in a completely different build system that's completely alien to the C/C++ world.
It even works without any build system at all since the emcc compiler/linker wrapper is also the Javascript bundler, yet the entire emcc wrapper acts like a GCC/Clang compatible compiler/linker with some extra Emscripten specific flags. The Emscripten SDK didn't jump into existance like this, the difference to the NDK team is that the Emscripten team actually listens to their users.
Interesting that you give Emacripten as example, given how badly documented its whole tooling is, and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded, unless using the Github installation from source.
The one great feature of Emscripten is that you can do:
emcc hello.c -o hello.html
...and it produces an output that's immediately runnable in a web browser instead of just a bare .wasm file which needs to be wrapped in a html with additional steps.
E.g. emcc is a drop-in replacement for gcc/clang which can be used directly in a C/C++ build tool as a C/C++ compiler and linker while still doing the right thing (producing a runnable .html).
The NDK equivalent would be a gcc-compatible compiler wrapper which can do this:
ndkcc hello.c -o hello.apk
...such a simple and obvious thing to do, yet it doesn't happen because the Android SDK/NDK developers have no clue about developer workflows outside of their precious Java ivory tower.
> and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded,
That's a feature, not a bug. It's trivial to install different emsdk versions side by side, each entirely self-contained and without polluting the system or requiring external dependencies.
The separate Java dependency also has been dropped a while ago, since the only remaining component that depends on Java is the optional Closure compiler step, and that comes now with an embedded Java runtime (as far as I'm aware at least).
Have fun justifying that Rust is "also" unsafe, with the right tools you can achieve the same in C++, if you're a great dev you can do even better, etc.
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better.
It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write.
I would like to use rust to write android apps. I don't really like the whole android studio java thing.
I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages).
That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has.
There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track.
In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMake is to wish you didn't, that way someone else would have to maintain it.
As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful.
Problem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.
Yeah; generally I find CMake rules are much easier to read and modify than autotools and makefiles. With Makefiles there’s about 18 different ways to write a rule to compile something, and I find I need to go hunting through a bunch of files to figure out how this makefile in particular defined a rule for compiling this C file in particular. CMake is much higher level. I can just see all the higher level targets, and how they’re built. Then - orthogonally - I can modify the build system that CMake uses to compile C code. It makes a lot more sense.
But I’d take cargo over any of this stuff. Cargo means I don’t have to think about compiler flags at all.
For me the ideal syntax is C/Go, just to be clear what I like.
But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...
> I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like.
I’m sorry if this comes across as dismissive, but I find it hard to take people seriously with complaints about syntax like this. Learning new syntax is really easy. Like, if you’re familiar with C & Go, you could probably learn all the syntax of rust in under an hour. The only surprising part of rust’s syntax is all the weird variants of match expressions.
Rust has some surprising semantics. Like how lifetimes work (and when you need to specify them explicitly). That stuff is legitimately difficult. But learning that if statements don’t need parenthesis is like - seriously whatever dude. If you want to spend your career never learning new stuff, software isn’t for you.
I picked up objective C about 15 years ago. The only thing most of my friends knew about it was that it had “that weird syntax”. It took no time at all to adjust. It’s just not that hard to type [] characters.
I'm very vocal that I don't like Python syntax, but I wouldn't refuse to write Python because of the syntax. If I had reason to write Python, I would grumble a bit but write the Python.
I'd say that rust has a weird level of being both verbose and terse in strange ways.
If you ever have to deal with lifetimes, then the verbosity goes up pretty significantly. And, dealing with pointers ultimately introduces multiple layers of concepts that you don't necessarily run into with C++/Go/Java.
Yet, with the type inference by default, rust can often feel shockingly terse. Doing collection manipulation is just as terse as any language you could imagine.
I think that's probably where complaints about syntax comes in.
C++ hides a lot of that complexity with move semantics, shorthands, autocoersion, and by making lifetime issues runtime problems. Languages like Go/Java/Python simply push everything onto the heap and try to avoid exposing low level memory semantics.
It's easy for me to see why someone wouldn't like rust. I think it's fine, but I'm also brain broken from perl and php.
> I'd say that rust has a weird level of being both verbose and terse in strange ways. If you ever have to deal with lifetimes, then the verbosity goes up pretty significantly.
I find rust generally more terse than both C and - especially Go, to which rust was compared upthread. Writing out lifetimes explicitly can be confusing. But I don't think it adds that much syntactic noise. Maybe 1/20 functions in my code have explicit lifetimes. That will confuse beginners, but I don't think its too bad once you're used to them.
> And, dealing with pointers ultimately introduces multiple layers of concepts that you don't necessarily run into with C++/Go/Java.
This is my #1 complaint about rust's syntax. If you ever need to interact with raw pointers within unsafe blocks, I feel like the language really fights you. It seems so strange, too - since unsafe blocks are exactly the place where it matters the most that my code is easy to read. Improving the syntax around pointers (for example by adding C's -> operator) would make unsafe blocks clearer.
It's not about learning syntax, it's about finding it generally tolerable to read. I personally find Rust syntax repulsive and would opt for a different language unless Rust was literally the only option. Thankfully it's never the only option, now or in the future.
Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.
Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function.
On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's type.
Pet peeves nitpick: it's not even a tuple. Go doesn't have tuples. It just has special-cased "multiple return values", which means that it's often impossible to just stuff the return of a function call (error value and all) into any data structure to aggregate them. You just can't do without first defining a struct since tuples don't exist in Go.
Yep Rust approach won. Pretty much every new language is adopting Result style errors and it's been adapted to plenty of existing languages.
It's a product of functional programming, and for me I can't see how you would ever want to handle errors outside of the functional programming railway-oriented style. For me it's just superior.
How is Go memory safe? Memory safety does not mean "leaking memory".
It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way.
I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bounds is not possible. But it is by no means "memory safe" to the level Rust is.
> It's absolutely possible to bork ownership and have multiple thread trample a struct.
This is specifically the one place where go is not memory safe IMO.
> It's absolutely possible to compute wrong pointer offsets.
In Go? Without the `unsafe` package (at which point you are explicitly opting out)? How? There's no pointer offset in the first place.
> It's absolutely possible to dereference nil.
Yeah, but that's safe defined behavior in go equivalent to "unwrap"ing a None option in rust. It reliably crashes. It's not like C where it's undefined behavior and you might crash of you might just corrupt random memory or have the optimizer make your code do something even stranger.
It's (really the lack of non-nil types) is one of many reasons why go doesn't produce as reliable software as rust, but it's not a memory safety issue.
> It's absolutely possible to reinterpret memory the wrong way.
My Go is a bit rusty (pun intended), so I may have misremembered, especially with the pointer offsets. (just googled it, I did remember it, sorry for the confusion).
>> It's absolutely possible to reinterpret memory the wrong way.
> Again, without the unsafe package? How?
Again my go is rusty, but I saw quite a bit of shenanigans in go with pointer casting from what's essentially a collection of void*. However perhaps those casts blow up at runtime? I'm too used to rust where it's explicit where it'll blow up.
>> It's absolutely possible to dereference nil.
> Yeah, but that's safe defined behavior in go equivalent to "unwrap"ing a None option in rust. It reliably crashes. It's not like C where it's undefined behavior and you might crash of you might just corrupt random memory or have the optimizer make your code do something even stranger.
Agreed. I conflated "safety" and "robustness" here. The existence of nil is a thorn in the language.
Right, that's the first category, "It's absolutely possible to bork ownership and have multiple thread trample a struct" resulting in undefined behavior.
I mentioned it because I often hear people (not in this thread though) that thanks to its GC preventing memory leaks, Go is memory safe. The GC's role in memory safety is preventing dangling pointers though.
Zig in spirit is essentially Go without GC. If GC is not reasonable for your usecase Zig seems like an awesome choice. Unfortunately it's probably about 5 to 10 years out from being stable enough for most people being able to write serious applications in it though (notable exceptions being Bun and Ghostty, but they have solid effort behind them keeping them up to date with Zig).
If you're focusing on safety guarantees, sure. If you measure by safety checks included by default instead, it actually has more safety checks than Go (in particular, safety checked numeric operations for overflow).
The other big thing that makes it spiritually like Go is that you follow the same pattern of: allocate resource, immediately defer deallocation.
Go has some of the worst error handling I've ever seen, even worse than most exception implementations IMO, and the type system is stupid enough that it's still very easy to write bugs. Go is only surface-level memory safe, you can definitely segfault in Go. And I mean real segfault, not nullptr dereference.
Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality.
Distributing Rust software is the pain that it is mostly because of how Cargo works. It’s pretty much impossible to sanely distribute something that isn’t a headache for downstream to consume.
> Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality.
"Absolutely awful" strikes me as wild hyperbole -- you also meant it this way as well, right? What toolchains are not absolutely awful in your mind?
Cargo isn't perfect by any stretch of the imagination -- there are a few common complaints that people have and a bunch of sharp edges (most of which have a github issue that has been open for years), but... "absolutely awful" has to be hyperbole.
Can you expand on your reasoning? Because the opposite seems to be true when it comes to projects like uv. People love the single-file executable -- easy to just compile that for a platform and have your users download it. It seems like the uv project is having a good time with that model, so I think they show it's not "impossible". Maybe they're doing something different I'm not aware of? Or maybe your use case is different, so what's impossible about your situation?
That sounds a lot like the issues some Linux distros are running into, where they expect to be able to ship one single blessed pre-compiled version of every library, and have each app load it dynamically at runtime.
But that's just not how Rust works: it's trying to fit a square peg in a round hole, and it isn't Cargo's fault that you have trouble with it.
I’ve found it a joy to use compared to CMake and friends. How does it make it harder to consume something downstream? Seems easy enough to me - just share the source crate.
Are you trying to distribute pre compiled code or something like that? I can see how that would be harder - cargo doesn’t really support that use case.
That’s a nice concrete example of something that sounds simple but is a nightmare.
Let’s be clear: the goal is to distribute a tarball which the receiver can build. Crates won’t be packaged in the target host (that’s part of Rust’s design), so we don’t have any choice but to include them too.
But there’s no simple way of gathering all of these. “cargo vendor” fetches all transitive dependencies for all platforms. So if any dependency supports windows, you end up with 400MB(!) of windows-only dependencies, even if your project doesn’t target windows. This makes “cargo target” useless.
There’s “cargo-vendor-filtered”, a huge hack around this bug, but it’s also broke in subtle ways.
In the end, if you want to distribute a tarball which a downstream can build, you can’t. Cargo works online only.
Like I said: cargo is too opaque. There’s no command to generate a list of files that it would download for a build. There’s no command to fetch all “real” dependencies. It too opaque an monolithic, doing everything in one indivisible way. This is a great experience for the developer, but awful for anyone else.
> Let’s be clear: the goal is to distribute a tarball which the receiver can build.
Thanks for clearing that up. What problem does that solve? I've never tried to do that, but I can see how it would be a pain in the neck.
I wonder how hard that would be to fix. It doesn't sound like a difficult feature to implement in cargo. I wonder how amenable the cargo devs would be to adding something like that?
Cargo is a blessing for any source-available project. All bundled up, a `cargo build` away. Because don't you dare say CMake or autotools are better, that's just the stockholm syndrome kicking in because you're familiar with it.
Seriously, how a CMakeLists.txt can even be compared to a Cargo.toml file? One is imperative full of arcane conditions everywhere filled with boilerplate, while Cargo.toml is a declarative manifest of the package?
Though there is one very sore point when distributing software, and that is for distribution package maintainers, because the whole ecosystem has been built around the C model and dynamic linking. That is not even the fault of cargo, since Rust's ABI is not stable thus dynamic linking would not work most of the time. Another thorn is generic stuff, which needs to be monomorphized, and as such don't work with dynamic linking (without Box<dyn>); C++ actually has the same issue and is why there are so many "header only" libraries for it.
The only people I’ve met who seem to think it’s a feud war are a few dyed in the wool C++ fans who implicitly hate the idea of programming anything else. Rust is just a language. It has some strengths and weaknesses just like every programming language. Some of its strengths are incredibly compelling.
Personally I’m relieved that we’re starting to see real competition to the C & C++ duopoly. For awhile there all the new languages were GC, and paid for their shiny features with poor runtime performance. (Eg java, C#, Ruby, Python, lua, go, etc etc)
Rust is a fine language. Personally I can’t wait to see what comes after it. I’m sure there’s even better ways to implement some of rust’s features. I hope someone out there is clever enough to figure them out.
> That is a surprising opinion. Rust marketing is entirely based - like in this submission - on comparing its memory safety to C/C++ and saying that C is bad!
I'm not really sure what you expect here. Like, a large driving factor of using rust (compared to C/C++) is that it has better memory safety. Should rust not talk about that? Should we try and be careful about the feelings of C/C++ devs and not name the truth in the room around memory safety?
The reason android is moving to rust is because it decreases the memory related defect rate compared to C++. Should we shy away from talking about C++ memory bugs because they're somehow embarrassing?
When C came out, I'm sure a lot was written about how much easier it was to program in compared to assembly. Does that mean there's a feud between C and assembly? I'm sure some assembly developers felt under attack. But its not a feud. Just two tools with different use cases. That's how I see C and rust.
> Even in its own "memory safety" definition, which is the first result on Google, they criticize C instead of providing a proper definition:
I'm not sure that page is intended to provide a definition of "memory safety" in the first place? It (and the following page) seem more intended to introduce safe/unsafe Rust and the boundaries between the two.
It's also from the Rustinomicon, which states:
> Unlike The Rust Programming Language, we will be assuming considerable prior knowledge. In particular, you should be comfortable with basic systems programming and Rust.
So it's arguably unsurprising that a definition of memory safety would not be found there.
My guess is that if you want a more precise definition you'd want to look at the Rust Reference (e.g., [0]) or in related areas.
The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.
The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible.
Which is a pity, because the language itself does not seem to be so bad.
> Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.
I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response.
> The Rust literature is poorly written compared to C and Ada
I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing?
I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library:
Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far.
So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:
Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.
> So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:
Why do we need links to the source code? Doxygen is already embedded in the source, you should already be reading the source code on your local machine. It makes no sense to go searching across the web for information that's already stored on your local machine. Especially since you have no idea if the version you find on the web matches the version you're using locally.
I mean we know for sure Rust is unsafe there is whole bug tracker dedicated to all the ways it's unsafe. My favorite is that you can cast any lifetime to static no matter how short it actually is in 100% safe Rust.
I think referencing the well-known cases in cve-rs[1] is quite a bad faith effort. Of course if you try reeeally hard to write unsound code, you can write unsound code. An edge case in the type system downstream of lifetime variance rules is simply not something that matters in any practical attempt to write safe software. I find the tracker interesting since it probes the boundary of the compiler, but it says absolute nothing to the effect of "Rust is unsafe".
The unsound bug tracker is were my heart gets all warm and fuzzy in Rust land.
All the ways to coerce and poke the implementation of what should be safe constructs to produce unexpected garbage - and people spending time fixing the issues because they are treated as bugs.
It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.”
This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.
I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860
Id like to see dev time in Rust vs C++, but generally, I sort of agree. If you use modern C++ with all its features, Rust is generally a better alternative.
That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.
> That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.
Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is nontrivial.
Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem.
The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold.
But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id.
So you simply have a system of tracing where memory gets used.
But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.
So your claim is that sufficiently careful C is just as safe as rust?
Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion:
> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.
C is not as memory safe as rust. And it cannot be made as safe as rust with a few bolted on tools and programming tricks.
And tell me how that pointer semantics would do
* a very strict type checking
* Pattern matching
* Algeberic data type
Plenty of people don't write Rust for additional memory safety, they write Rust because the features provided by it is overall very balanced & encourages developer to write code which handles almost all edge cases.
The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say "Rust is too hard!" and they give up.
But if you stick it out, as Google has, the dividend is that more often than with other languages, you are not paying these costs continually but instead reaping dividends on the long run.
First of all, Rust has the Haskell-like property that (as long as the logic is sound) if your code compiles, it usually runs just fine. This is why testing speeds up, because all of the edge cases that are explored during testing were already accounted for by the compiler.
It also translates into easier refactoring, where you can make sweeping changes in the codebase and feel confident that you can put it all back together again.
And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!". Fast is a feature, and your users benefit from it every time they run your code.
It's hard to find that nexus of features in other languages. Usually they are just as fast and hard to write as Rust, without the safety guarantees. Or they are just as safe as Rust, but without the speed. And that's why Rust has hit a sweet spot where other languages can't quite get it.
It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model.
One of the main features of Rust is the community, there are so many great packages
Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type theory
I agree with you as long as you don't know C++ first. I actually teach C++ and Rust to students who only know Java, and they have a much easier time picking up Rust. It's the people who approach Rust with C++ idioms who have the wort time with it. It comes down to the tooling, especially Cargo being the one-stop-shop for everything Rust. Another poster here laments that Cargo is too overloaded with disjoint functionality, but that's actually a benefit for a lot of learners.
I think tooling is big and people underestimate the lingering cognitive overhead of simply building C++ with arcane CMake files, but honestly it's more that much of Rust is informed by problems in C++ that they didn't have to inherit and don't have to maintain forever.
Like for example, how many ways are there to initialize a variable in C++? Which are you supposed to use?
C++ is the hardest, most difficult programming language to write correct (according to spec, not in the ‘it compiles’ sense) programs in ever created that isn’t a toy or specifically designed to be hard like malbolge. It takes a decade of writing it daily to realize that you know nothing, precisely because the compiler does not reject so many invalid programs.
>if your code compiles, it usually runs just fine.
This was the same argument for Java, which is memory safe, fairly strict in terms of ownership.
The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
The dividends never get there if you don't ever run into this.
>And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!"
This is a vibe at best. The speed difference is surely there. But it makes very little difference when there are much slower things in the entire workflow, like pulling things from the internet.
Basically, Rust is a good choice for a small subset of things. Android happens to be one of them, because a) you need native code performance, b) you have multiple teams working on many services and c) you have a somewhat closed ecosystem where you control a lot of the low level things. Because of all of this, double frees are a real threat and can pop up as you are passing data around without strict checks.
> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
Most of these will usually make a program crash. Crashes are testable and not a memory safety issue. Exception handling was created specifically to deal with this.
Use after free is generally VERY hard to exploit. Double free can corrupt data structures more with control. Use after free is basically at the mercy of the allocator and program state, where whatever gets written to the same memory address may or may not be relevant.
There is a reason why most vulnerabilities these days are either higher level logic bugs, or things that require code execution on the machine.
The issue with most codebases is nobody thinks about starting out with acceptance testing system.
The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on.
This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And things like memory and cpu runtime constraints are a part of this.
If you have this, you basically replace what the Rust compiler is doing for you with tests. Memory leaks are caught. However, as a benefit, you also can verify changes in the dev cycle with things like performance degradation, all in the same system.
I'm not sure that nobody thinks of this. We just have a finite amount of time. Usually with a solid approach, you get solid performance. Fixing a performance related bug rarely when it comes up, is still a time savings over designing this kind of rigorous process from scratch, and getting everyone on board with it.
Getting rid of a whole host of bugs due to the compiler is a big deal because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. If you can solve this seamlessly I think that's an interesting product that others would be very interested in.
> because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it.
This is just a matter of tooling. (On that note, here is a free business idea, prompt engineer an LLM agent that sets this up for you)
While the compiler does do a lot of things for you, you still end up with things that you should check because compiler doesn't understand your program logic. If Rust was a absolutely strict typed language, where basically everything had a type that defined what data it could hold, then it would be a different story. For example, when parsing a json into an object, instead of strings/numbers/bools, every single field has a finite set of values that it can hold. Then the compiler can figure out a lot of things. For example, if you try to convert a string to int, if the string field type doesn't have a defined regex expression it must match, then the compiler can catch this.
Anything less then that, you are better of writing the validation system once and reusing it for all your code bases now and in the future.
> The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests …
Sometimes. It depends on what you’re working on.
Part of the fun challenge in writing software is that the act of programming can teach you that you’re wrong at every level. The syntax can be wrong. The algorithm you’re implementing can be wrong. The way you’re designing a module can be misguided. And you might be solving the wrong problem entirely! Like, maybe you spend weeks adding a feature to a game and it makes the game less fun! Oops!
Tests formalise beliefs about what you want your code to do, at some level of abstraction. But if those beliefs turn out to be wrong, the tests themselves become a headwind when you try and refactor. You want those early refactoring to be as easy as possible while you’re learning a problem space.
Now, some programs don’t suffer from this as much. If you’re implementing a C compiler or drop in replacement for grep, you have some clear acceptance tests that will almost certainly not change through your project’s lifecycle.
But not all problems have clear constraints like that. Sometimes you’re inventing a programming language. Or writing a game. Or making a user interface. In my opinion, problems that are fully constrained from the start are some of the least interesting to work on. Where’s the discovery?
> Part of the fun challenge in writing software is that the act of programming can teach you that you’re wrong at every level. The syntax can be wrong. The algorithm you’re implementing can be wrong. The way you’re designing a module can be misguided.
I see you sir haven’t had experience with writing drivers for prerelease hardware. You’re right in these cases of course, you just aren’t right enough - the real fun starts when you can trust neither the hardware, nor the BIOS, nor the OS in addition to all the above.
I will simply say that Google is one of the few places that, to a first approximation, has this. We have our (pretty good) suite of tests. We can run only affected tests. We can them with instrumentation (*SAN), we can run them under various memory and CPU limits, we can run them 1000 times in parallel to deflake.
Anyway Google has all of that, and yet still finds this improvement.
Writing the tests before the code only really works if there's an interface that's fully defined and well specified in advance. There are definitely times where that is the case, but in my experience it usually doesn't work like that.
It doesn't work like that because people are afraid to change things up. Lots of time people want to see working code that works for nominal use cases before hand.
Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already.
If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.
At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills.
I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.
> The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation
Yes, this is the biggest issue with Rust that I've seen; most language will let you do something wrong and then as you learn you get better. Rust will refuse to compile if you're not doing things correctly (and normally I would put 'correctly' in quotes but correctness in Rust is well defined).
The first time I tried to experiment with learning Rust was a disaster. I just wanted to decode some JSON and filter it, but -- oops! -- I don't own that variable. Okay, well I can pass it somewhere else mutably, right? But then that function does the work and returns something that... what's a lifetime? What's a 'a mean? How do I... screw it, I'll go back to Python.
Eventually, after the tooling and the tutorials got better I came back to it and really enjoyed what I've seen so far and even rewrote one of my own personal tools in Rust[1] to experiment with. It's nothing impressive, but it was fun to do.
The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense.
On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.
Oh, the more junior the developers, the quicker they will get any benefit. That's common for any language that enforces correctness, but the C++ vs. Rust comparison isn't even fair; C++ is an incredibly hard language to use.
Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever.
Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default!
Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.
While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using
For example: folks are more likely to rewrite stuff that is well-understood, and stuff that is well-understood is going to have shorter review times and lower rollback rate.
That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more rollbacks, and less likely to be rewritten.
The first chart does in fact a compelling reason to believe the effect is not that at all. If the "easy" code was predominantly being rewritten you would expect to % new memory unsafe code and % memory safety vulnerabilities to scale at different rates as the difficult to work on areas remained in C and kept causing new memory vulnerabilities.
Personal experience also provides a compelling reason, my experience is absolutely that people are more inclined to rewrite the things that are causing trouble in a new language.
It's not a blinded randomly controlled trial of course, it's observational data. You can't be completely sure there isn't a confounding factor that explains the data, but it seems far more likely than not that it is a real effect.
I haven't looked at Googles style for c++ in a long time, but from what I remember it was actively hostile to best practices. Actively hostile to any improvement introduced by the language and actively hostile to the wider ecosystem of c++. Also Rob Pike was involved somehow at the time and that guy went around claiming that his C inspired GCed language would be the perfect replacement for C++ everywhere after the c++ standard simplified some common patterns for library authors because he was actively hostile towards reusable code.
I am not sure I even want to know what the average Google C++ codebase looks like.
I don't see a contradiction between the statement that vulns in C++ code are generally on a downward trajectory, and the statement that most vulns are in new code.
This is basically the C++ treadmill for decades and I think people are starting to realise they were duped.
Bjarne's C++ promised that if you use this instead of C you won't have these problems. The problems persisted of course. Then it was well you need to use standard C++ 98 not that crap pre-standard C++ you've been doing, once you adopt C++ 98 the problems will subside. Then it's you need "modern" C++ 11, of course you've got problems, that's because you used C++ 98, use this "modern" C++ instead.
By around 2020 they started to say the "modern" C++ 11 wasn't up to it, you need to write "contemporary" C++ 20 or better.
What was it George W Bush told us? "Fool me once, shame on...shame on you. Fool me...you can't get fooled again".
> That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more rollbacks, and less likely to be rewritten.
I'd say that this is likely the most likely to be rewritten actually, because high test coverage is a massive enabler in such a rewrite, and because having a project that “only a few greybeards grok” sounds like a big organizational liability.
That being said, and while I'm pretty convinced that Rust bring massive benefits, I agree with you that these measurements shouldn't be taken as if it was a rigorous scientific proof. It's more of one additional anecdotal evidence that Rust is good.
> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion.
Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?
> In science, you go out of your way to control for confounding factors.
There's tons of observational science done in a very similar fashion to the article where there is simply no way to control for confounding factors for the same reason that there is simply no way to properly control for it in the data available.
It’s a good start and even if error bars are wide enough to land a 747 in them their numbers show orders of magnitude scale differences. This should raise eyebrows at the very least in the biggest skeptics.
Going out of your way would involve committing unethical experiments, which is absolutely frowned upon by scientists.
And many experiments are simply impossible to do in a manner that completely removed every outside factors. But that doesn't mean that an experiment's results are immediately bad.
Having been close to someone who went through the PhD process to a career in research, this is a sadly common but romantic and incorrect view of science as practiced in the world today.
So, I'm not being romantic. I'm being realistic. And I'm happy to call B.S. on a lot of published research, because doing so gives me more predictive power than that research
I'm the first one to be annoyed when political scientists and economists pretend to do science when they are just extrapolating from anecdotal correlations, but here this isn't something being published in a scientific journal and nobody claim they are doing “science” in the first place.
This, from my limited experience working on AOSP at Google, only the newer code were being written in Rust, not the existing code. But that was 2 years ago.
> Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust, making it easier for Chromium engineers to deal with data from the web
I find this surprising, isn't Wuffs[1] (also made by Google) an even better fit for this particular use-case? (It has compile-time spatial memory safety, where Rust has compile-time temporal safety but runtime spatial safety, with bound checking).
Obviously for general-purpose system programming, Rust is a no-brainer and I'm happy to see Google pursuing their rustification of Android.
I don't find it surprising, just from barriers to adoption: "Wuffs programs take longer for a programmer to write, as they have to explicitly annotate their programs with proofs of safety" is a hard sell (even if it has obvious value) and "you have to learn and integrate yet another language just for parsing files" is a hard sell too.
Which isn't to say that it shouldn't be adopted (having not used it I really don't know), just that it's not surprising that it's having difficulty gaining traction.
If you're parsing untrusted data, then some level of runtime checking is unavoidable. And Rust's pretty good at letting you encode "I already checked this and therefore don't need to check it again" into the type system.
Rust is good, don't get me wrong, but bound checks are still reason why you occasionally need unsafe to get the maximum performance, because not everything can be expressed as an iterator where bound checks are automatically eliminated.
If you check Wuffs repo, you'll see benchmarks very favorably comparing to rust implementations.
And it's not surprising, wuffs is to spatial safety what the borrow checker is to temporal safety. And regarding spatial safety rust is kind of like where C++ is in terms of temporal safety: it has the choice between unsafe or runtime check hopping that a large fraction of them will get eliminated by the compiler.
Always curious to hear from people doing Rust gamedev without bevy! What are the main crates you're using, and what sort of game object architecture are you going with?
I do hobbyist level gamedev in my spare time and found bevy to be a bit too much for the things I want to do.
At this point I feel like it's no longer an uphill climb to get Rust into foundational, mission-critical code adoption. The benefits are so obvious. Maybe it's just a lingering religious war?
In any case, I'm glad we're seeing more and more evidence and case-studies of why "rewrite it in Rust" isn't just a meme.
Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C!
It's all nonsense, but it would be hilarious if it weren't so ignorant.
The irony is that those haters have been doing the same speech since Ada, Modula-2 and Object Pascal early days.
Multics got an higher security score than UNIX, thanks to PL/I.
During the USENET flamewar days, they used to call programming with straightjacket languages.
Also note how proudly they keep digging out Brian Kerninghan complains against Pascal, that disregard the dialects have taken out those issues, and that while Pascal was designed for teaching, Modula-2 was already available, taking care of those pain points, designed for systems programming.
It's all correct and also pointless and irrelevant. It all boils down to "Rust doesn't fix every possible problem so why not stick with something that still has every possible problem?"
In other words, they're upset that a new thing isn't popular so they're trying to think of any argument against it, but none of their arguments are relevant. Yes, you can still write bugs in Rust; of course you can. What you can't do is write memory safety bugs in Rust, which are a huge proportion of security bugs that occur. Rust gives you a massive decrease in attack surface automatically.
This is ignoring the ecosystem, which is full of better tooling, better library packaging, better testing, and just in general an overall better language, but instead of trying to argue the language on its merits they're trying to argue that it's not perfect so why bother.
I've also heard the same arguments about C++; 'anything you can do in C++ you can do in C!', which is technically true but ignores the fact that if I want to do something C++ does it usually makes more sense to use C++ to do it rather than e.g. trying to hack the concept of objects, private methods, templates, etc. into C myself.
Yeah but 1000x less mistake ????? I mean these people behind android project is atleast one of the better engineer but jesus christ if they can improve so much then I dont know how much average joe can benefit from that
The important thing is the likelihood of mistakes getting past the compiler. According to Google's numbers the likelihood for memory safety reduces by several orders of magnitude, and the likelihood for other kinds of mistakes reduces by a factor of ~4 (depending on how you interpret their numbers).
Just saying "but you can still make mistakes" is dumb and irrelevant and it's kind of disappointing that it's such a commonly bandied non-argument that Google still had to address it in this post.
Sure, but the discussion against Rust is basically saying that you can have the same features without the downsides of using Rust, which is objectively true. For example, memory analyzers like valgrind work great.
If you assume that the only benefit of using rust is built-in valgrind, sure, but there's more to the language than preventing off-by-one errors.
If people don't want to use the language then that's fine, no problem, but a lot of people do want to use the language because it's just a great language to use as well as having memory safety.
I think they're trying to avoid rewriting things for no reason though. The things being rewritten tend to have a history of security problems or other issues that would be cause for a rewrite even if it wasn't in Rust.
That ends up being "rewrite it in Rust" because new code includes changes to existing code. A nice thing about Rust is that you can generally rewrite things piecewise there's no need to switch everything at once.
Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper.
That however is a very niche case where Rust is applicable.
The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing against its adoption for everything.
When you see shit like "[...] should be rewritten in Rust because memory safe", it shows that people have no idea what memory safety even is. There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
The downsides of Rust is that its ownership semantics are often cumbersome to write, which slows down development. Rust is also still evolving because of the stuff that happens under the hood. And for a lot of things, where network latency is dominant and cpu cycles are spent sleeping waiting for responses to come back, you don't need natively compiled code in lieu of python or node that are way more flexible and faster to develop in.
So in most cases, Rust is not applicable, when you can write perfectly memory safe code faster.
There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
This is effectively true in C and C++ though. Show me a nontrivial project in either of those languages that has never had a memory safety issue and I'll show you a project that doesn't look at quality. Even SQlite doesn't meet this bar, despite incredibly skilled programmers and an obsessive commitment to quality.
There's been over a thousand memory safety CVEs in the kernel this year alone [0], the most recent published 2 days ago. Most of these aren't exploitable and are caught before stable, so I went to LWN instead and "scrolled down" until I saw an article that mentioned a memory safety vuln in stable kernels. "Scrolled down" is in quotes because there was no scrolling involved. Today's Friday security updates post links USN-7861-3 [1], which includes fixes for memory safety issues like CVE-2025-37838 [2].
If you say that something can happen, then whether to use a tool to mitigiate it should also be qualified. The conversation around Rust is that bugs WILL happen, which is not true.
Lol, this is actually very ironic considering Rust is handholding you because you don't have the skills to write memory safe code.
Like I said in my other posts, Rust makes sense in very niche situations. The article just proves that it works for the niche case where its applicable. That doesn't mean Rust automatically wins.
Readers, feast your eyes on direct evidence of how facts don’t change people’s minds. You can almost see him putting fingers in his ears and going lalala
My friend told me he likes writing rust because he loves doing things that have already been done his senior pushed management to rewrite in rust and got approved after 2 months, he jokingly told him I guaranteed us a job for the next 3 years rewriting will take time. One paycheck collection strategy push Rust -> get adoption -> rewrite code (now memory safe yay) -> collect paycheck rewriting . In the meantime others will write memory unsafe code for you which is new and provide you a paycheck guarantee and the rust compiler helps you take your time when rewriting you can read the old code while it compiles.
I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both.
Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code written in 2022 actually increased, with rust not really having gained any significant momentum.
How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".
Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
> How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".
The first graph considers <memory unsafe> vs <memory safe> languages, while the second graph considers C++ vs Rust. There's more languages than just those two in the first graph.
Moreover the first graph is in percentage terms, while the second graph is in absolute terms.
In 2022 it appears a bunch of memory safe non-rust code was added. Java/python/...
> Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
I’m a little perplexed why every time something in rust compiles, there’s a blog post about it. I was under the impression Ada, especially when using provers, has been around much longer and is more robust. I just can’t decide if the massive Rust evangelism budget is a red flag or just a curious sociological case study, but I wish I knew the truth.
Rust has the twin features of significant technical merits and a powerful hype machine. In truth, it's neither the devil nor the best thing since sliced bread. It has enough traction that the tooling and developer experience are always improving, and appeals to a wide range of uses. Rust was lucky enough to get noticed when it was decent pre 1.0, which motivated the community to make it excellent at 1.0, and it's been making history ever since. I think Rust got critical mass because it had a bold vision and focused on developer experience enough to get buy in on improving its performance and robustness. Ada is wonderful, but it's less pretty, and doesn't make pretensions. In that sense, Rust was built for the hype, but the language has benefitted greatly from all the attention.
The history is kind of weird. Graydon was ejected out of his own language and then a machine took over. That is really unusual, and I’m not sure there is an analog anywhere.
That's not what happened at all. Graydon voluntarily stepped down because he didn't want to be in the role of BDFL. It's true that he wasn't a huge fan of the "C++-ification" of the language, but he wasn't pushed out or anything, and definitely could have stayed on steering the project as long as he wanted to. I think there are a number of other languages that would have benefited from a similar approach, actually.
> I’m a little perplexed why every time something in rust compiles, there’s a blog post about it
Crucially Rust is a very pleasant developer experience. Out of the box tooling is smoother, the compiler diagnostics are much better than peer languages†, the community are nicer, and so on. When you wrote safe Rust which compiles you get software that does what you wrote and not something else, which seems like a very basic thing to ask for but neither C nor C++ can do this. People respond well to a more pleasant environment.
† I wrote the one where if you write 'A' (the Unicode character capital A) but actually meant the ASCII byte 65 the diagnostic suggests writing b'A' instead rather than just telling you that what you wrote is a type mismatch.
This was a great breakdown. Loved the different aspects they captured beyond memory safety, including the skill improvements within the team as they grew comfortable.
Rust allows us to collect paycheck rewriting code, rewriting code is so much easier since you do not have to think much about the underlying business you already have the code it's purely technical also you can just collect paycheck rewriting code for quite a while since most code bases are large easy money if you already know rust.
This would be great if it weren't such a hasty generalization. A comparative analysis against alternative approaches like continued hardening of the legacy code base would have been better to read through. This suggests there is no middle-ground to be had which we know to be false. And all this while oversimplifying legitimate engineering trade-offs like build system complexity and developer retraining costs.
Relying on Google as a credible institution rather than independent verification results is what can only be described as self-evident truth. This is corporate tech evangelism that only benefits Google.
Why does the article avoid adoption barriers due to Rust's steep learning curve? Why does the author gloss over maturity gaps in the toolchain? Why isn't there feedback included from the maintainers of the critical components like HALs and other drivers?
Rust is older today than the K&R Book on C was when Windows, Linux and NextStep were started. Although C was started earlier, it wasn't widely known about until after said book... Let alone C++
There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire. And while, like any technical decision, there are pros and cons, I cannot see why in the face of astounding evidence like this, you would completely dismiss it.
And I say this as someone who has never written a line of Rust in their life (some day I'll find the time).
In my experience, the loudest critics of Rust I have heard are actually seasoned C and C++ developers who are incredibly good at one or both languages, but know almost nothing outside it.
On one hand, C++ is an incredibly complicated language that one can invest considerable amounts of time into. It also used to occupy a unique niche where you get tons of abstraction features yet as much blazing speed as you care to spend time optimising. Rust is encroaching on that niche.
On the other hand, C is an incredibly simple language, which does not allow for convenient expressions of particular abstractions. If they hated C++ because it was too hard to follow. What the code is doing, they probably hate rust for the similar levels of abstraction affordances.
When I hear the bad faith arguments from people who really should know better, what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades, and are now feeling like their skill set is at risk of being unnecessary.
It always seemed like an unproductive attitude to have in a knowledge-based industry like software development. I am also a C++ developer, but you bet I am learning Rust on the side, because I think it's a good idea to skate where the puck is headed. I also learned enough of Zig to be dangerous a few months ago because it was fun.
Either way, I would suggest those developers reflect on the reason why they have this reflexive need to throw a wrench into any conversation mentioning rust. If their intention is to slow down adoption through hostile community sentiment, it's not working.
> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades
That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable.
Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages in roughly the same space such as Zig or Nim, or occasionally Go. They whine because they think Zig or Nim should take the place of Rust.
>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages....
>They whine because they think Zig or Nim should take the place of Rust.
How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe?
Things have died down now, doesn't mean it didn't happen.
> Things have died down now, doesn't mean it didn't happen.
I have some bad news for you. In the early 90's, C++ _was_ that language. Not only that, but at the time a lot of the reactionary criticisms of C++ by annoyed C developers had a lot more weight to them.
- C++ was slower than C, because the costs of vtables and exceptions was a lot larger and compilers weren't as good at optimizing.
- C++ was bug-ridden, both because it was easy to accidentally misuse the language, but also because compilers were simply buggy due to the complexity of the language.
- Many of the STL containers you know and love were missing from pre-standard C++, and even afterwards its implementation was commonly subpar, leading developers to either use their compiler-specific proprietary containers or roll their own.
- Streams were often the only reliable thing in the C++ standard library. It also ballooned compile times to the point of being outright banned from many codebases.
- Don't get me started on the utter nightmare that was sifting through compiler errors through misuse of templates...
So yeah, I don't want to hear other C++ developers whine about how annoying Rust developers are. We were just as annoying back in the day, with a worse language. Linus banned C++ from the kernel, and honestly he was 100% right to do so at the time.
> Every time a language in the same space comes they get asked if they are memory safe?
So what?
It might be shocking for you, but every new messenger gets asked if it supports e2ee these days.
Why shouldn't people want to know about the availability of a massive advancement in the space of system programming languages?
And yet at the same time naming Ada is forbidden?
> The C++ language has evolved quickly, with a release every three years or so.
There was a revival of C++ starting with C++11 and ending around the era of C++17. It was, frankly, great. However, a few things happened around and since C++20 that has caused the language to backslide.
First, it seems like corporate support for C++ has dropped significantly. Apple, having successfully replaced GCC with Clang for their own internal use, no longer cares that much about keeping up with the latest C++ features, choosing to prioritize Swift instead. Google seems to have slowed their contributions after being blocked from any commitments that opened up the possibility of breaking ABI. Microsoft has gutted their Visual C++ team, which has significantly slowed the implementation pace of new features and fixing bugs...unless they're related to Unreal Engine. There are also persistent rumors going around that Microsoft are working on their own project in the spirit of rustc-codegen-gcc, but for Visual Studio.
Second, it seems like a lot of the new blood that the revival decade had attracted to the C++ community and standards committee have stopped participating and given up. There's probably not one or two all-encompassing reasons for this, but the disconnected stories I keep hearing about just leave me feeling sad for the future of C++. Anecdotally, the ones that I see that are most commonly cited up are the horrendous rollout of C++ modules, the drama surrounding Safe C++ vs Safety Profiles, and the circling of the wagons around rot13_content_warning("pbaivpgrq puvyq encvfg") Arthur O'Dwyer.
If I had to pick one own-goal in particular that ground my gears from a technical perspective, it's the ordeals of the developer who tried to get `std::embed` into C++. Going through the standardization process was such a nightmare for her - including trying to convince the standards committee that it was a problem worth solving in the first place - that she eventually gave up and took the idea to the C standards committee instead. After a few rounds of back-and-forth feedback, C23 now has #embed. Not only did C get the feature before C++, but the C++ standards committee gave up whatever say they had in the shape of the final product.
That's not to say that I'm not looking forward to certain modern C++ features. Concepts are great, even if they fall well short of the original proposal. I use std::span and std::expected in every project I can, even if I have to use third-party polyfill libraries to deliver them. Modules could be nice when they're more widely supported. But _man_ the future of C++ looks pretty bleak from where I'm sitting, and it seems like the people in a position most able to do something about that future aren't making wise decisions.
Agree with a lot of what you said. Definitely to a lot of corporations C++17 was the peak of the language. Apple prioritized Swift afterwards and Google started doing Carbon and begrudgingly accepted Rust.
First time hearing about the embed issue and god that person’s experience is awful: https://thephd.dev/finally-embed-in-c23 and it feels like a job for only the best project managers.
An earlier Google blog post from the same series (link in the first sentence) pointed out why: new code tend to have more vulnerabilities than established code. So it makes more sense to write new code in Rust than to rewrite old code in Rust. After all new features are still being added and new code needs to be written; it’s not like the codebase is done with features.
According to that blog post (https://security.googleblog.com/2024/09/eliminating-memory-s...), the vulnerability density for 5 year old code in Android is 7.4x lower than for new code. If Rust has a 5000 times lower vulnerability density, and if you imagine that 7.4x reduction to repeat itself every 5 years, you would have to "wait" (work on the code) for... about 21 years to get down to the same vulnerability density as new Rust code has. 21 years ago was 2004. Android (2008) didn't even exist yet.
Remember that there are other types of vulnerabilities too. If there are less of them in old code then it may make up for more memory issues.
I also feel like this is good advice when making a language shift, or any _other_ shift, even a stylistic one.
A lot of my coworkers get in this situation where, when a change in direction is made, they feel like we have to stuff the roadmap with work to rewrite everything. That work is... 0 value, in most cases, unless the decision we have made is intended to directly solve an issue in the existing code.
Many times I find that if you just do new work in the new thing, you'll "naturally" prioritize rewriting at the right rate. When we do it that way, we end up replacing, rather than rewriting, those legacy systems, which avoids the pitfall of trying to reproduce prior behavior, down to the bugs it may have had.
>So it makes more sense to write new code in Rust than to rewrite old code in Rust.
This is a general result regardless of what language you're talking about (unless you're really downgrading to assembly or something crazy). This of course presumes that the overall Rust (or other new language) situation is better than the existing one. It's not generally.
The blog post has a number of issues, including mixing C and C++. And Android C++ source code is often filled with C-style code, especially the older the code, and is not always that good in several aspects.
As an example, from https://android.googlesource.com/device/generic/trusty/+/c3f...
Many of the files in that commit have a lot of C-style code, yet are classified as C++. C and C++ are very different programming languages, and memory safety is arguably significantly easier to achieve in practice in C++ than in C, yet in the blog post, C++ is blamed for C-style code, and C and C++ are not differentiated.
Compare and contrast with https://android.googlesource.com/device/generic/goldfish/+/d... . That source code file has much more modern C++. Though even then, it contains goto, and modern C++ code reviews would normally not accept goto in my experience. I do not understand what Google Android is doing when its developers are using goto. Could they not have used lambdas in those places where they are using goto? The mixture of std::string_view and goto, modern and yuck, is disconcerting.
On a different topic, how much of the new Rust code is vendored dependencies? Is Fuchsia included?
Maybe the real value for Google Android that Rust holds, is that it mostly prevents C-style code from being written. And Rust does not support goto, and while I think an argument could be made that goto is OK to include in a toolbox, its usage should be very, very, very, very rare. Why does somewhat modern Google Android C++ allow goto?
I am not impressed by Google Android's C++ code quality. Are Google Android developers, independent of language, significantly below average?
C++ does have baggage, cruft and issues. But having strange C++ code (like goto) and also blaming C++ for C-style code, does not help paint an honest and accurate image. And if Google Android's C++ code review process accepts goto willy-nilly, I do not consider Google Android to be at all credible on any subject related to code quality, memory safety and security in any programming language.
Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.
That argument can be applied to unsafe Rust as well. There are code reviews, coding standards and other checks for a reason.
Though, I suppose something like C++ profiles, just for modernization, might make it much easier to enforce and track that modern C++ is used.
The difference is that with Rust one can prevent unsafe in the compiler build settings.
Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language.
With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.
Yes, so something like a modernization profile for C++ would make it easier to enforce, and would not require external tools. But it ultimately does not change that C++ is not C, and that the blog is deeply misleading. Nor does it change that Google Android source code appears to have significant issues.
> as if there isn't any other memory safe language.
But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.
With that line of argumentation there are no safe languages, we should all go back to Assembly.
Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
This is not a theoretical exercise. https://materialize.com/blog/rust-concurrency-bug-unbounded-... .
AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.
And even for memory-unsafe languages like Rust, there are trade-offs.
> Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust.
What definition of memory safety are you using where (supposed) "necessity" and "prevalence" are factors, and at what thresholds for those two factors do languages cross from unsafe to safe or vice versa?
> In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.
So you have Rust, which uses unsafe code for performant collections, and Java, which uses unsafe code via its JIT for performant collections. I'm not sure I see a substantial difference here.
> But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.
Everything else aside, why is no_std included here?
no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.
And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of constraints relative to resources or bugged infinite recursive calls without tail-call optimization, can do it.
> no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.
I think you're technically correct, though I also think the picture is a bit more complicated than you paint it. From my understanding, stack overflow protection needs cooperation between (at least) a language, its runtime (if present), and the environment the program is run in. In other words, I'm not sure any language can "protect the stack completely" without knowledge of the environment it's going to be run in, so at least technically speaking I don't think Rust is any different here.
That being said, rustc will insert stack probes even when compiling with no_std, so in environments where stack probes are sufficient to protect against stack overflow/stack clashes no_std is safe with respect to that particular issue.
For example, this short program:
Produces stack probes on e.g., x86_64-unknown-linux-gnu [0]: [0]: https://rust.godbolt.org/z/rcdvj8j4KBTW; Do you know if it is possible to track new comments to Hacker News threads?
I used https://hnreplies.com/
> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.
We're decades into the global warming era. You simply can't make some people accept evidence if the conclusions from that evidence would be uncomfortable to them.
If people don't take exploitability seriously, you can't make them. Well, unless you keep pwning them.
People are worried about half-assed[0] rewrites that break functionality and introduce exciting, new vulnerabilities due to improper implementation. And they aren't wrong to fear that, given the multiple issues we've seen in just the past week with Ubuntu's Rust overhaul.
[0]: Or even whole-assed. Memory (un)safety is only one form of vulnerability.
They were half-assed in the sense that they trusted the old test suite, which turned out to be a mistake, as some edge-cases weren't covered. Hopefully they will be more rigorous going forward, but even then, these bugs were caught before being added to a stable release, so overall fine.
I'm not sure if it is the best ROI to rewrite battle-tested tools in Rust, but it isn't like people are forced to do it. People have fun writing Rust, and want to work with it more, so that's the direction these projects take. And if you don't want to use these tools, the beautiful thing about Linux is that if you don't like the direction a distribution takes, you can always switch.
I think that it would be foolish for any software engineer to completely dismiss any technology. There is a time and place for any tool, and it is a job of a competent engineer to determine what the appropriate combination of these is that would solve a certain problem within specific constraints.
That said, memory safety is one criterion out of many that could be used to make that decision. For a large number of software projects, memory safety simply isn't a major concern. Ease of use, iteration speed, developer familiarity, availability of specific libraries, and so on, are often equal or greater concerns than memory safety.
So, sure, if you're writing a kernel, operating system, or a mission-critical piece of software, then Rust might be worth considering. Otherwise, you might be better served by other languages.
I dont so much dismiss the technology as the people who insist on rewriting everything in rust.
Rust seems to attract a certain mindset of mediocre programmers who yell "security" to shove their poorly written slower code down our throats.
Most of them seem to be former web developers who bring all their npm drama to stable C foundations
Stable where?
We're in C23 nowadays, and in Linux distributions there are plenty of npm like drama, one apt/dnf install away with pkg-config, or vcpkg/conan for the more modern folks.
Although I imagine there are a few still stuck in ./configure land.
Any C program shipped with GNU Autotools is fairly straightforward to package as a Deb or rpm
> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.
Because it's not a silver bullet. That safety comes at a cost; Rust is much more difficult to learn than C or Zig and the compilation time for code with equivalent semantics is an order of magnitude greater. It has also added a great deal of toolchain complexity to projects like the Linux kernel.
People have decided that the pros outweigh the cons in those particular cases, but those cons exist nonetheless.
Rust is more difficult to learn the basics of than C, but I'm not sure it's more difficult to learn to write memory-safe code in Rust than in C. It's also not clear to me it's that much harder to learn Rust than it is to learn how to write equivalently-high-level code in C++ _unless you end up in one of the areas where Rust is really hard_. But a lot of systems code doesn't end up in those areas. Some does, and then you have to go fishing for a crate that does things for you. C++ just has a lot of corners you can get sucked into, and the legacy mix of multiple generations of C++ coding styles / OO stuff makes for some really tangled messes out there.
(fwiw, I teach undergrad systems programming in C, I use Python at the startup, and I use a mix of C/C++/Rust in research.)
I would personally much prefer to use Rust for code exposed to external untrusted input than to use C. I have substantially more confidence that I would not add exploitable bugs given the same time budget.
My favorite framing for this is that rust front loads all the pain.
C and C++ are incredibly subtle languages. But you can get a lot of code written before you run into certain foot guns in C and C++. This gives those language a more enjoyable on-ramp for beginners.
In comparison, rust is a wall. The compiler just won’t compile your code at all if you do anything wrong. This makes the act of learning rust much more painful. But once you’ve learned rust, it’s a much smoother experience. There’s far fewer ways for your programs to surprise you at runtime.
At least the Rust compiler gives pretty good advice on what is going wrong. And for complete beginners, agentic AI can soften the pain a lot if used correctly. By used correctly I mean the following work flow:
1) Design in correspondence with AI. Let it criticise your ideas, give you suggestions on tools/libraries/techniques, and have concepts and syntax explained to you. Stay aware that these models are sycophantic yes-machines.
2) Implement yourself.
3) Debug in collaboration with AI. If you ask a question like "I'm getting [error], what are the most likely reasons for this happening?", you can save a lot of time finding the issue. Just make sure to also research why it is happening and how to solve it independently.
4) Let AI criticise your final result and let it offer suggestions on what to improve. Judge these critically yourself.
There is some worth in spending hours trying to fix a bug you don't understand, it builds resilience, helps you get familiar with a lot of language topics, and you probably won't make the same mistake again. But the above approach is a pretty good compromise of letting AI help where it excels, while still keeping enough control to actually learn something yourself.
I believe that Rust is the language benefiting the most from agentic AI, because the compiler is such a strong gate-keeper, and the documentation of almost all aspects of the language is comprehensive and clear. The biggest pain points of Rust are also reduced by AI: Front-loaded learning curve is softened, refactoring is something gen AI is actually decent at, and long compile times can be spent productively by already planning out the next steps.
> I believe that Rust is the language benefiting the most from agentic AI
Except in my experience, chatgpt and claude both struggle to write rust code that compiles correctly. Chatgpt is pretty good at complex tasks in typescript like "Write a simple snake game using (web framework x). It should have features X and Y". Its can be surprisingly good at some complex problems like that.
If you try the same in rust, it often fails. I've also had plenty of situations where I've had some complex borrowing error in rust code, and chatgpt just can't figure it out. It goes in loops. "Oh I see the problem. Sure, this should fix it ..." except the "fixed code" fails in just the same way.
I'm not sure why. Maybe there's just not enough rust code in the training set for chatgpt to figure it out. But rust is definitely a weakness of the current generation of models.
The pain will always remain when refactoring or changing code, with modifications cascading in the function and type definitions.
If a language is hard to write at first, it’s always hard to write. The saving grace of C++ is that one mustn’t use the overcomplicated functional aspects, template meta-programming, etc. Through some amazing circumstances, all of the above (or their equivalents) + async is exactly what idiomatic Rust code has become.
Inside Rust there is a not so ugly language that is struggling to come to light and it is being blocked at every step.
> If a language is hard to write at first, it’s always hard to write.
That seems obviously false. Most fancy programming languages are difficult to write at first, C++ included. But they all get easier over time.
Rust got way easier to write over time for me. I'm soooo much more productive in it now compared to when I started. Does C++ not get easier to write over time too?
You’re mixing up developers becoming more competent with the language becoming easier.
Neither C++ nor Rust are becoming easier unless new features are added which make them simpler to use in some circumstance.
C++11 & co did make many things simpler. For Rust I don’t know the details of what’s upcoming; it doesn’t seem to be getting simpler.
A significant amount of Rust’s “new” features over the last years have been “yeah if you tried to use x and y together, that didn’t work, but now it does.” From an end user perspective, a lot has been made more straightforward over time.
How about you teach some of those students to Bootstrap a Linux cross compile both with and without rust then come back and answer this reply again
This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software that meets a particular set of requirements and those requirements include resilience to handling untrusted inputs.
Of course adding an additional set of tooling complicates an environment. I'm sure that was the case for Google in adding Rust to Android as well. And yet - it seems to have proved worth it. And I suspect that in the long term it will prove likewise for Linux, because Linux shares the same requirements and has a similar threat model it needs to guard against.
The reason it is relevant is this:
"This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software"
A lot of your argument assumes that you've already have an entire working build environment readily available. If this is not the case, what used to be a fairly straightforward C compile now becomes an massive ordeal
Is it harder to learn than C? For sure it is a bit harder to get started. But is it also harder to learn than writing proper C(++?) with the same amount of quality in terms of lack of bugs ?
C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.
> In C, you just need to know what a struct is and what a pointer is.
Suppose we have a team of experts busily analyzing every single state of the code. They are reading/valgrinding/fuzzing/etc.-- in real time as the intermediate developer writes code.
Each time the developer tries to compile, the team quickly votes either to a) remain silent and leave the dev alone, or b) stop compilation because someone thinks they've discovered an invalid read/write or some other big no-no that the compiler will not catch (but the Rust compiler would catch).
If they choose b, the experts stop for a bit and discuss the clearest way to communicate the hidden bug. Then they have a quick conversation with the intermediate developer. Suggestions are made, and the whole process repeats.
Is this process substantially faster than just learning Rust?
Edit: clarification
> to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.
It is misguided to say that recursive data structures should be easy to write. They are difficult to reason about and the Rust compiler is right to point this out. CS is not engineering, you should be writing those trees with a pencil on a piece of paper as Dijkstra intended, not in C.
How often do you DIY a self-balancing binary tree? Sure I wrote a few in college, but in the real world you are almost always just using an existing library. Optimizing for edge cases like that doesn't make sense.
And is your hand-written C implementation going to be safe and correct. You didn't mention any kind of locking or atomic operation, so is it going to unexpectedly break in a multithreaded environment?
The concepts of Rust are definitely more complicated, but in practice it just means that C makes it easier to shoot yourself in the foot. It's easy, but is that really the most important thing here?
This assumes a perfect student who is not going to make any mistakes while writing their code, not even a typo. If an error is introduced, things become much harder on the C side. The compiler may miss it. It could manifest as a bug that only occurs in certain non-obvious circumstances, and manifests erratically (e.g. an out-of-bounds write clobbering data of a node next to it in the heap). Rust would most likely just not allow such a bug to be introduced.
In the same vein, driving on a modern busy road requires you to know about lanes, speed limits, various signs, traffic lights, rules of turning and merging, etc, etc. A road without all of that, where a steering wheel plus two pedals suffice, of course still allows you to drive, and drive fast, but it requires much more attention from a driver; many driver's mistakes are noticed later, and lead to more dangerous accidents.
> For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics.
This assumes a self-balancing binary tree must have nodes with parent pointers. Without those you don't need reference counting and without that you don't need `RefCell` either.
How often do you find yourself implementing self-balancing trees in either C or Rust?
once in university
> Because it's not a silver bullet.
It does look like a silver bullet, actually. In the context of software engineering, "silver bullet" inevitably leads to Fred Brooks:
'"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."
Reducing memory-safety vulnerabilities by 5000x compared to the prior approach is not just a silver bullet, it's an arsenal of silver bullets.
> the compilation time for code with equivalent semantics is an order of magnitude greater
The time it takes to write and run the comprehensive tests for C and Zig code to demonstrate anything even approximately in the ballpark of what Rust gives you for free is a multiple orders of magnitude greater than whatever time you spent waiting for the Rust compiler. Why care about the time it takes to compile trivially incorrect code, rather than caring about the total time it takes to produce reliable software, which is demonstrably lower for memory-safe languages like Rust?*
[flagged]
Who said that anyone is absolved of the responsibility to write tests for business logic when using Rust? I struggle to see anything in the comment you replied to that is anywhere close to claiming this
> paper reports three orders of magnitude less issues, cites evidence
> baseless claims
Not even downvoting.
To me, those sound like meaningful pros and cons, not a reason to completely dismiss it.
[flagged]
But every language has those, even C.
You can just ignore those people. I’d hate to miss out on a positive technical choice because some people were being annoying about it.
[flagged]
And the evidence is: Google's PR piece.
>"There are certain places on the internet where any mention of rewriting in Rust is met with scorn and ire."
Nah. For me it induces vomit. Any time the vulnerability is mentioned a horde will arrive promptly and sing "rewrite the ... " in Rust.
For fuck's sake. We got it. We know it is mostly memory safe with bunch of other protections baked in. So go and rewrite it and then try to sell it to your customer and have them pay for this job. If you succeed - congrats, good for you and for the "victims". If not - stop nagging people who have other things to worry about.
One who has tried the language and hates it can completely dismiss it. Memory issues can be fixed in ways that don't involve rewriting millions of lines of code and the ensuing chaos, feature degradation, retraining, etc. that goes with it.
Your reply isn't necessarily "polite" but your reaction and is entirely appropriate considering the headaches these people are bringing
It's not just the headaches, it's the smugness with which they tell us that C and C++ are too bad to be used and the only solution is to throw it all away and start over. I've seen some smug language evangelists before, but Rust has the worst. It's just too much work to rewrite everything and retrain everyone, for the sake of maybe preventing this one category of error. Calling memory errors "unsafe" is also a bit of a stretch.
It's one class of bugs. This is not enough information to make a technical decision. Logic bugs still exist. It's not clear if these are easier or harder to create in Rust. There is some existing evidence to suggest that object oriented programs make it easier to create logical errors and emergent bugs.
So, that's why I completely dismiss it, it fraudulently attempts to champion Rust as an obvious replacement of anything. For those who think this has something to do with Rust specifically, no, we've held these reservations for promised replacement languages for decades now. There is no evidence Rust's borrow checker alone has overcome enough of the problems of any previous example.
A short criticism of Rust is, for a supposed systems language replacement, they let far too many features and first party magic (cargo) into the language.
70% of bugs in a large mature c++ code base come from memory safety bugs. Yes it's not the only type of bug, but it sure is the majority. Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful. Rust enums make it easier to associate state with specific states, option types actually force you to check if they are valid, result types force you to check for errors, etc. Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits.
> 70% of bugs in a large mature c++ code base come from memory safety bugs.
Are 100% of those exploitable? This single ended statistic is simply not useful.
> Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful.
You have proof of this?
> Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits.
That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.
And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.
> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.
I'm not entirely sure where this idea even comes from. Why would it be desirable for a systems programming language to be sparse on features?
Bugs don't need to be exploitable to be a problem. The program is incorrect and invariably will fail to act correctly due to those bugs.
Modern c++ has none of the advantages I mentioned. std::variant is cumbersome to use and you cannot easily match on it exhaustively, std::optional and std::expected have UB if you look at the stored types without checking if it's valid first. I love c++ and still use it daily, but I also know I write more bugs when I use it compared to rust. I don't have hard proof that rust is less prone to other types of bugs but wouldn't be surprised if someone produces a blog post with evidence. If you're trying to make judgement without experience, then that's simply foolish.
I'm not sure why you would point to "bigness" of the language as a problem when you're fine with considering c++ a systems language. If you don't like cargo, you don't have to use it. There are other build tools that can integrate with the rust toolchain the same way you would do so with c++. If some libraries are not suitable, don't use them. There are plenty of c++ libraries like boost which I avoid because they don't work well for me too. Consider the way in which The Linux kernel is using rust the language. The key to whether a systems programming is useful is whether I can meet the constraints the software must run in, typically in terms of binary size, memory usage, and runtime performance. Rust delivers here and can be used anywhere c/c++ have found success.
> Are 100% of those exploitable? This single ended statistic is simply not useful.
Some more links/statistics (including on 0-days exploited in the wild) here: https://www.memorysafety.org/docs/memory-safety/#how-common-...
> You have proof of this?
One class of non-memory-safety bugs that safe Rust entirely prevents is data races: https://doc.rust-lang.org/nomicon/races.html
> That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.
Are the advantages in those cases (option/result) properly realized when it's just piled on top as something you could do?
I still have to be wary that, for instance, std::strchr could return a nullptr which I might pass on without handling. Plus even with std::optional<T> it's on me to remember to check val.has_value(), else it's undefined behavior to access.
Whereas in Rust, s.find() must return an Option<usize> because there's no null for it to return otherwise, and accessing the inner value (`match`, `if let`, ...) requires handling the Option::None case.
> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.
Large compared to C or Zig, but not compared to C++.
Generally speaking, the purpose of a program is not to minimize the number of memory safety bugs. All other things being equal, yes, having fewer memory safety bugs is better than having more. But perhaps you're trading legible bugs for illegible bugs? The rust implementation is most likely going to be more complex than the c implementation (which is fair since it almost eliminated a whole class of bugs), and in that complexity there is extra room for non-memory safety related bugs.
There's probably also 500x more people who know c to a given level then know rust to a given level.
If we have an analyzer that can find memory safety bugs in C, we could also just put that in the CI pipeline, or as a pre-submit hook before you're allowed to add code to a code base.
This idea that if Rust doesn't have all those memory safety bugs it must somehow have loads of other bugs we haven't discovered reminds me of Americans insisting that countries which don't have their lousy gun safety problems must have the same effects by some other means they haven't detected - Like, OK England doesn't have lots of gun murders like America, but surely loads of English people are just dropping dead because someone threw a yoghurt at them, or used harsh language, and we just missed them off our statistics ?
No man, it is possible to just do better, and this is an example of just doing better. The Rust is just better software. We can and should learn from this sort of thing, not insist that better is impossible and the evidence suggesting otherwise must be a mirage.
https://en.wikipedia.org/wiki/No_true_Scotsman
I don't see the connection, did you reply in the wrong place?
You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all. That's just a basic requirement of what it means to write in those languages.
The graph about reverted code also addresses the "illegible bugs" argument.
As for an analyzer, that's what ASAN is. I hope I don't need to explain why that's not a universal solution (even though everyone should be using it).
> You're not fully understanding the issue with memory safety. When you write C or C++, you're promising that you won't violate memory safety at all.
The post you reply to does not indicate a misunderstanding of memory safety at all. .
The comment I'm responding to implicitly assumes memory safety violations are like other bugs where that it's meaningful to speak of programs being more or less correct depending on the number of issues. What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all. It's more like parsing paint splatters as perl [0]. You might get something resembling what you want if you're lucky, but you also might not depending on how the compiler feels that day.
Let's use an example: https://godbolt.org/z/TP6n4481j
The code shows main immediately calling a nullptr. What the compiler generates is a program that calls unreachable() instead. These are two different programs. If memory safety is "just" a bug, this would be a miscompilation. It's not a miscompilation though, because what I've given the compiler is something that resembles C++, but is actually some similar language where null dereferences are meaningful. The compiler only knows about C++ though and C++ doesn't have nullptr dereferences, so it assumes I haven't done that. Instead it generates a program corresponding to an execution trace that is valid C++, even if it can't see the call to NeverUsed(). If you use -O0, you get the segfault as expected.
A single instance of memory unsafety (or other UB) can take your program arbitrarily far from "correct". All other things being equal, a program with 1 violation might be just as incorrect as a program with 100. I could add a hundred more lines of safety violations after Do() without changing the compiled behavior. You don't even need to execute the unsafety to have "spooky action at a distance" cause that change.
[0] https://web.archive.org/web/20190406194101/http://colinm.org...
Finally someone who actually gets it.
Many Rust proponents are experienced C and C++ developers who have dealt with this situation for decades. Given the language, it's understandable that compilers make the choices that they do. It's also understandable that programmers find it unreasonably difficult to reason about code written in such a language.
> What I'm emphasizing is that code with safety violations, strictly speaking, isn't C/C++ at all.
This isn't really correct and many programming language standards (including that of C and C++) don't support this view. Many language standards define a notion of conformance. Strictly conforming programs aren't allowed to invoke behaviors that which are undefined[1].
Conforming programs do not have this requirement and basically any non-trivial C and C++ programs are written to this rather than the notion of "strictly conforming".
Most non-trivial programs are not strictly conforming (including some C compilers themselves), generally because restricting the set of targets to something smaller than "any possible C implementation" is useful.
It is perfectly legal (and very desirable in cases where the standards fall short of usefulness) for a C compiler to define undefined behavior. What you compiled is still a C program, just one that isn't portable across the entire potential set of implementations.
[1]: Or unspecified or implementation-defined, for that matter, but this part tends to get left out of discussions.
The C++ ISO document describes conforming implementations of their language, ie compilers and similar tools - that conformance isn't a property of your program at all.
So far as I can tell there is no mention of the program conformance you're describing.
There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation. In theory you could have an implementation that gives semantics to UB like Fil-C or CCured do. No mainstream implementation does that for memory unsafety due to the performance overhead, and conforming implementations are required to document those extensions. I don't think there's a sane argument for an implementation to intentionally choose the behavior in the example I provided and Clang certainly doesn't, so it's non-conformant regardless.
> No mainstream implementation does that for memory unsafety due to the performance overhead
It depends on what is considered memory safety here (especially when some of them are arguably unforced errors in the standards), but many implementations do in fact have options for this ("no delete null pointer checks" for example is an example of one such option, for example, which is used extensively by the Linux kernel for example).
The performance impact tends to be much more negligible outside of, sometimes contrived, benchmarks, especially when compared to algorithmic efficiencies or the like.
> There's a line in the standards that basically says a conforming program is anything acceptable by a conforming implementation.
Perhaps it "basically" says that, but it certainly doesn't appear to literally say any such thing, so you're going to need to specify where you believe you saw this so that I can have any idea what it actually says.
C standard N3096, Section 4:
That definition goes all the way back to C89. The C++ standard drops it for the term "well-formed program", but adds enough clarifications in 1.4 to mean essentially the same thing.Ah, no. Most C++ programs that compile are not well-formed programs. This functions as an escape hatch for Rice's Theorem. You see, C++ even more so than C has semantic requirements - but Rice says all non-trivial semantic requiremnts are Undecidable. So, if you want what C++ says it wants it appears that compilers would be entirely impossible and that's awkward. To "fix" that C++ says it's fine if the compiler will compile your program even though it is not well-formed, the program doesn't have any meaning of course, only well-formed programs have meaning, but it did compile, so as a programmer you're happy...
C++ has a recurring phrase in its standard document "Ill-formed No Diagnostic Required" or IFNDR which carries this intent. The compiler can't tell you made a mistake, but you didn't actually write a valid C++ program so -shrug-
Because there's no way to tell for sure without exhaustive human examination we don't know for sure how many C++ programs aren't actually well-formed but experts who've thought about it tend to think the answer for large C++ software projects is all or most of them.
Chances are, a Rust implementation of certain things may be simpler than C implementation. C is a low-level language, so you have to do more housekeeping, and express things obliquely, via implementation, vs expressing things more declaratively in Rust.
Being simpler is not a given though.
"Knowing C" as being able to read and understand what's happening is quite separate from "knowing C" as being able to write it competently. Same thing with Rust: an algorithm written in rust is far from impenetrable for a non-expert, and even someone who sees Rust the first time but has enough experience with other languages.
The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.
C is not simple, it is inept. There are so, so many bargain-bin features and capabilities that it just cannot do that it ends up creating much MORE complex code, not less complex code.
I mean, just the pretense that simple tool = simple engineering isn't necessarily true. Building a home using an excavator and drills is fairly straight forward. You know what's complicated? Trying to build a home using only a screwdriver. Yeah. Good luck with that, you're gonna have to come up with some truly insane processes to make that work. Despite a screwdriver being so much more simple than an excavator.
Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.
C++ and Rust? Easy. Templates and generics. C? Up until a few years ago, your options were: 1. copy and paste (awful) or 2. use void * (also awful).
Copy and paste means your implementations will diverge and you just artificially multiplied your maintenance burden and complexity. And void pointer completely throws away any semblance of type safety, forces you to write stupid code that's way more complex than it needs to be, and, to top it off, is horrible for performance!
That's just one example, but there's so, so many when you look around C++ or Rust enough. And these are not rare things, to me. To me, these are everyday coding problems.
Anonymous functions? There's another one. Encapsulation? Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.
> Just making not literally every piece of data universally mutable? Not possible in C. Trivial in C++ and Rust, and it makes your programs SO much easier to reason about.
And Rust is significantly better at this than C++ for the simple reason that mut is a modifier. I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it, and, as readers, we’re left wondering whether things actually need to be mutable, or the author forgot/didn’t know to add const-ness to their code. With Rust having opt-in mutability, you know for a fact that mutability was a deliberate choice (even if sometimes the only motivation was “make the compiler happy”).
> I’ve lost track of how many times I’ve listened to Kate Gregory extol the virtues of const-ing all the things, but people still don’t systematically add it
Adding const to _function-local_ variables only really matters when you "leak" a pointer or ref, whether mutable or const, to a function or variable the compiler can't optimize away:
as there is no way to know if something obtains a mutable ref to sz down the line.In other cases like RVO, adding const is actually detrimental as it prevents the move-constructor from being selected (likewise with the move assignment operator).
Rust _needs_ to have const by default due to its aliasing model ("only one mutable ref per object") and you can't have cheap bound checks without this. But that, too, is a tradeoff (some classes of programs are hard to code in Rust)
Pretty sure the std::abort() can't be optimized away if sz is mutable since it's legal for some_opaque_func() to cast away szRef's const and modify sz via that. sz itself needs to be const for the if statement to be removable as dead code.
https://cpp.godbolt.org/z/Pa3bMh9Ee shows that both GCC and Clang keep the abort when sz is not const. Add const and the abort goes away.
> The idea that people occasionally throw around that C is more 'simple' and less 'complex' than C++ or Rust and therefore it leads to more maintainable or easy to understand code is, IMO, completely bogus.
This, this, this.
C compilers are simple, but the C language is not, and let’s not even talk about C++.
>Trivial example: you want to build a container that can hold data of different types and perform generic operations on them.
Do I?
I would simplify the problem to not need different types or generic operations.
Or if I really need generic operations, break them down to smaller operations so you don't need to take a bunch of type parameters everywhere.
For example containers, instead of having container<T>, have the container operations return an index or 'opcode', then the user applies that to their data. The container doesn't need to know about T, void pointers or sizes, just its own internal bookkeeping stuff.
That's valid, even sensible, but you have now left significant performance on the table.
I like to focus on the ways that C is actually quite complicated, especially the complications that directly provoke UB when you don't know about them. Integer promotion and strict aliasing are at the top of my list.
To be honest I feel like "this code is easier to review and less likely to require rollbacks" is even more of a valuable take from this article, just in terms of "hey, don't you like it when things don't have to be rolled back?"
Security issues are like bad etc too, just we've heard the security spiel so many times at this point. I just think it's nicer to write most stuff in Rust.
Yes, Rust's strictness makes it a lot more maintainable. It is so much more common that changing the one thing you wanted to change results in a compiler error at every single other site you need to change, without having to look at other areas of the codebase at all, and all the tests pass on the first try.
Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.
I don't know much about how it got started. I'm curious how much of Rust's capabilities depend upon recent CS breakthroughs. Could we have made Rust in 1990?
The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
> Could we have made Rust in 1990?
No. Only massively oversimplifying, Rust could be described as a bunch of ideas pioneered among functional languages coming back to C++, the same way Java was a bunch of ideas from Lisp coming back to C. There is very little that's truly new in Rust, it's just mixing a bunch of features that were not often together before.
> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
What makes Rust slow to compile is largely independent of what makes it unique. A lot of text has been written about this, but the again massively oversimplified version is that had the designers cared about compile times when the language was being designed and the compiler written, you could have something that's very similar to Rust but also very fast to compile.
> The compiler is also relatively slow. Would Rust have been worth working with on 30+ year old hardware?
As I understand it, a lot of the slowness of the rust compiler comes about from llvm. And how rust and llvm interoperate. Rustc creates and sends gigabytes of stuff to llvm - which passes all of that to its optimizer. If you skip all that work - for example by running cargo check - the compiler is an order of magnitude faster.
If rust were invented in the 90s, it wouldn’t have used llvm. Rust could still have been implemented, and we’d probably have a much faster compiler as a result. But it would have missed out on all the benefits of llvm too. It would have needed its own backend to be written - which would have been more work. And the compiler probably wouldn’t have been as good at low level optimisations. And it probably wouldn’t have out of the box support for so many target platforms. At least, not from day 1.
The obvious(?) question is why it sends gigabytes of stuff to llvm and if that can't be reduced somehow.
> The obvious(?) question is why it sends gigabytes of stuff to llvm
IIRC it's a combination of technical debt from earlier in Rust's life (it's easier to generate naive LLVM IR and let LLVM's optimizer do the heavy lifting of chewing through that) and how Rust implements generics via monomorphization
> and if that can't be reduced somehow.
I believe the technical debt bit can be (and is being!) reduced by implementing optimizations and better IR generation in rustc itself. As for the monomorphization strategy, I thought I remembered reading something about how Rust technically allows for generics to be implemented via non-monomorphization strategies like type erasure/dynamic dispatch, but I can't seem to find that post/article/whatever it was now so I'm not sure I'm not making it up. That being said, there are patterns to reduce the amount of code generated (e.g., generic facade that forwards to a non-generic implementation), but those need to be manually implemented at the moment and I don't think there's significant work towards automating that at the moment.
For the latter, the term you want to search for is polymorphization. It is about making the compiler do the work that those manual façades do, automatically.
Yeah, that looks familiar. Thanks for the pointer!
I think the answer is probably that Rust was possible in the 1980s and 1990s, but such a thing just wasn't practical.
Rust is notoriously compiler-intensive. That wouldn't have been tolerated in the early PC era. When you needed fast compilers that "worked on my machine" and should work on yours. Ship it.
It wasn't really possible. We had neither the PL techniques nor the computational power to make something like Rust work at the time. All the answers people are throwing around showing it would have been possible rely on a garbage collector and require a runtime, or have many other unacceptable compromises (e.g. no use after free because you aren't allowed to free).
> Could we have made Rust in 1990?
We did, it was called OCaml. If we'd had any sense we'd've rewritten all our systems code in it. But since C had bigger numbers on microbenchmarks, no-one cared.
One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system.
So the answer is no, because humans’ collective expertise of programming language theory simply isn’t enough in 1990, unless Rust developers independently invented such features instead of copying them from GHC Haskell.
> One of Rust’s biggest and best features is its trait system inspired by Haskell’s type classes. It is the right abstraction for most use cases that in 1990 were implemented by OOP and inheritance. Now the basics of type classes were invented by Wadler in 1988, but certain more advanced features (type families) were only invented in 2005. You mention OCaml but that’s only a small part of Rust’s type system.
I submit that those advanced features are at most a tiny fraction of why projects like OP are seeing benefits from moving to Rust. E.g. I wouldn't be at all surprised if this Rust on Android project isn't using type families at all, or is using them only in an incidental way that could be replaced without significantly compromising the benefits.
Any Rust code longer than ~20 lines uses Rust iterators which use type families. The Iterator trait in Rust has an associated type called Item. This is the innovation here. Classic type classes can only contain functions not types. It was in 2005 that a paper was written to show how having a type inside a type class makes sense, including how it can be type checked (via entailment of type class predicates with type equality), type inferred (by changing the standard HM system to return partial type equality constraints in addition to substitutions).
Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.
Are associated types type families? I'm not sure. They seem more similar to functional dependencies to me. But I'm only familiar with type families from Haskell so maybe I'm missing some broader context.
Yes they are type synonym families. And yes they are quite similar to functional dependencies because it is conceived as an alternative to functional dependencies but it expresses the programmer’s intent more clearly.
> Classic type classes can only contain functions not types...
> Now if Rust did not have such language features maybe it would have implemented iterators very differently. Current Rust iterators are similar to Java iterators, and in Java, iterators themselves have a type parameter, rather than having an associated type inside the iterator trait.
True, although I'm not sure how much difference it makes in a language with first-class modules. But more importantly, how much difference does it make at the point of use? As far as I can see the overwhelming majority of Rust iterator code looks pretty much the same as one would write in OCaml, or Java.
All of the memory safety stuff is independent of the trait system, to the best of my knowledge, but the data race protection is implemented through the Send and Sync traits. I'm unsure if there is an obvious alternative approach to this same feature, but I think it may be one innovation that is still novel to Rust and would not have existed in earlier decades.
Rust also has the bigger numbers on microbenchmarks, that's why people care about it.
Yes, exactly. It's tragic that the only way programming culture ever improves is when a language comes out that's better for writing software in and happens to also have bigger numbers on microbenchmarks.
I think you're generalizing a bit too much. Rust targetted the audience that wanted big numbers on microbenchmarks, but not all languages do. Typescript for example has no performance advantage against Javascript, but it became very popular due to the better dev experience. Kotlin is another example where that mattered a lot.
Yeah, I am blown away. Assuming that these stats are true/verifiable, this spells real doom for C++. What is the point of C++ in 2025 except to maintain a large, existing source code base? Else, you should be doing everything that you used to do in C++ in Rust.
> What is the point of C++ in 2025 except to maintain a large, existing source code base?
Half of useful things to do are impossible or plain cumbersome to write in rust given the semantics and constraints of the borrow checker. Try to write self referential structures in rust and you'll have a more nuanced opinion.
I’ve written self-referential structures in Rust with the ouroboros and self_cell crates. It was fine, and I got way more guarantees I got it right compared to C++.
That’s entirely the point, though. Rust compiler is of the opinion that recursive data types are hard and I don’t think it can be reasonably argued that this opinion is incorrect.
Feel free to use unsafe {} when you need it, though.
That's also a reason why Google is researching with Carbon, they have for sure a hunger to migrate away from C++.
Note that N=1 for the memory safety vulnerabilities they had with Rust, so the error of the estimated average number of vulnerabilities per LOC is quite large.
Yes. I would make a guess of 10 or less memory-safety vulnerabilities per MLOC, which is still a hundredfold reduction.
Your best guess is that the true rate is 20x higher than the observed rate? This seems unlikely to me given the number of samples (outside of systematic biases towards certain types of memory safety bugs that probably apply to C++ code too). 10 per hundred MLOC is closer to what I would have guessed too, but that is because I've historically been very conservative with my assumptions about the memory unsafety rate per unsafe LOC being similar to that of C++. The evidence here suggests that the true rate is probably much lower than that.
I'm making a conservative guess, which is why I said 10 or less (10 or fewer??). So the improvement is at least a hundredfold. I might say 5 or less instead. I think the exact rate is not so important; either way, it's clear that Rust is a boon.
Those are orange vs apple, just like the rate of rollbacks
They compare something new, which rewrite existing stuff (not only but still) with some decades-years-old cruft
In they new code, they know what they want
They can also start with state-of-the-art unit testing that may not exist in the early 2000
So .. yeah, those numbers ..
That rust is saner than c++ is a given anyway :)
Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.
Take a look at the examples in this post: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-...
Large C++ codebases have the same problems that large codebases have in any language: too many abstractions, inconsistent ways of doing things, layers of legacy. It comes with the job. The difference is that in C/C++, hard-to-read code also means hard-to-guess pointer lifetimes.
If the C++ code I worked on looked like that[1] and was actually C with classes, then I’d be switching to Rust too. For Google and Microsoft it probably makes sense to rewrite Windows and Android in Rust. They have huge amounts of legacy code and everybody’s attacking them.
It doesn’t follow that anyone else, or the majority has to follow then. But that’s predictably exactly what veteran rustafarians are arguing in many comments in this thread.
[1] Pointers getting passed all over the place, direct indexing into arrays or pointers, C-style casts, static casts. That (PVOID)(UINT_PTR) with offsetting and then copying is ridiculous.
It's not _that_ hard to believe if you start spraying smart pointers everywhere.
Per million lines of code.
I fear Androids problems with Google as steward has other significant problems than memory safety.
To a degree that users might want to even exploit such flaws to unlock their phones.
Aside from that. Sure, the constraints of Rust do solve these kinds of problems.
Absolutely crazy.. I never expected that the difference would be so drastic.
They found a memory safety bug in their Rust code and assumed it was the only memory safety bug in their Rust codebase. And then they compared it to the historical average in C++ code that's been around for almost two decades in production. I can't be the only one here who sees how biased this comparison is right?
Rather, they found one memory safety bug in their Rust codebase, and measured it against the legions of memory safety bugs they found in their C++ codebase. In neither case are they measuring against bugs not found, so no, it's not biased.
Except it's not an apples-to-apples comparison. The C++ code has been around a lot longer, and a lot of it was written with older versions of C++ which didn't have modern safety features. I'm sure there is a bunch of new/delete in their codebase still. And I'm sure they're actively looking for memory safety issues in C++, and probably not so hard (if at all) with Rust.
> The C++ code has been around a lot longer
They made an earlier report where they found out that older C/C++ code has actually a lot less new vulnerabilities compared to new code, so I guess here they are comparing to new C/C++ code to get the higher ratio, meaning the comparison should actually be apples-to-apples.
Is it a usual thing you do that when you're given data about a literal thousandfold improvement, in a context where there are well-understood theoretical and practical reasons why you might have expected to see such an improvement, you make up reasons why it is actually not an improvement at all, without either investigating to see whether those reasons are actually true or demonstrating that even if they were true, they could possibly explain more than a tiny fraction of the improvement?
I usually am skeptical about a literal thousandfold improvement, yes. And I'm not saying it's impossible, but rather that the data and the way it's presented has inherent biases. Its on the people making grandiose claims to prove them.
The fact that the safe subset of Rust can indeed be made safe, and that unsafe code can be encapsulated like this, have already been formally verified. This is an empirical demonstration that matches these formal results across a large company with a large amount of code (technically, it exceeds them, but this is only under the assumption that memory safety issues per line of unsafe Rust are identical to memory safety issues per line of C, which is really an unwarranted simplifying assumption).
Do you really believe that "they're not actively looking for memory safety issues in Rust" is (1) true (at least outside of Google, there is actually a ton of security work done specifically targeting just the unsafe blocks, since those are obviously where the memory safety issues lie) or (2) could possibly be responsible for a literal thousandfold reduction in memory safety issues? Remember that the Rust code is often integrated with C++ code--there is not necessarily a way to just test the C++ part even if you wanted to. Additionally, Google has explicitly prioritized code that interacts with untrusted data (like parsers and networking code) meaning it's likely to be easier to fuzz most of this Rust code than most new C++ code.
Also remember that, again, there are mechanized proofs of memory safety for a large subset of the safe portion of Rust, which constitutes 96% of the code under consideration here. The rate of memory safety bugs would have to be 25x as high per LOC in unsafe Rust code as in C code for the number of vulnerabilities to match. It would be far more shocking if we didn't see a dramatic reduction. Google is empirically demonstrating that the observed memory safety bugs per line of unsafe Rust is actually far lower than per line of C, but my point is that even if you think that is the result of bias or them not applying the same scrutiny to Rust code (something that is certainly not true of Rust vs. C code in the wild), the effect of this underrepresentation cannot possibly explain most of the reduction they observe.
Google deployed numerous state of the art mitigations prior to adopting Rust and still found that 70% of their CVEs were due to memory safety issues--your assertion that they are engaged in motivated reasoning and just wanted Rust to work out is pretty ill-founded. In fact when I worked for Google prior to Rust's release, they were strongly averse towards adopting any new language and believed that good engineering practices, automation, and a rigorous review process always outweighed the benefits of adopting a new language past their core ones, whatever its purported reliability or performance benefits. Security researchers are highly skeptical as a rule of these sorts of claims and have a lot of say at Google. They themselves changed their minds based on this sort of internal evidence.
I agree that skepticism is warranted, because we are constantly being sold things by industry. At a certain point, though, when the effect size is massive and persistent and the mechanism extremely clear, that skepticism (not in general, but of a particular claim) becomes the unscientific position. We are well past that point with Rust wrt memory safety.
You're sure of a lot of things.
Because I don't blindly accept bad science? It's more like others are sure that this data confirms their biases.
Where is your data? You seem to be biased.
Why do you blindly accept the status quo, though? You should be skeptical of both sides.
If you want something more comparable, they estimate that only 5% of their Rust code is within unsafe blocks. That makes only 5% of the code with potential for memory safety issues: that's already a 20x improvement. Let's make it 10x because unsafe blocks tend to be trickier, but you still get a lot of Rust guarantees.
The thing is with Rust, you know where to look for memory safety issues: the unsafe blocks. C and C++? GLHF that's your whole codebase. As they mentioned, you don't opt-out of all of Rust guarantees by going the unsafe route. Of course you can ditch them, but that'll be hugely visible during code review. Overall, you can be much more confident saying "yup there's no bug there" in Rust than in C or C++.
Even if they are off by a factor of 100 it's a huge win and the point stands.
It's fair to point this out and worth the mention. Still, I'd like to think that the engineers behind this can at least gauge the benefit of this endeavor with some accuracy despite the discrepancy in available data, and stating the data that is available only makes sense.
and they found 1000 memory safety bugs and assumed it was the only 1000 memory safety bugs in that code which have been in production for 2 decades. How naive can they be?
Even so, relatively speaking if C is not 50,000x worse, it must be at least 2000x worse.
Further up they refer to Android C/C++ code, not C/C++ in general:
"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code."
Which means they had a pretty poor code base. If they had spent more time on engineering and less time on features that are canceled after 12 months anyway, they could have written better C/C++.
I peruse Android system code at work and their C++ code base is not designed for safety. It’s just typical C++ code as any large company would write it.
And for a large juicy target like Android, that won’t be good enough to stay ahead of the attackers long term.
Of course, tools like Fil-C or hardware-based security might make Rust vs. C or C++ moot.
Edit: your comment makes a good point. Shame that trigger-happy (c)rustaceans are downvoting everything in sight which is not praising this PR piece disguised as a technical blogpost.
While crashing is better than exploitable behavior, catching bugs at compile time is even better. Neither hardware based strategies nor filc actually find bugs at compile time. Also the conversation with respect to security isn't about migrating old code, but what to use for new code that you write.
I will note that developers also feel more productive in rust. That's why they migrate existing things over to it even when it may not be beneficial for security.
Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore.
Of course, I am exaggerating a bit - and I am not even that experienced with Rust.
But after coding with Ruby, JS/TS and Python - it feels refreshing to know that as long as your code compiles, it probably is 80-90% there.
And it is fast, too.
That’s my favorite feature. Rust turns runtime errors into compile time errors.
All that fighting with the compiler is just fixing runtime bugs you didn’t realize were there.
Rust is the most defect-free language I have ever used.
I'd wager my production Rust code has 100x fewer errors than comparable Javascript, Python, or even Java code.
The way Result<T,E>, Option<T>, match, if let, `?`, and the rest of the error handling and type system operate, it's very difficult to write incorrect code.
The language's design objective was to make it hard to write bugs. I'd say it succeeded with flying colors.
Now try an actual functional programming language. I like Rust too but those features all come from FP, and FP languages have even more features like that that Rust doesn't yet or can't have.
> Rust has been such a "pain" to learn - at least compared to other, more straight-forward languages. But boy does it feel good when you know that after a few back and forths with the compiler, the code compiles and you know, there is not much that is going to go wrong anymore.
I found that at some point, the rust way kinda took over in my head, and I stopped fighting with the compiler and started working with the compiler.
Rust is easy to learn. I've done it 4 or 5 times.
I'm interested in what scenarios you don't get this same feeling when writing TS code? I of course agree with Ruby, JS, and Python.
One big source of bugs in TS is structural sharing. Like, imagine you have some complex object that needs to be accessed from multiple places. The obvious, high performance way to share that object is to just pass around references wherever you need them. But this is dangerous. It’s easy to later forget that the object is shared, and mutate it in one place without considering the implications for other parts of your code.
I’ve made this mistake in TS more times than I’d like to admit. It gives rise to some bugs that are very tricky to track down. The obvious ways to avoid this bug are by making everything deeply immutable. Or by cloning instead of sharing. Both of these options aren’t well supported by the language. And they can both be very expensive from a performance pov. I don’t want to pay that cost when it’s not necessary.
Typescript is pretty good. But it’s very normal for a TS program to type check but still contain bugs. In my experience, far fewer bugs slip past the rust compiler.
Appreciate it, that makes a lot of sense. I feel like I've been trained to favor immutability so much in every language that I sometimes forget about these things.
Yes, immutability is great for safety. But the copies you have to make to keep everything immutable extracts a price in copies and garbage collection.
Rust is advertised as having fearless concurrency. That's true, but not that important as concurrency is not that common. What's important to everyday programming is Rust provides fearless mutability. The fearless concurrency you get with that is just a bonus.
Fearless mutability provides Rust the same safety as a functional language in a without the speed or space cost. IMO, it's Rust's true secret sauce.
Yea this seems like a super power I thought only functional languages had. I have to make time to learn some Rust
Similar. I mostly design my code around something like pipe and lifetime. The longer something needs to live the closer it is to the start of the program. If I need to mutate it, I take care that the actual mutation happens in one place, so I can differentiate between read and write access. For anything else, I clone and I update. It may not be efficient and you need to track memory usage, but logic is way far simple.
Not parent comment, but TS is generally safe if you have types correct at system borders, but very scary when you don't. Some of the most impactful bugs I've seen are because a type for an HTTP call did not match the structure of real data.
Also, many built in functions do not have sufficient typesafey like Object.entries() for instance
That is an issue with how TS works, but it can be significantly improved upon by using a library to verify the structure of deserialized data. zod is one example, or you could use protobufs. Fundamentally, this is an issue with any programming language. But having your base "struct"-like type be a hashmap leads to more mistakes as it will accept any keys and any values.
I disagree that this is an issue in every language - the problem is that in other languages the validation against some schema is more or less required for unmarshalling, and it's optional in TS.
Seeing a deserialization error immediately clues you in that your borders are not safe. Contrast that with TypeScript, where this kind of issue can lead to an insidious downstream runtime issue that might seem completely unrelated. This second scenario is very rare in other languages.
I don't know Rust, and I'm genuinely curious: How does it improve over that problem?
When you call a REST API (or SQL query for that matter), how does it ensure that the data coming back matches the types?
TS allows you to do parse the JSON, cast it into your target type, done (hiding correctness bugs, unless using runtime verification of the object shape, see sibling comment). Does Rust enforce this?
It validates the object shape at runtime, much like you can do in Typescript with a library like Zod. The key difference in this case is that Rust makes it scary to not validate data while Typescript will gladly let you YOLO it and blow your legs off, even in strict mode.
Okay I see, that's a nice secure-by-default point, whereas TS is arguably not secure-by-default.
It’s not. And trying to just be a transformation of the source to JS without its own standard library (mostly, some old stuff doesn’t follow this) means it really isn’t possible with just TS alone.
That’s OK with me. I use TS because I like it and hate the total lack of safety in JS. I have to use JS on the web, so TS it is.
If I don’t need it to run on a webpage, I wouldn’t be writing it in TS. I like other languages more overall.
The worst offender is toString which has different types between objects and is everywhere by default.
What do you mean by "safe" in this context?
If you type correctly at border of your system, then TS will be very close to a formal verification of your code. This won't catch all bugs, but even broad categories for you data is helpful. If you know your input is a non-null string. Then it will warn you of every non string usage. It won't catch whether it's a name or an email, but knowing someone tries to divide it by zero is helpful.
It's a lot more effort, but branded types for conceptual differences can bridge that last gap
Typescript doesn't even support notions like "unsigned integer". It is not a serious attempt at type-safety; its main claim to fame is "better than raw Javascript" which is not saying much.
If you need to run in a JS environment it’s a hell of a lot. It’s a FANTASTIC improvement.
I wouldn’t use it server side or for a client application that doesn’t run in a web browser. That’s not its place, for me.
But I will 100% reach for it every time if I need to run in a JavaScript environment.
TS actually works very well as an HTTP server, I’d say better than typed Python. Plain JS… a minute of silence, please.
I’ve never been a JS on the server person, I was used to other languages when that was developed.
Well I think I would prefer python, but simply because it’s “more traditional“ and I realize that’s specious reasoning, I prefer to use strongly typed languages whenever possible.
I would generally reach for Java since it’s the language I’m most proficient in due to my career. There’s also Go, which I played with long ago, or maybe I’d try Rust.
This is only for anything important. If I was just toying with something locally I’d probably do whatever was fastest. In that case Python or JS might be my choice for a very tiny script.
Note that Google still doesn't have official support for using Rust in Android userspace, though.
Despite all pluses on the blog, NDK only supports C and C++ tooling, same on Android Studio, and it is up to the community to do the needful work, if anyone feels like using Rust instead.
Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using Rust or anything else so long as it plays by the rules.
Some people rather reach out for first party support, instead of filling in the gaps for the big boys.
By first party support, would you be expecting a Rust toolchain shipped in the NDK, or maybe Rust bindings shipped in the NDK?
I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io.
Or maybe they should ship scripts that shell out to an existing Rust toolchain.
I expect Rust being documented here,
https://developer.android.com/ndk
I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust.
I expect all NDK APIs to have Rust bidding crates.
I expect that Android developer forums also care to support devs using Rust.
And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and C++.
The Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.
I'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated.
[1] https://github.com/android/ndk-samples/tree/main/endless-tun...
Both Gradle and CMake have a strong late 1990's smell to them. While CMake is sort of a necessary evil in the C/C++ world, there's no excuse for dragging Gradle into the NDK, combining both build tools leads to a complexity explosion that rarely works and tends to break after either the NDK or SDK is updated, or somebody merely looks the wrong way at the build files.
CMake is the defacto tool adopted by the industry, regardless how many love to hate it.
You can use BSD Make instead of Gradle, isn't UNIX great?
> You can use BSD Make instead of Gradle, isn't UNIX great?
So the NDK officially supports creating an APK just with a Makefile? That would be news to me (and great news at that).
It is possible to cobble together a build process that directly calls various Android SDK command line tools to build an APK directly from a C/C++ build tool without involving Gradle, but as far as I know, most of those invoked cmdline tools are deprecated and building APKs outside Gradle is not 'supported' by the Android SDK/NDK (e.g. it may stop working at any time).
No, I wasn't talking about APKs.
The NDK supports building shared objects with Makefiles, via ndk-build.
The original plan to deprecate ndk-build was reversed, due to the complaints.
Pretty much official,
https://developer.android.com/ndk/guides/build
I also stand corrected, it is actually GNU Make, not BSD Make.
Nope it clearly supports ISO C 11 and ISO C++17.
I do agree the NDK team is rather small.
Huh? "Barely"? What are you talking about? The NDK supports compiling C++ just fine. There are CMake files, among other things, ready to use --- as well as Soong native configurations. CMake is under active development. Other toolkits are within easy reach: for example, Meson works fine. Also Bazel. Hell, even autotools can be made to work.
Sure, building C/C++ code into an .so file kinda works but that's about it, try building the APK entirely with cmake, that's simply not supported, you'll have to integrate with Gradle. The result is a complexity clusterf*ck that's a nightmare to maintain.
The NDK team should take a long hard look at Emscripten to get some inspiration how native code development is integrated into a 'native-hostile' runtime platform.
I've never understood why developers fixate on having "pure" NDK-based apps. It's really not that hard to implement Activity, Service, etc. as JVM in Kotlin or Java and call the native code via JNI. What do you think the "pure native" app layer in Android is doing if not that?
It's not about the idea of writing a pure native app, but about making it easier to build a hybrid app without an exploding build process complexity.
Emscripten is again a perfect example of how it should be done: FFI calls into Javascript are trivial (it's even possible to embed JS code into C/C++ source files), and I can build a complete hybrid WASM/JS app without having to bring in a completely different build system that's completely alien to the C/C++ world.
It even works without any build system at all since the emcc compiler/linker wrapper is also the Javascript bundler, yet the entire emcc wrapper acts like a GCC/Clang compatible compiler/linker with some extra Emscripten specific flags. The Emscripten SDK didn't jump into existance like this, the difference to the NDK team is that the Emscripten team actually listens to their users.
Interesting that you give Emacripten as example, given how badly documented its whole tooling is, and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded, unless using the Github installation from source.
The one great feature of Emscripten is that you can do:
...and it produces an output that's immediately runnable in a web browser instead of just a bare .wasm file which needs to be wrapped in a html with additional steps.E.g. emcc is a drop-in replacement for gcc/clang which can be used directly in a C/C++ build tool as a C/C++ compiler and linker while still doing the right thing (producing a runnable .html).
The NDK equivalent would be a gcc-compatible compiler wrapper which can do this:
...such a simple and obvious thing to do, yet it doesn't happen because the Android SDK/NDK developers have no clue about developer workflows outside of their precious Java ivory tower.> and is a pain to prevent it from downloading the Java tooling and everything else that is already downloaded,
That's a feature, not a bug. It's trivial to install different emsdk versions side by side, each entirely self-contained and without polluting the system or requiring external dependencies.
The separate Java dependency also has been dropped a while ago, since the only remaining component that depends on Java is the optional Closure compiler step, and that comes now with an embedded Java runtime (as far as I'm aware at least).
Usually applications aren't bare bones hello world.
It is not ivory tower, it is called OS safety, and the NDK purpose has been quite clear on its front page documentation since Android 2.x.
Likewise, from my side, I don't consider those speed bumps on Emscripten features.
Don't forget this list of expectations for SPARK [1] too, if you want even safer, high-integrity, and formally verified code on Android!
[1] https://www.adacore.com/about-spark
I think we can indeed forget about it.
Android has zero lines of Ada code, why should I care about it in this case?
They've been trying to strangle the NDK for years. You can't even make an app without a ton of glue code on the JVM.
True, NDK was never intended to make apps, only for games and as helper for native methods, since it was introduced in Android 2.1.
The point is about the official support for using Rust exactly for the same use cases.
This is the bomb that sank C++ in 2026.
Have fun justifying that Rust is "also" unsafe, with the right tools you can achieve the same in C++, if you're a great dev you can do even better, etc.
rust has other advantages. I think cargo is better than cmake. I think the syntax is better, I think the way dependencies and modules are handled is better.
It can be annoying to write "safe" code, but once it meets a certain standard I can be confident in multithreaded applications I write.
I would like to use rust to write android apps. I don't really like the whole android studio java thing.
> I think cargo is better than cmake
I expect that Google is using neither of these for most of their own code, but rather their own build system (which I think is the same between the languages).
I absolutely agree if you aren't Google though.
Google3 uses Blaze which is an internal Bazel. And it’s fantastic. I like Facebook’s BUCK too but it’s basically the same thing.
If I were to go to another company I’d promote using either of the above.
What does Android do for Rust?
It uses Soong which internally calls rustc: https://source.android.com/docs/setup/build/rust/building-ru...
Android uses Soong: https://source.android.com/docs/setup/build
Proprietary code uses the internal version of Bazel: https://bazel.build/
Yeah my understanding is that google has some sort of God program they use that can compile anything and has 10,000 command line options.
It’s https://en.wikipedia.org/wiki/Bazel_(software)
>I think cargo is better than cmake
That is an understatement. I can't think of a build system that has spawned more attempts to find something better than CMake has.
There have been so many people trying to make their own C/C++ build system and/or package manager out of sheer spite for CMake that it's frankly hard to keep track.
In fairness to them and to CMake, it's not a simple problem to solve. To truly know CMake is to wish you didn't, that way someone else would have to maintain it.
You seem to forget about autotools. Cmake is ugly but I'll take it over autotools.
As an end user: at least with autotools it's easy for me to see the available configuration options with ./configure --help in a nicely readable way. cmake has -LAH but it's still... kind of awful.
At least it knows how to use ninja though.
Problem is autotools doesn't work when cross compiling - the options are there but there is always something wrong, and it isn't easy to fix. cmake can at least get that right. Note that I cross compile a lot of code so this matters to me, if you just do the common thing autolools might work - but make would as well then.
Yeah; generally I find CMake rules are much easier to read and modify than autotools and makefiles. With Makefiles there’s about 18 different ways to write a rule to compile something, and I find I need to go hunting through a bunch of files to figure out how this makefile in particular defined a rule for compiling this C file in particular. CMake is much higher level. I can just see all the higher level targets, and how they’re built. Then - orthogonally - I can modify the build system that CMake uses to compile C code. It makes a lot more sense.
But I’d take cargo over any of this stuff. Cargo means I don’t have to think about compiler flags at all.
If you find yourself doing a lot of cross compiling C check out the Zig build system.
I am not going to rewrite the build system of a third party library.
I cannot like Rust syntax, sorry.
For me the ideal syntax is C/Go, just to be clear what I like.
But I agree that the tooling that cargo introduced is a breath of fresh air in a world dominated by huge makefiles, libraries copied in the repository (I know, there is Conan, vcpkg etc)...
> I cannot like Rust syntax, sorry. For me the ideal syntax is C/Go, just to be clear what I like.
I’m sorry if this comes across as dismissive, but I find it hard to take people seriously with complaints about syntax like this. Learning new syntax is really easy. Like, if you’re familiar with C & Go, you could probably learn all the syntax of rust in under an hour. The only surprising part of rust’s syntax is all the weird variants of match expressions.
Rust has some surprising semantics. Like how lifetimes work (and when you need to specify them explicitly). That stuff is legitimately difficult. But learning that if statements don’t need parenthesis is like - seriously whatever dude. If you want to spend your career never learning new stuff, software isn’t for you.
I picked up objective C about 15 years ago. The only thing most of my friends knew about it was that it had “that weird syntax”. It took no time at all to adjust. It’s just not that hard to type [] characters.
I'm very vocal that I don't like Python syntax, but I wouldn't refuse to write Python because of the syntax. If I had reason to write Python, I would grumble a bit but write the Python.
I'd say that rust has a weird level of being both verbose and terse in strange ways.
If you ever have to deal with lifetimes, then the verbosity goes up pretty significantly. And, dealing with pointers ultimately introduces multiple layers of concepts that you don't necessarily run into with C++/Go/Java.
Yet, with the type inference by default, rust can often feel shockingly terse. Doing collection manipulation is just as terse as any language you could imagine.
I think that's probably where complaints about syntax comes in.
C++ hides a lot of that complexity with move semantics, shorthands, autocoersion, and by making lifetime issues runtime problems. Languages like Go/Java/Python simply push everything onto the heap and try to avoid exposing low level memory semantics.
It's easy for me to see why someone wouldn't like rust. I think it's fine, but I'm also brain broken from perl and php.
> I'd say that rust has a weird level of being both verbose and terse in strange ways. If you ever have to deal with lifetimes, then the verbosity goes up pretty significantly.
I find rust generally more terse than both C and - especially Go, to which rust was compared upthread. Writing out lifetimes explicitly can be confusing. But I don't think it adds that much syntactic noise. Maybe 1/20 functions in my code have explicit lifetimes. That will confuse beginners, but I don't think its too bad once you're used to them.
> And, dealing with pointers ultimately introduces multiple layers of concepts that you don't necessarily run into with C++/Go/Java.
This is my #1 complaint about rust's syntax. If you ever need to interact with raw pointers within unsafe blocks, I feel like the language really fights you. It seems so strange, too - since unsafe blocks are exactly the place where it matters the most that my code is easy to read. Improving the syntax around pointers (for example by adding C's -> operator) would make unsafe blocks clearer.
It's not about learning syntax, it's about finding it generally tolerable to read. I personally find Rust syntax repulsive and would opt for a different language unless Rust was literally the only option. Thankfully it's never the only option, now or in the future.
Can you give some examples? Its hard to agree or disagree if you're not going to make any substantive claims.
All three have very similar syntax when compared even to something like Python or Ruby, let alone ML or Haskell. Seems like a spurious complaint.
I mean, Rust is quite a different category than C or Go, if this is the 3 languages you reference.
Rust has plenty of syntax coming straight from ML (okay, not straight, probably through OCaML)
Pattern matching, destructuring, expressions everywhere, etc are stuff that C/Go never even heard about.
No need to like it. It isn’t brainfck and does the job.
I don’t disagree, that’s part of why I like Swift so much. Rust looks very C++ to me.
But if I was working in C++ and had a choice of C++ or Rust, I’d go Rust based on this.
Agree! Swift I forgot to mention. What a nice and elegant language.
Go is such a great language. If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go. Great multithreading, memory safe, great error handling, and a familiar syntax for people coming from C++/Java/etc.
> great error handling
Go get this completely wrong! It use a tuple rather than an enum for potential errors. This means you can forget to check errors and just use the invalid (nil?) return value from the function.
On the other hand, rust uses the Either enum to force you to handle the error. Alternatively you can use the ? operator to pass it to the calling function, which is reflected in the enclosing function's type.
Pet peeves nitpick: it's not even a tuple. Go doesn't have tuples. It just has special-cased "multiple return values", which means that it's often impossible to just stuff the return of a function call (error value and all) into any data structure to aggregate them. You just can't do without first defining a struct since tuples don't exist in Go.
Yep Rust approach won. Pretty much every new language is adopting Result style errors and it's been adapted to plenty of existing languages.
It's a product of functional programming, and for me I can't see how you would ever want to handle errors outside of the functional programming railway-oriented style. For me it's just superior.
Umm, actually, it's specifically a coproduct of functional programming. ;-)
https://en.wikipedia.org/wiki/Coproduct
Ha learned something
How is Go memory safe? Memory safety does not mean "leaking memory".
It's absolutely possible to compute wrong pointer offsets. It's absolutely possible to dereference nil. It's absolutely possible to bork ownership and have multiple thread trample a struct. It's absolutely possible to reinterpret memory the wrong way.
I do agree that UAF is not possible (in most cases) due to the GC. That array indexing out of bounds is not possible. But it is by no means "memory safe" to the level Rust is.
> It's absolutely possible to bork ownership and have multiple thread trample a struct.
This is specifically the one place where go is not memory safe IMO.
> It's absolutely possible to compute wrong pointer offsets.
In Go? Without the `unsafe` package (at which point you are explicitly opting out)? How? There's no pointer offset in the first place.
> It's absolutely possible to dereference nil.
Yeah, but that's safe defined behavior in go equivalent to "unwrap"ing a None option in rust. It reliably crashes. It's not like C where it's undefined behavior and you might crash of you might just corrupt random memory or have the optimizer make your code do something even stranger.
It's (really the lack of non-nil types) is one of many reasons why go doesn't produce as reliable software as rust, but it's not a memory safety issue.
> It's absolutely possible to reinterpret memory the wrong way.
Again, without the unsafe package? How?
My Go is a bit rusty (pun intended), so I may have misremembered, especially with the pointer offsets. (just googled it, I did remember it, sorry for the confusion).
>> It's absolutely possible to reinterpret memory the wrong way. > Again, without the unsafe package? How?
Again my go is rusty, but I saw quite a bit of shenanigans in go with pointer casting from what's essentially a collection of void*. However perhaps those casts blow up at runtime? I'm too used to rust where it's explicit where it'll blow up.
>> It's absolutely possible to dereference nil. > Yeah, but that's safe defined behavior in go equivalent to "unwrap"ing a None option in rust. It reliably crashes. It's not like C where it's undefined behavior and you might crash of you might just corrupt random memory or have the optimizer make your code do something even stranger.
Agreed. I conflated "safety" and "robustness" here. The existence of nil is a thorn in the language.
Thanks for the corrections!
Using data races: https://www.ralfj.de/blog/2025/07/24/memory-safety.html
Right, that's the first category, "It's absolutely possible to bork ownership and have multiple thread trample a struct" resulting in undefined behavior.
Rust doesn't consider leaking memory to be unsafe.
I mentioned it because I often hear people (not in this thread though) that thanks to its GC preventing memory leaks, Go is memory safe. The GC's role in memory safety is preventing dangling pointers though.
> Great multithreading
Until you stumble upon the countless footguns. At least they generally don’t lead to memory unsafety, just garbage data.
Data Race Patterns in Go
https://www.uber.com/blog/data-race-patterns-in-go/
Zig in spirit is essentially Go without GC. If GC is not reasonable for your usecase Zig seems like an awesome choice. Unfortunately it's probably about 5 to 10 years out from being stable enough for most people being able to write serious applications in it though (notable exceptions being Bun and Ghostty, but they have solid effort behind them keeping them up to date with Zig).
More like Modula-2 in C clothing, given the safety guarantees.
If you're focusing on safety guarantees, sure. If you measure by safety checks included by default instead, it actually has more safety checks than Go (in particular, safety checked numeric operations for overflow).
The other big thing that makes it spiritually like Go is that you follow the same pattern of: allocate resource, immediately defer deallocation.
> If your code base doesn't mind garbage collection and doesn't depend on some external library, everyone should really look at go
I mean, at that point pretty much every language would be a decent choice.
>mention Go
>great error handling
why people so confident being so wrong???
Go has some of the worst error handling I've ever seen, even worse than most exception implementations IMO, and the type system is stupid enough that it's still very easy to write bugs. Go is only surface-level memory safe, you can definitely segfault in Go. And I mean real segfault, not nullptr dereference.
in the beginning I also hate it, but now is fine.
Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality.
Distributing Rust software is the pain that it is mostly because of how Cargo works. It’s pretty much impossible to sanely distribute something that isn’t a headache for downstream to consume.
> Cargo is absolutely awful. It might be better than cmake, but it still the worst part about Rust. It’s completely opaque, and intermixes a huge pile of different functionality.
"Absolutely awful" strikes me as wild hyperbole -- you also meant it this way as well, right? What toolchains are not absolutely awful in your mind?
Cargo isn't perfect by any stretch of the imagination -- there are a few common complaints that people have and a bunch of sharp edges (most of which have a github issue that has been open for years), but... "absolutely awful" has to be hyperbole.
Can you expand on your reasoning? Because the opposite seems to be true when it comes to projects like uv. People love the single-file executable -- easy to just compile that for a platform and have your users download it. It seems like the uv project is having a good time with that model, so I think they show it's not "impossible". Maybe they're doing something different I'm not aware of? Or maybe your use case is different, so what's impossible about your situation?
Isn't it also the npm model?
That sounds a lot like the issues some Linux distros are running into, where they expect to be able to ship one single blessed pre-compiled version of every library, and have each app load it dynamically at runtime.
But that's just not how Rust works: it's trying to fit a square peg in a round hole, and it isn't Cargo's fault that you have trouble with it.
Can you say more?
I’ve found it a joy to use compared to CMake and friends. How does it make it harder to consume something downstream? Seems easy enough to me - just share the source crate.
Are you trying to distribute pre compiled code or something like that? I can see how that would be harder - cargo doesn’t really support that use case.
How would you improve cargo?
> just share the source crate
That’s a nice concrete example of something that sounds simple but is a nightmare.
Let’s be clear: the goal is to distribute a tarball which the receiver can build. Crates won’t be packaged in the target host (that’s part of Rust’s design), so we don’t have any choice but to include them too.
But there’s no simple way of gathering all of these. “cargo vendor” fetches all transitive dependencies for all platforms. So if any dependency supports windows, you end up with 400MB(!) of windows-only dependencies, even if your project doesn’t target windows. This makes “cargo target” useless.
There’s “cargo-vendor-filtered”, a huge hack around this bug, but it’s also broke in subtle ways.
In the end, if you want to distribute a tarball which a downstream can build, you can’t. Cargo works online only.
Like I said: cargo is too opaque. There’s no command to generate a list of files that it would download for a build. There’s no command to fetch all “real” dependencies. It too opaque an monolithic, doing everything in one indivisible way. This is a great experience for the developer, but awful for anyone else.
> Let’s be clear: the goal is to distribute a tarball which the receiver can build.
Thanks for clearing that up. What problem does that solve? I've never tried to do that, but I can see how it would be a pain in the neck.
I wonder how hard that would be to fix. It doesn't sound like a difficult feature to implement in cargo. I wonder how amenable the cargo devs would be to adding something like that?
Uuuh how so?
Cargo is a blessing for any source-available project. All bundled up, a `cargo build` away. Because don't you dare say CMake or autotools are better, that's just the stockholm syndrome kicking in because you're familiar with it.
Seriously, how a CMakeLists.txt can even be compared to a Cargo.toml file? One is imperative full of arcane conditions everywhere filled with boilerplate, while Cargo.toml is a declarative manifest of the package?
Though there is one very sore point when distributing software, and that is for distribution package maintainers, because the whole ecosystem has been built around the C model and dynamic linking. That is not even the fault of cargo, since Rust's ABI is not stable thus dynamic linking would not work most of the time. Another thorn is generic stuff, which needs to be monomorphized, and as such don't work with dynamic linking (without Box<dyn>); C++ actually has the same issue and is why there are so many "header only" libraries for it.
I dislike Rust, but I would definitely prefer it over the "Android Studio Java / Kotlin thing", for sure.
I personally have zero interest in these feud wars. I'm only glad there are more quality options for Devs to develop safer system tools.
The only people I’ve met who seem to think it’s a feud war are a few dyed in the wool C++ fans who implicitly hate the idea of programming anything else. Rust is just a language. It has some strengths and weaknesses just like every programming language. Some of its strengths are incredibly compelling.
Personally I’m relieved that we’re starting to see real competition to the C & C++ duopoly. For awhile there all the new languages were GC, and paid for their shiny features with poor runtime performance. (Eg java, C#, Ruby, Python, lua, go, etc etc)
Rust is a fine language. Personally I can’t wait to see what comes after it. I’m sure there’s even better ways to implement some of rust’s features. I hope someone out there is clever enough to figure them out.
[flagged]
> That is a surprising opinion. Rust marketing is entirely based - like in this submission - on comparing its memory safety to C/C++ and saying that C is bad!
I'm not really sure what you expect here. Like, a large driving factor of using rust (compared to C/C++) is that it has better memory safety. Should rust not talk about that? Should we try and be careful about the feelings of C/C++ devs and not name the truth in the room around memory safety?
The reason android is moving to rust is because it decreases the memory related defect rate compared to C++. Should we shy away from talking about C++ memory bugs because they're somehow embarrassing?
When C came out, I'm sure a lot was written about how much easier it was to program in compared to assembly. Does that mean there's a feud between C and assembly? I'm sure some assembly developers felt under attack. But its not a feud. Just two tools with different use cases. That's how I see C and rust.
> Even in its own "memory safety" definition, which is the first result on Google, they criticize C instead of providing a proper definition:
I'm not sure that page is intended to provide a definition of "memory safety" in the first place? It (and the following page) seem more intended to introduce safe/unsafe Rust and the boundaries between the two.
It's also from the Rustinomicon, which states:
> Unlike The Rust Programming Language, we will be assuming considerable prior knowledge. In particular, you should be comfortable with basic systems programming and Rust.
So it's arguably unsurprising that a definition of memory safety would not be found there.
My guess is that if you want a more precise definition you'd want to look at the Rust Reference (e.g., [0]) or in related areas.
[0]: https://doc.rust-lang.org/reference/unsafety.html
I don't think materially contrasting yourself with your direct competition quite constitutes a "feud war"
The downvoting patterns of anything that is mildly critical of Rust (see above) very much indicates a feud war. Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.
The Rust literature is poorly written compared to C and Ada and the argumentation style on forums is sloppy, aggressive, and often unintelligible.
Which is a pity, because the language itself does not seem to be so bad.
> Rust has a dogmatic, aggressive and self-righteous community that uses any available tactic to push their language through.
I'm confused, because that's not been my experience of the rust community at all. I've been very critical of certain aspects of rust over the last few years, and I've (for the most part) gotten fair, reasonable feedback in response.
> The Rust literature is poorly written compared to C and Ada
I'm even more confused. Which literature are you looking at? Can you provide some examples so we’re all talking about the same thing?
I find most of the documentation around rust to be the best in the business. Eg here's the reference documentation for iterator trait, in the standard library:
https://doc.rust-lang.org/std/iter/trait.Iterator.html
Every function in that interface is well documented, with examples.
Here's the equivalent for C++:
https://en.cppreference.com/w/cpp/iterator/iterator.html
Where is the rest of it? This doesn't describe how iterators work at all. Or how to use them. There's more stuff in the header file but its inadequate by far.
So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:
http://www.lmdb.tech/doc/group__mdb.html
In rust, any published crate automatically has a docs.rs/cratename link. Eg for serde's reference manual:
https://docs.rs/serde/
And then for the "guide" style explanation they wrote a book:
https://serde.rs/
Where is any documentation for the C standard library? As far as I can tell, there's no official documentation at all. There are man pages. But in comparison to rust's docs, or mdn for javascript, man pages are nowhere near as good. I’d give examples but this comment is too long already.
> So much C library code is documented in ad-hoc ways - often through doxygen, which is a disaster. Eg here's the documentation for LMDB. LMDB is one of the most thoroughly documented C APIs I've seen, but I find this almost totally unusable. I often find myself reading the source instead. There's not even any links to the source from here:
> http://www.lmdb.tech/doc/group__mdb.html
How is doxygen a disaster?
Why do we need links to the source code? Doxygen is already embedded in the source, you should already be reading the source code on your local machine. It makes no sense to go searching across the web for information that's already stored on your local machine. Especially since you have no idea if the version you find on the web matches the version you're using locally.
Nope, Rust compiler depends on LLVM and GCC (ongoing), both written in C++.
Then there are enough industry standards that are defined for C and C++, where Rust isn't even visible.
It really depends on the type of software.
I mean we know for sure Rust is unsafe there is whole bug tracker dedicated to all the ways it's unsafe. My favorite is that you can cast any lifetime to static no matter how short it actually is in 100% safe Rust.
(doesn't mean it's not an improvement on C++)
I think referencing the well-known cases in cve-rs[1] is quite a bad faith effort. Of course if you try reeeally hard to write unsound code, you can write unsound code. An edge case in the type system downstream of lifetime variance rules is simply not something that matters in any practical attempt to write safe software. I find the tracker interesting since it probes the boundary of the compiler, but it says absolute nothing to the effect of "Rust is unsafe".
[1] https://github.com/Speykious/cve-rs
The unsound bug tracker is were my heart gets all warm and fuzzy in Rust land.
All the ways to coerce and poke the implementation of what should be safe constructs to produce unexpected garbage - and people spending time fixing the issues because they are treated as bugs.
It’s like the best possible advertisement for ”we enable soundness and correctness for all your programs.”
https://github.com/rust-lang/rust/issues?q=state%3Aopen%20la...
This doesn't 'cast' anything. The compiler prevents this because it would allow references that outlive their owners. Freely 'casting' only works for data that is static in nature anyways, at which point a coercion is taking place. Any other way involves `std::mem::transmute` or `Box::leak` and the like.
Here is a nice segfault in perfectly legal safe Rust https://play.rust-lang.org/?version=stable&mode=debug&editio...
I'd call it casting thought technically maybe it's not you might want to call it something else? You don't need transmute or leak. The issue is only 10 years old now https://github.com/rust-lang/rust/issues/25860
Yes, that's an existing soundness hole in the compiler. You won't accidentally code it up yourself though.
If the bar is "deliberately malicious code results in a segfault", get back to me when they fix
EDIT: and even that's being charitable; the Rust issue is viewed as a compiler bug which should be fixed.Id like to see dev time in Rust vs C++, but generally, I sort of agree. If you use modern C++ with all its features, Rust is generally a better alternative.
That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.
> That being said, it would be pretty easy to implement some pointer semantics even in C that can do 95% of what Rust does.
Making a language with memory-safe pointers isn't hard. Making a language with memory-safe pointers that doesn't rely on sandboxing, a virtual machine, or other dynamic checks which produce runtime overhead--thereby disqualifying one from being considered for this domain in the first place--is nontrivial.
Rust has things that have dynamic runtime check overhead that are often used. Reference counters, array size, e.t.c You have to have runtime checks because of Rice's theorem.
The only way around this would be to have a absolutely strict type system that defines the finite sets of data that memory can hold.
But for compile time checks, its not hard. For example, the I would do it C is that every pointer gets an optional permission id through some syntax when created. Any expression involving modifying that pointer needs to have the appropriate permission id stated, any dereference operation needs to have the appropriate permission stated, and free is only limited to the function where the pointer was created with malloc. Then any pointer created in assignment from an expression involving that pointer inherits the permission id.
So you simply have a system of tracing where memory gets used.
But all of this is overkill tbh, when you can just use existing static memory analyzers that pretty much do the same thing. And coupled with dynamic memory analyzers like valgrind with appropriate testing, you don't even need to do runtime checks within your code.
So your claim is that sufficiently careful C is just as safe as rust?
Seems like a pretty wild claim to make in the comment thread of this article. Google has some of the most careful engineers in the business. They use valgrind & ubsan & friends religiously. And yet this is their conclusion:
> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.
C is not as memory safe as rust. And it cannot be made as safe as rust with a few bolted on tools and programming tricks.
And tell me how that pointer semantics would do * a very strict type checking * Pattern matching * Algeberic data type
Plenty of people don't write Rust for additional memory safety, they write Rust because the features provided by it is overall very balanced & encourages developer to write code which handles almost all edge cases.
The thing about Rust is you pay for everything up front, and the dividends come later. You pay first to learn it, which is not easy. Then you pay every time you have to compile your code, which can kill development momentum. When you are learning, often times this manifests as a moment where you have to completely rearchitect your approach because plowing forward is too costly. It's at this point a lot of people say "Rust is too hard!" and they give up.
But if you stick it out, as Google has, the dividend is that more often than with other languages, you are not paying these costs continually but instead reaping dividends on the long run.
First of all, Rust has the Haskell-like property that (as long as the logic is sound) if your code compiles, it usually runs just fine. This is why testing speeds up, because all of the edge cases that are explored during testing were already accounted for by the compiler.
It also translates into easier refactoring, where you can make sweeping changes in the codebase and feel confident that you can put it all back together again.
And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!". Fast is a feature, and your users benefit from it every time they run your code.
It's hard to find that nexus of features in other languages. Usually they are just as fast and hard to write as Rust, without the safety guarantees. Or they are just as safe as Rust, but without the speed. And that's why Rust has hit a sweet spot where other languages can't quite get it.
Yeah, I use Rust at work and it's a boon.
It's so easy to bake in proofs/invariants into types, yet you still retain control of the memory model.
One of the main features of Rust is the community, there are so many great packages
Something that will replace/build on Rust in the future is a language based on Two Level Type theory, where you have zero cost abstractions with a language that can do full dependent type theory
I'm glad you said that because that's exactly where my research is ^_^
https://andraskovacs.github.io/pdfs/2ltt_icfp24.pdf
I think that something like this is the endgame practical programming language
I think Rust is easier to learn than C++
I agree with you as long as you don't know C++ first. I actually teach C++ and Rust to students who only know Java, and they have a much easier time picking up Rust. It's the people who approach Rust with C++ idioms who have the wort time with it. It comes down to the tooling, especially Cargo being the one-stop-shop for everything Rust. Another poster here laments that Cargo is too overloaded with disjoint functionality, but that's actually a benefit for a lot of learners.
I think tooling is big and people underestimate the lingering cognitive overhead of simply building C++ with arcane CMake files, but honestly it's more that much of Rust is informed by problems in C++ that they didn't have to inherit and don't have to maintain forever.
Like for example, how many ways are there to initialize a variable in C++? Which are you supposed to use?
C++ is the hardest, most difficult programming language to write correct (according to spec, not in the ‘it compiles’ sense) programs in ever created that isn’t a toy or specifically designed to be hard like malbolge. It takes a decade of writing it daily to realize that you know nothing, precisely because the compiler does not reject so many invalid programs.
>if your code compiles, it usually runs just fine.
This was the same argument for Java, which is memory safe, fairly strict in terms of ownership.
The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
The dividends never get there if you don't ever run into this.
>And then there's the fact that the programs themselves are fast. How many times has uv been brought up here and the #1 remark people have is "wow it's so fast!"
This is a vibe at best. The speed difference is surely there. But it makes very little difference when there are much slower things in the entire workflow, like pulling things from the internet.
Basically, Rust is a good choice for a small subset of things. Android happens to be one of them, because a) you need native code performance, b) you have multiple teams working on many services and c) you have a somewhat closed ecosystem where you control a lot of the low level things. Because of all of this, double frees are a real threat and can pop up as you are passing data around without strict checks.
> The fact is, Rust addresses only one memory safe thing, and that is double free. If you don't understand why that is, you probably shouldn't talk about memory safety.
How does Rust not address use after free?
Not to mention out-of-bounds access, uninitialized memory, invalid type casting, and a ton of insidious sources of undefined behavior
Most of these will usually make a program crash. Crashes are testable and not a memory safety issue. Exception handling was created specifically to deal with this.
Use after free is generally VERY hard to exploit. Double free can corrupt data structures more with control. Use after free is basically at the mercy of the allocator and program state, where whatever gets written to the same memory address may or may not be relevant.
There is a reason why most vulnerabilities these days are either higher level logic bugs, or things that require code execution on the machine.
Most of these is confirmation of easily observable reality, but the 4x difference in rollback rates, jesus christ.
We all knew rust was safer. It was the 1000x number that surprised me.
Which is more that rust isn’t that safe in my mind, it’s that bugs are that prevalent. I never would have guessed that.
That 4x rate is very impressive too.
Great seeing all this data from a large big complicated codebase.
The issue with most codebases is nobody thinks about starting out with acceptance testing system.
The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests or a subset based on what you are working on.
This is essentially your contract for software. And on a modular level, it means that it scopes down the contracts to the individual sub systems. And things like memory and cpu runtime constraints are a part of this.
If you have this, you basically replace what the Rust compiler is doing for you with tests. Memory leaks are caught. However, as a benefit, you also can verify changes in the dev cycle with things like performance degradation, all in the same system.
I'm not sure that nobody thinks of this. We just have a finite amount of time. Usually with a solid approach, you get solid performance. Fixing a performance related bug rarely when it comes up, is still a time savings over designing this kind of rigorous process from scratch, and getting everyone on board with it.
Getting rid of a whole host of bugs due to the compiler is a big deal because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it. If you can solve this seamlessly I think that's an interesting product that others would be very interested in.
> because you won't have to design this extra acceptance system or deal with keeping an entire organization disciplined by it.
This is just a matter of tooling. (On that note, here is a free business idea, prompt engineer an LLM agent that sets this up for you)
While the compiler does do a lot of things for you, you still end up with things that you should check because compiler doesn't understand your program logic. If Rust was a absolutely strict typed language, where basically everything had a type that defined what data it could hold, then it would be a different story. For example, when parsing a json into an object, instead of strings/numbers/bools, every single field has a finite set of values that it can hold. Then the compiler can figure out a lot of things. For example, if you try to convert a string to int, if the string field type doesn't have a defined regex expression it must match, then the compiler can catch this.
Anything less then that, you are better of writing the validation system once and reusing it for all your code bases now and in the future.
> The way it should work is that before even writing code, you design a modular acceptance system that runs full suite of tests …
Sometimes. It depends on what you’re working on.
Part of the fun challenge in writing software is that the act of programming can teach you that you’re wrong at every level. The syntax can be wrong. The algorithm you’re implementing can be wrong. The way you’re designing a module can be misguided. And you might be solving the wrong problem entirely! Like, maybe you spend weeks adding a feature to a game and it makes the game less fun! Oops!
Tests formalise beliefs about what you want your code to do, at some level of abstraction. But if those beliefs turn out to be wrong, the tests themselves become a headwind when you try and refactor. You want those early refactoring to be as easy as possible while you’re learning a problem space.
Now, some programs don’t suffer from this as much. If you’re implementing a C compiler or drop in replacement for grep, you have some clear acceptance tests that will almost certainly not change through your project’s lifecycle.
But not all problems have clear constraints like that. Sometimes you’re inventing a programming language. Or writing a game. Or making a user interface. In my opinion, problems that are fully constrained from the start are some of the least interesting to work on. Where’s the discovery?
> Part of the fun challenge in writing software is that the act of programming can teach you that you’re wrong at every level. The syntax can be wrong. The algorithm you’re implementing can be wrong. The way you’re designing a module can be misguided.
I see you sir haven’t had experience with writing drivers for prerelease hardware. You’re right in these cases of course, you just aren’t right enough - the real fun starts when you can trust neither the hardware, nor the BIOS, nor the OS in addition to all the above.
I will simply say that Google is one of the few places that, to a first approximation, has this. We have our (pretty good) suite of tests. We can run only affected tests. We can them with instrumentation (*SAN), we can run them under various memory and CPU limits, we can run them 1000 times in parallel to deflake.
Anyway Google has all of that, and yet still finds this improvement.
Android testing standards aren't necessarily the same as the rest of Google. At least historically it wasn't, I'm sure things have improved.
Writing the tests before the code only really works if there's an interface that's fully defined and well specified in advance. There are definitely times where that is the case, but in my experience it usually doesn't work like that.
It doesn't work like that because people are afraid to change things up. Lots of time people want to see working code that works for nominal use cases before hand.
No it's because often designing the interface and writing the implementation go hand-in-hand.
If they use Rust for new code and C++ changes are all in old code, this could be explained just by older code being more risky to change.
Funny, another commenter on this post was saying the opposite, that Rust was likely being used to just port existing features and that was easier because there were probably good tests for it already.
If you've actually written considerable amounts of Rust and C++, these statistics don't require justification. In my opinion it's completely expected that Rust code is easier to write correctly.
As a relatively novice programmer who's worked in tech for decades but not as a software developer: I take issue with the idea that you need to write considerable amounts of Rust and C++ for these statistics to be expected. In fact, despite Rust's initial vertical learning curve I'd say that any junior developer trying to implement anything with any degree of complexity at all in Rust and C++ would see the benefits.
At the very least, the fact that IDE integration can tell you all kinds of stuff about what you're doing/doing wrong and why accelerates things greatly when you're starting out.
The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation, because the compiler will reject most random changes to the code. Which is the point of course, but C++ will compile programs which then crash, giving you a very misguided feeling that you’re making progress, but this is very important in the process of gaining new skills.
I don’t see a way around it, programming without garbage collection is hard, Rust makes it very clear very quickly, which is also the point, but this is at odds with making the learning curve accessible.
> The problem with junior developers is that Rust will be incredibly frustrating to learn by perturbation
Yes, this is the biggest issue with Rust that I've seen; most language will let you do something wrong and then as you learn you get better. Rust will refuse to compile if you're not doing things correctly (and normally I would put 'correctly' in quotes but correctness in Rust is well defined).
The first time I tried to experiment with learning Rust was a disaster. I just wanted to decode some JSON and filter it, but -- oops! -- I don't own that variable. Okay, well I can pass it somewhere else mutably, right? But then that function does the work and returns something that... what's a lifetime? What's a 'a mean? How do I... screw it, I'll go back to Python.
Eventually, after the tooling and the tutorials got better I came back to it and really enjoyed what I've seen so far and even rewrote one of my own personal tools in Rust[1] to experiment with. It's nothing impressive, but it was fun to do.
[1] https://github.com/danudey/rust-downloader
Oh I totally agree with you.
The logic in my comment wasn't that you need to have written considerably amounts of code to be expecting this, just that to not be expecting this would make me think you hadn't. If that makes sense.
On your second point, I think IDE integration for C++ is similar as it is for Rust. Just Rust errors and tooling are a million times better regardless of IDE.
Oh, the more junior the developers, the quicker they will get any benefit. That's common for any language that enforces correctness, but the C++ vs. Rust comparison isn't even fair; C++ is an incredibly hard language to use.
Now, if they actually "see" it is another matter.
I’d say the same applies for Swift vs ObjC.
Let’s end the C era.
Apple should have modernized ObjC instead of making Swift the lingua franca. Both speed of iteration and flexibility (on which web-stack-rivaling productivity features would have been possible) are gone forever.
Swift Concurrency is a tire fire that not even their async-algorithms team can use completely correctly, and useful feature like typed throws are left half finished. The enormous effort the constant further bastardization of Swift takes, is at least in part the reason for the sorry state dev tooling is in. Not even a 4T dollar company can make a reliable SwiftUI preview work, in their own IDE. Variadic generics (a seemingly pure compiler feature) crash at runtime if you look at them the wrong way. Actors, the big light tower of their structured concurrency, are unusable because calls to them are unordered. They enforce strict concurrency checking now, but the compiler is too dumb to infer common valid send patterns; and their solution to make this abomination work in real codebases? Intro a default that lets _everything_ in a module run on the main thread per default!
</rant>
Swift has so many issues they would honestly be better off just moving to Rust rather than fix Swift. Seriously. The fact that it's so easy to get the compiler to spend exponential time resolving types that it very often just shits the bed and begs you to rewrite your code for it to stand a chance is shameful coming from, as you say, a $4T company. Points to deep problems with Swift.
I fully, totally agree with this. The recent fixes for concurrency makes Swift look like a poor man’s Rust anyway.
I don’t disagree with anything you said.
While the C calling convention continues to rule operating systems and FFIs, I think it’ll continue to limp along. Hopefully one day that can be fixed, it’s annoying that C is what I have to reach for to call SomeLib no matter what language I’m using
I think they're comparing new code in Rust vs new code in C++.
I found it interesting that the rollback rate remained more or less constant despite size differences.
This isn't control for confounding factors.
For example: folks are more likely to rewrite stuff that is well-understood, and stuff that is well-understood is going to have shorter review times and lower rollback rate.
That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more rollbacks, and less likely to be rewritten.
The first chart does in fact a compelling reason to believe the effect is not that at all. If the "easy" code was predominantly being rewritten you would expect to % new memory unsafe code and % memory safety vulnerabilities to scale at different rates as the difficult to work on areas remained in C and kept causing new memory vulnerabilities.
Personal experience also provides a compelling reason, my experience is absolutely that people are more inclined to rewrite the things that are causing trouble in a new language.
It's not a blinded randomly controlled trial of course, it's observational data. You can't be completely sure there isn't a confounding factor that explains the data, but it seems far more likely than not that it is a real effect.
I would expect memory safety vulns to be dropping in most C/C++ projects due to better practices
This contradicts what Google has reported about their own code, which is that most vulnerabilities are in new code
I haven't looked at Googles style for c++ in a long time, but from what I remember it was actively hostile to best practices. Actively hostile to any improvement introduced by the language and actively hostile to the wider ecosystem of c++. Also Rob Pike was involved somehow at the time and that guy went around claiming that his C inspired GCed language would be the perfect replacement for C++ everywhere after the c++ standard simplified some common patterns for library authors because he was actively hostile towards reusable code.
I am not sure I even want to know what the average Google C++ codebase looks like.
I don't see a contradiction between the statement that vulns in C++ code are generally on a downward trajectory, and the statement that most vulns are in new code.
This is basically the C++ treadmill for decades and I think people are starting to realise they were duped.
Bjarne's C++ promised that if you use this instead of C you won't have these problems. The problems persisted of course. Then it was well you need to use standard C++ 98 not that crap pre-standard C++ you've been doing, once you adopt C++ 98 the problems will subside. Then it's you need "modern" C++ 11, of course you've got problems, that's because you used C++ 98, use this "modern" C++ instead.
By around 2020 they started to say the "modern" C++ 11 wasn't up to it, you need to write "contemporary" C++ 20 or better.
What was it George W Bush told us? "Fool me once, shame on...shame on you. Fool me...you can't get fooled again".
You would be severely disappointed.
> That gnarly horrid mess that only a few greybeards grok and has massive test coverage, a long tail of requirements enforced by tests and experience, and a culture of extreme rigor? Longer reviews, more rollbacks, and less likely to be rewritten.
I'd say that this is likely the most likely to be rewritten actually, because high test coverage is a massive enabler in such a rewrite, and because having a project that “only a few greybeards grok” sounds like a big organizational liability.
That being said, and while I'm pretty convinced that Rust bring massive benefits, I agree with you that these measurements shouldn't be taken as if it was a rigorous scientific proof. It's more of one additional anecdotal evidence that Rust is good.
> It's more of one additional anecdotal evidence that Rust is good.
But that means it's likely to be the worst kind of science:
- Group of people agree that Rust is good. This is a belief they hold.
- Same group of people feel the need to search for argument that their belief is good.
- The group does "science" like this.
And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion.
> And then the rest of us have a data point that we think we can trust, when in reality, it's just cherry picked data being used to convey an opinion.
Calling what Google did here "science" and cherry picked is quite a disservice. It's observational data, but do you have any objection to the methodology they used? Or just (assumed?) bad vibes?
In science, you go out of your way to control for confounding factors.
This isn't that.
> In science, you go out of your way to control for confounding factors.
There's tons of observational science done in a very similar fashion to the article where there is simply no way to control for confounding factors for the same reason that there is simply no way to properly control for it in the data available.
It’s a good start and even if error bars are wide enough to land a 747 in them their numbers show orders of magnitude scale differences. This should raise eyebrows at the very least in the biggest skeptics.
Going out of your way would involve committing unethical experiments, which is absolutely frowned upon by scientists.
And many experiments are simply impossible to do in a manner that completely removed every outside factors. But that doesn't mean that an experiment's results are immediately bad.
Having been close to someone who went through the PhD process to a career in research, this is a sadly common but romantic and incorrect view of science as practiced in the world today.
A lot of what folks call science isn't science.
So, I'm not being romantic. I'm being realistic. And I'm happy to call B.S. on a lot of published research, because doing so gives me more predictive power than that research
I'm the first one to be annoyed when political scientists and economists pretend to do science when they are just extrapolating from anecdotal correlations, but here this isn't something being published in a scientific journal and nobody claim they are doing “science” in the first place.
This article is mostly about new code.
This, from my limited experience working on AOSP at Google, only the newer code were being written in Rust, not the existing code. But that was 2 years ago.
That is somewhat mitigated by grouping comparisons of S/M/L change sizes.
It would be interesting to group changes by line-deletions, say to indicate rewrites (and size of them)
> Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in Rust, making it easier for Chromium engineers to deal with data from the web
I find this surprising, isn't Wuffs[1] (also made by Google) an even better fit for this particular use-case? (It has compile-time spatial memory safety, where Rust has compile-time temporal safety but runtime spatial safety, with bound checking).
Obviously for general-purpose system programming, Rust is a no-brainer and I'm happy to see Google pursuing their rustification of Android.
[1]: https://github.com/google/wuffs
I don't find it surprising, just from barriers to adoption: "Wuffs programs take longer for a programmer to write, as they have to explicitly annotate their programs with proofs of safety" is a hard sell (even if it has obvious value) and "you have to learn and integrate yet another language just for parsing files" is a hard sell too.
Which isn't to say that it shouldn't be adopted (having not used it I really don't know), just that it's not surprising that it's having difficulty gaining traction.
If you're parsing untrusted data, then some level of runtime checking is unavoidable. And Rust's pretty good at letting you encode "I already checked this and therefore don't need to check it again" into the type system.
Rust is good, don't get me wrong, but bound checks are still reason why you occasionally need unsafe to get the maximum performance, because not everything can be expressed as an iterator where bound checks are automatically eliminated.
If you check Wuffs repo, you'll see benchmarks very favorably comparing to rust implementations.
And it's not surprising, wuffs is to spatial safety what the borrow checker is to temporal safety. And regarding spatial safety rust is kind of like where C++ is in terms of temporal safety: it has the choice between unsafe or runtime check hopping that a large fraction of them will get eliminated by the compiler.
I use rust for gamedev (not bevy). I'm unlikely to consider anything else exactly because of stability and throughput.
Always curious to hear from people doing Rust gamedev without bevy! What are the main crates you're using, and what sort of game object architecture are you going with?
I do hobbyist level gamedev in my spare time and found bevy to be a bit too much for the things I want to do.
At this point I feel like it's no longer an uphill climb to get Rust into foundational, mission-critical code adoption. The benefits are so obvious. Maybe it's just a lingering religious war?
In any case, I'm glad we're seeing more and more evidence and case-studies of why "rewrite it in Rust" isn't just a meme.
Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C!
It's all nonsense, but it would be hilarious if it weren't so ignorant.
The irony is that those haters have been doing the same speech since Ada, Modula-2 and Object Pascal early days.
Multics got an higher security score than UNIX, thanks to PL/I.
During the USENET flamewar days, they used to call programming with straightjacket languages.
Also note how proudly they keep digging out Brian Kerninghan complains against Pascal, that disregard the dialects have taken out those issues, and that while Pascal was designed for teaching, Modula-2 was already available, taking care of those pain points, designed for systems programming.
>It's all nonsense,
How is any of that wrong?
It's all correct and also pointless and irrelevant. It all boils down to "Rust doesn't fix every possible problem so why not stick with something that still has every possible problem?"
In other words, they're upset that a new thing isn't popular so they're trying to think of any argument against it, but none of their arguments are relevant. Yes, you can still write bugs in Rust; of course you can. What you can't do is write memory safety bugs in Rust, which are a huge proportion of security bugs that occur. Rust gives you a massive decrease in attack surface automatically.
This is ignoring the ecosystem, which is full of better tooling, better library packaging, better testing, and just in general an overall better language, but instead of trying to argue the language on its merits they're trying to argue that it's not perfect so why bother.
I've also heard the same arguments about C++; 'anything you can do in C++ you can do in C!', which is technically true but ignores the fact that if I want to do something C++ does it usually makes more sense to use C++ to do it rather than e.g. trying to hack the concept of objects, private methods, templates, etc. into C myself.
1. You don't know what you're doing - everyone makes mistakes.
2. You can still write bugs in Rust but the point is you are far less likely to.
Yeah but 1000x less mistake ????? I mean these people behind android project is atleast one of the better engineer but jesus christ if they can improve so much then I dont know how much average joe can benefit from that
It's not 1000x fewer mistakes overall, it's 1000x fewer mistakes of this one specific family that Rust is designed to eliminate.
They've also seen improvements in developer confidence and onboarding time, but not to the same degree.
>You don't know what you're doing - everyone makes mistakes.
I mean if you don't know what you are doing you are going to make mistakes that go beyond memory safety. Look at Log4shell for example.
The important thing is the likelihood of mistakes getting past the compiler. According to Google's numbers the likelihood for memory safety reduces by several orders of magnitude, and the likelihood for other kinds of mistakes reduces by a factor of ~4 (depending on how you interpret their numbers).
Just saying "but you can still make mistakes" is dumb and irrelevant and it's kind of disappointing that it's such a commonly bandied non-argument that Google still had to address it in this post.
On the sense that you can write a Rust compiler in C and use it to program your software in a better language, yes, all of that is correct.
It isn’t wrong, it’s misguided. You can write the same code in a Turing machine, too.
Sure, but the discussion against Rust is basically saying that you can have the same features without the downsides of using Rust, which is objectively true. For example, memory analyzers like valgrind work great.
If you assume that the only benefit of using rust is built-in valgrind, sure, but there's more to the language than preventing off-by-one errors.
If people don't want to use the language then that's fine, no problem, but a lot of people do want to use the language because it's just a great language to use as well as having memory safety.
But the approach here is "write new code in rust", not rewrite.
Google rewrote Android's Bluetooth stack in Rust.
Also mentioned:
Eh, I don't think it's actually one or the other. Google has taken on rewriting some more problematic components in rust. See for example:
Binder kernel driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Media codecs: https://www.androidauthority.com/android-16-in-process-softw...
This is also happening at Microsoft:
> Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library
https://www.microsoft.com/en-us/research/blog/rewriting-symc...
Yeah, there's also a freetype replacement https://github.com/googlefonts/fontations
I think they're trying to avoid rewriting things for no reason though. The things being rewritten tend to have a history of security problems or other issues that would be cause for a rewrite even if it wasn't in Rust.
That ends up being "rewrite it in Rust" because new code includes changes to existing code. A nice thing about Rust is that you can generally rewrite things piecewise there's no need to switch everything at once.
Sure, but at a macro level the approach is still to "rewrite" Android subsystems in Rust. Just slowly.
Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper.
That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing against its adoption for everything.
When you see shit like "[...] should be rewritten in Rust because memory safe", it shows that people have no idea what memory safety even is. There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
The downsides of Rust is that its ownership semantics are often cumbersome to write, which slows down development. Rust is also still evolving because of the stuff that happens under the hood. And for a lot of things, where network latency is dominant and cpu cycles are spent sleeping waiting for responses to come back, you don't need natively compiled code in lieu of python or node that are way more flexible and faster to develop in.
So in most cases, Rust is not applicable, when you can write perfectly memory safe code faster.
>Show me a nontrivial project in either of those languages that has never had a memory safety issue
I mean, the linux kernel is a pretty good example. Static analyzers and things like valgrind exist for a reason.
There's been over a thousand memory safety CVEs in the kernel this year alone [0], the most recent published 2 days ago. Most of these aren't exploitable and are caught before stable, so I went to LWN instead and "scrolled down" until I saw an article that mentioned a memory safety vuln in stable kernels. "Scrolled down" is in quotes because there was no scrolling involved. Today's Friday security updates post links USN-7861-3 [1], which includes fixes for memory safety issues like CVE-2025-37838 [2].
[0] https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
[1] https://lwn.net/Articles/1046495/
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-37838
> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
I sense a lack of statistical education here.
If you say that something can happen, then whether to use a tool to mitigiate it should also be qualified. The conversation around Rust is that bugs WILL happen, which is not true.
we'll have to agree to disagree.
> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
lol. this take is hilarious in the face of the article you are commenting on. holy cognitive dissonance.
> The downsides of Rust is that its ownership semantics are often cumbersome to write
skill issue
>skill issue
Lol, this is actually very ironic considering Rust is handholding you because you don't have the skills to write memory safe code.
Like I said in my other posts, Rust makes sense in very niche situations. The article just proves that it works for the niche case where its applicable. That doesn't mean Rust automatically wins.
Readers, feast your eyes on direct evidence of how facts don’t change people’s minds. You can almost see him putting fingers in his ears and going lalala
My friend told me he likes writing rust because he loves doing things that have already been done his senior pushed management to rewrite in rust and got approved after 2 months, he jokingly told him I guaranteed us a job for the next 3 years rewriting will take time. One paycheck collection strategy push Rust -> get adoption -> rewrite code (now memory safe yay) -> collect paycheck rewriting . In the meantime others will write memory unsafe code for you which is new and provide you a paycheck guarantee and the rust compiler helps you take your time when rewriting you can read the old code while it compiles.
I don't understand the graphs presented here. On the first graph showing "New Memory Unsafe Code" and "Memory safety Vulns" we don't have any steady state. The amount of both "unsafe code" and "memory safety vulns" had apparently already been dropping before 2019. None the matter though, we see a great big drop at 2022 in both.
Then in the next graph, showing "Rust" and "C++", we see that the amount of C++ code written in 2022 actually increased, with rust not really having gained any significant momentum.
How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".
Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
> How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"? Somehow an increase in C++ code led to a decrease in the amount of both "New Memory Unsafe Code" and "Memory safety Vulns".
The first graph considers <memory unsafe> vs <memory safe> languages, while the second graph considers C++ vs Rust. There's more languages than just those two in the first graph.
Moreover the first graph is in percentage terms, while the second graph is in absolute terms.
In 2022 it appears a bunch of memory safe non-rust code was added. Java/python/...
> Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
That's a perfectly human phrasing lol.
I’m a little perplexed why every time something in rust compiles, there’s a blog post about it. I was under the impression Ada, especially when using provers, has been around much longer and is more robust. I just can’t decide if the massive Rust evangelism budget is a red flag or just a curious sociological case study, but I wish I knew the truth.
Rust has the twin features of significant technical merits and a powerful hype machine. In truth, it's neither the devil nor the best thing since sliced bread. It has enough traction that the tooling and developer experience are always improving, and appeals to a wide range of uses. Rust was lucky enough to get noticed when it was decent pre 1.0, which motivated the community to make it excellent at 1.0, and it's been making history ever since. I think Rust got critical mass because it had a bold vision and focused on developer experience enough to get buy in on improving its performance and robustness. Ada is wonderful, but it's less pretty, and doesn't make pretensions. In that sense, Rust was built for the hype, but the language has benefitted greatly from all the attention.
A good comment except for the "it's less pretty" claim. The Rust I've looked at seems incredibly cryptic by comparison.
The history is kind of weird. Graydon was ejected out of his own language and then a machine took over. That is really unusual, and I’m not sure there is an analog anywhere.
> Graydon was ejected out of his own language
That's not what happened at all. Graydon voluntarily stepped down because he didn't want to be in the role of BDFL. It's true that he wasn't a huge fan of the "C++-ification" of the language, but he wasn't pushed out or anything, and definitely could have stayed on steering the project as long as he wanted to. I think there are a number of other languages that would have benefited from a similar approach, actually.
> I’m a little perplexed why every time something in rust compiles, there’s a blog post about it
Crucially Rust is a very pleasant developer experience. Out of the box tooling is smoother, the compiler diagnostics are much better than peer languages†, the community are nicer, and so on. When you wrote safe Rust which compiles you get software that does what you wrote and not something else, which seems like a very basic thing to ask for but neither C nor C++ can do this. People respond well to a more pleasant environment.
† I wrote the one where if you write 'A' (the Unicode character capital A) but actually meant the ASCII byte 65 the diagnostic suggests writing b'A' instead rather than just telling you that what you wrote is a type mismatch.
[dead]
> How can one possibly square those two pieces of data to point at rust somehow fixing the "memory safety vulns"?
The code base contains Kotlin and Java as well
> Also "this approach isn’t just fixing things, but helping us move faster." is an AI red flag.
Who do you think AI learned it from
It'll be interesting down the road to see how this affects the rate of security bugs that are not memory safety related.
This was a great breakdown. Loved the different aspects they captured beyond memory safety, including the skill improvements within the team as they grew comfortable.
I thought this article was about using Rust for mobile development, like Tauri on Android.
The graphs aren't showing up for me on the site unless I click on them
now ahow me how rust can protect us against tech giants doing sauron moves on our software ecosystems?
Rust allows us to collect paycheck rewriting code, rewriting code is so much easier since you do not have to think much about the underlying business you already have the code it's purely technical also you can just collect paycheck rewriting code for quite a while since most code bases are large easy money if you already know rust.
[dead]
Don't let Lunduke Journal see this post, he might have an annurism.
This would be great if it weren't such a hasty generalization. A comparative analysis against alternative approaches like continued hardening of the legacy code base would have been better to read through. This suggests there is no middle-ground to be had which we know to be false. And all this while oversimplifying legitimate engineering trade-offs like build system complexity and developer retraining costs.
Relying on Google as a credible institution rather than independent verification results is what can only be described as self-evident truth. This is corporate tech evangelism that only benefits Google.
Why does the article avoid adoption barriers due to Rust's steep learning curve? Why does the author gloss over maturity gaps in the toolchain? Why isn't there feedback included from the maintainers of the critical components like HALs and other drivers?
Rust is older today than the K&R Book on C was when Windows, Linux and NextStep were started. Although C was started earlier, it wasn't widely known about until after said book... Let alone C++
They’ve already written about it?
https://security.googleblog.com/2023/09/scaling-rust-adoptio...
https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...
And other posts.