Earlier quoted context omitted.
[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]
Rust in Android: move fast and fix things
151–160 of 430 posts
Re: Rust in Android: move fast and fix things
#152Earlier quoted context omitted.
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).
> 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…
To me, those sound like meaningful pros and cons, not a reason to completely dismiss it.
Re: Rust in Android: move fast and fix things
#153Earlier quoted context omitted.
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).
> 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…
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 ?
Re: Rust in Android: move fast and fix things
#154This 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.
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.
Re: Rust in Android: move fast and fix things
#1555 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.
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?
Re: Rust in Android: move fast and fix things
#156Earlier quoted context omitted.
> 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…
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.
Re: Rust in Android: move fast and fix things
#157Earlier quoted context omitted.
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).
> 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…
> 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?*
Re: Rust in Android: move fast and fix things
#1585 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.
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.
Re: Rust in Android: move fast and fix things
#159Earlier quoted context omitted.
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).
> 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…
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.
Re: Rust in Android: move fast and fix things
#1605 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.
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?
Even so, relatively speaking if C is not 50,000x worse, it must be at least 2000x worse.