If you read my comment with a little care, you may realize that I said nothing about replacing the software, I only spoke about writing it. In my own Distro I wouldn't replace coreutils with a Rust rewrite either at this point.
On the borrow checker: It doesn't prevent logic errors as is commonly understood. These errors are what careful use of Rusts type system could potentially prevent in many cases, but you can write Rust without leveraging it successfully. The Rust compiler is an impressive problem-avoidance tool, but there are classes of problems even it can't prevent from happening.
BLet us not fall into the trap of thinking thst just because the Rust compiler fails to prevent all issues, we should therefore abandon it. We shouldn't forget our shared history of mistakes rustc would have prevented (excerpt):
- CVE-2025-5278, sort: heap buffer under-read in begfield(), Out-of-bounds heap read in traditional key syntax
- CVE-2024-0684, split: heap overflow in line_bytes_split(), Out-of-bounds heap write due to unchecked buffer handling
- CVE-2015-4042, sort: integer overflow in keycompare_mb(), Overflow leading to potential out-of-bounds and DoS
If we were civil engineers with multiple bridge collapses in our past and then, we finally had developed a tool that reliably prevents a certain especially dangerous and common type of bridge collapse, we would be in the wrong profession if we scoffed at the use of the tool. Whether it is Ruet or some C checker isn't really the point here. The point is building stable, secure and performant software others can rely on.
Any new method to achieve this more reliably has to be tested. Ideally in an environment where harm is low.
It is worth noting, that all three CVEs could be prevented by simple bounds checking at runtime. Preventing them does not require borrow checker or any other Rust fancy features.
It is also worth noting that theoreticals don't help such discussions either.
Yes, C programmers can do much more checks. The reality on the ground is -- they do not.
Forcing checks by the compiler seems to be the only historically proven method of making programmers pay more attention.
If you can go out there and make _all_ C code utilize best-in-class static checkers, by all means, go and do so. The world would be a much better place.
If your only criteria is "remove the buffer under- and over-flows", yes. IMO Rust helps with a few more things. Its strong static typing allows for certain gymnastics to make invalid states unrepresentable. Though in fairness, that is sometimes taken too far and makes the code hard to maintain.
On the borrow checker: It doesn't prevent logic errors as is commonly understood. These errors are what careful use of Rusts type system could potentially prevent in many cases, but you can write Rust without leveraging it successfully. The Rust compiler is an impressive problem-avoidance tool, but there are classes of problems even it can't prevent from happening.
BLet us not fall into the trap of thinking thst just because the Rust compiler fails to prevent all issues, we should therefore abandon it. We shouldn't forget our shared history of mistakes rustc would have prevented (excerpt):
- CVE-2025-5278, sort: heap buffer under-read in begfield(), Out-of-bounds heap read in traditional key syntax
- CVE-2024-0684, split: heap overflow in line_bytes_split(), Out-of-bounds heap write due to unchecked buffer handling
- CVE-2015-4042, sort: integer overflow in keycompare_mb(), Overflow leading to potential out-of-bounds and DoS
If we were civil engineers with multiple bridge collapses in our past and then, we finally had developed a tool that reliably prevents a certain especially dangerous and common type of bridge collapse, we would be in the wrong profession if we scoffed at the use of the tool. Whether it is Ruet or some C checker isn't really the point here. The point is building stable, secure and performant software others can rely on.
Any new method to achieve this more reliably has to be tested. Ideally in an environment where harm is low.