Comment by habibur

> 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.

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.

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.

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 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

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.

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 ?

> 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?*

To me, those sound like meaningful pros and cons, not a reason to completely dismiss it.

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.

Your reply isn't necessarily "polite" but your reaction and is entirely appropriate considering the headaches these people are bringing

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.

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).

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.

> 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.

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.

> 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.

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.

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++.

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.

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.

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.

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.