21 ms·

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

by habibur 11mo ago

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

petcat 11mo ago
Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.
- teaearlgraycold 11mo ago
  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?
  - petcat 11mo ago
    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.
    - Jweb_Guru 11mo ago
      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).
  - Tuna-Fish 11mo ago
    > 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.
  - josephg 11mo ago
    > 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.
    - hyghjiyhu 11mo ago
      The obvious(?) question is why it sends gigabytes of stuff to llvm and if that can't be reduced somehow.
      - aw1621107 11mo ago
        > 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.
  - lmm 11mo ago
    > 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.
    - kccqzy 11mo ago
      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.
      - lmm 11mo ago
        > 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.
        kccqzy 11mo ago
        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.
  - deleted 11mo ago
    [deleted]
Cyph0n 11mo ago
Absolutely crazy.. I never expected that the difference would be so drastic.
belval 11mo ago
Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.
- darknavi 11mo ago
  It's not _that_ hard to believe if you start spraying smart pointers everywhere.
- vacuity 11mo ago
  Per million lines of code.
- oconnor663 11mo ago
  Take a look at the examples in this post: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language 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.
  - blub 11mo ago
    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.
pityJuke 11mo ago
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).
- ls-a 11mo ago
  [flagged]
  - pityJuke 11mo ago
    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.
    - ls-a 11mo ago
      [flagged]
- linkage 11mo ago
  > 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.
  - mcherm 11mo ago
    To me, those sound like meaningful pros and cons, not a reason to completely dismiss it.
  - spockz 11mo ago
whyever 11mo ago
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.
- vacuity 11mo ago
  Yes. I would make a guess of 10 or less memory-safety vulnerabilities per MLOC, which is still a hundredfold reduction.
  - Jweb_Guru 11mo ago
    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.
    - vacuity 11mo ago
      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.
samdoesnothing 11mo ago
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?
- nashashmi 11mo ago
  Even so, relatively speaking if C is not 50,000x worse, it must be at least 2000x worse.
- kibwen 11mo ago
  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.
  - samdoesnothing 11mo ago
    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.
    - shakow 11mo ago
      You're sure of a lot of things.
      - samdoesnothing 11mo ago
        Because I don't blindly accept bad science? It's more like others are sure that this data confirms their biases.
rtpg 11mo ago
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.
- pie_flavor 11mo ago
  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.
JackSlateur 11mo ago
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 :)
bgwalter 11mo ago
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++.
- blub 11mo ago
  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.
  - surajrmal 11mo ago
    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.
throwaway2037 11mo ago
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.
- aeve890 11mo ago
  > 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.
  - whytevuhuni 11mo ago
    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++.
  - baq 11mo ago
    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.
- norman784 11mo ago
  That's also a reason why Google is researching with Carbon, they have for sure a hunger to migrate away from C++.
raxxorraxor 11mo ago
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.

by habibur 11mo ago

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

petcat 11mo ago

Rust is truly a marvel of engineering. A breakthrough. Such a thing is so very rare in computer science.

teaearlgraycold 11mo ago
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?
- petcat 11mo ago
  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.
  - Jweb_Guru 11mo ago
    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).
- Tuna-Fish 11mo ago
  > 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.
- josephg 11mo ago
  > 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.
  - hyghjiyhu 11mo ago
    The obvious(?) question is why it sends gigabytes of stuff to llvm and if that can't be reduced somehow.
    - aw1621107 11mo ago
      > 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.
- lmm 11mo ago
  > 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.
  - kccqzy 11mo ago
    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.
    - lmm 11mo ago
      > 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.
      - kccqzy 11mo ago
        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.
- deleted 11mo ago
  [deleted]

Cyph0n 11mo ago

Absolutely crazy.. I never expected that the difference would be so drastic.

belval 11mo ago

Isn't that a lot though, that means 1 memory safety vulnerability per 1000 lines of code, that seems hard to believe.

darknavi 11mo ago
It's not _that_ hard to believe if you start spraying smart pointers everywhere.
vacuity 11mo ago
Per million lines of code.
oconnor663 11mo ago
Take a look at the examples in this post: https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language 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.
- blub 11mo ago
  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.

pityJuke 11mo ago

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

ls-a 11mo ago
[flagged]
- pityJuke 11mo ago
  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.
  - ls-a 11mo ago
    [flagged]
linkage 11mo ago
> 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.
- mcherm 11mo ago
  To me, those sound like meaningful pros and cons, not a reason to completely dismiss it.
- spockz 11mo ago

whyever 11mo ago

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.

vacuity 11mo ago
Yes. I would make a guess of 10 or less memory-safety vulnerabilities per MLOC, which is still a hundredfold reduction.
- Jweb_Guru 11mo ago
  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.
  - vacuity 11mo ago
    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.

samdoesnothing 11mo ago

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?

nashashmi 11mo ago
Even so, relatively speaking if C is not 50,000x worse, it must be at least 2000x worse.
kibwen 11mo ago
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.
- samdoesnothing 11mo ago
  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.
  - shakow 11mo ago
    You're sure of a lot of things.
    - samdoesnothing 11mo ago
      Because I don't blindly accept bad science? It's more like others are sure that this data confirms their biases.

rtpg 11mo ago

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.

pie_flavor 11mo ago
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.

JackSlateur 11mo ago

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

bgwalter 11mo ago

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

blub 11mo ago
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.
- surajrmal 11mo ago
  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.

throwaway2037 11mo ago

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.

aeve890 11mo ago
> 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.
- whytevuhuni 11mo ago
  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++.
- baq 11mo ago
  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.
norman784 11mo ago
That's also a reason why Google is researching with Carbon, they have for sure a hunger to migrate away from C++.

raxxorraxor 11mo ago

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.