> I can assure you that the core utils have all already went through static analysers doing more checks than the Rust compiler.
Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right.
It is true that the borrow checker doesn't prevent ALL bugs though.
Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.
Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class.
And even without annotations, you can prove safe a lot of constructs by being conservative in your analysis especially if there is no concurrency involved.
Note that I wasn't specifically commenting about this specific issue. It's more about my general fatigue regarding people implying that rewrite in Rust are always better or should be done. I like Rust but the trendiness surrounding it is annoying.
You can do a lot of things. Yes, there are formally verified programs and libraries written in C. But most C programs are not, including the GNU coreutils (although they are battle-tested). It's just the effort involved is higher and the learning curve for verifying C code correctly is staggering. Rust provides a pretty good degree of verification out-of-the-box for free.
Like any trendy language, you've got some people exaggerating the powers of the borrow checker, but I believe Rust did generally bring out a lot of good outcomes. If you're writing a new piece of systems software, Rust is pretty much a no-brainer. You could argue for a language like Zig (or Go where you're fine fine with a GC and a bit more boilerplate), but that puts even more spotlight on the fact that C is just not viable choice for most new programs anymore.
The Rewrites-in-Rust are more controversial and they are just as much as they are hyped here on HN, but I think many of them brought a lot of good to the table. It's not (just?) because the C versions were insecure, but mostly because a lot of these new Rust tools replaced C programs that had become quite stagnant. Think of ripgrep, exa/eza, sd, nushell, delta and difft, dua/dust, the various top clones. And these are just command line utilities. Rewriting something in Rust is not an inherently bad idea of what you are replacing clearly needs a modern makeover or the component is security critical and the code that you are replacing has a history of security issues.
I was always more skeptical about the coreutils rewrite project because the only practical advantage they can bring to the table is more theoretical safety. But I'm not convinced it's enough. The Rust versions are guaranteed to not have memory or concurrency related bugs (unless someone used unverified unsafe code or someone did something very silly like allocating a huge array and creating their own Von Neumann Architecture emulator just to prove you can write unsafe code in Rust). That's great, but they are also more likely to have compatibility bugs with the original tools. The value proposition here is quite mixed.
On the other hand, I think that if Ubuntu and other distros persist in trying to integrate these tools the long-term result will be good. We will get a more maintainable codebase for coreutils in the future.
> It is true that the borrow checker doesn't prevent ALL bugs though.
True, but "prevents all bugs" is that what the debate pretty much digests to in the "rust is better" debate. So you end up with rewrites of code which introduce errors any programmer in any language can make and since you do a full rewrite that WILL happen no matter what you do.
If that's acceptable fine, otherwise not. But you cannot hide from it.
~70% of bugs in NEW code, in companies, that have mottos like "move fast and break things". The same study, found that old C, C++ codebases tends to have these once in a blue moon and other bug classes are more prevalent.
Only if you don't use unsafe though. If you look at almost any real-world project written in Rust, you'll find tons and tons of `unsafe` in its dependency tree.
Congratulations to you on being the 10000th? person [0] to miss the point of unsafe/safe.
1. Unsafe doesn't mean the code is actually unsafe. It only tells you that the compiler itself cannot guarantee the correctness of it.
2. Unsafetiness tells the code reviewers to give a specific section of code more scrunity. Clippy also has an option that requires the programmer to put a comment to explain how the unsafe code is actually safe in the context.
3. And IF a bug does occur, it minimizes the amount of code you need to audit.
>You do coverage testing, which would have found the missing date -r path.
The original coreutils test suite didn't cover the -r path. The same bug would have not been statically discovered in most programming languages, except perhaps the highly functional ones like Haskell.
>You do proper code review, which would have found the missing date -r path.
And in an ideal world there would be no bugs at all. This is pointless -- we all know that we need to do a proper code review, but humans make errors.
Some checks are pretty much impossible to do statically for C programs because of the lack of object lifetime annotations, so no, this statement can't be right.
It is true that the borrow checker doesn't prevent ALL bugs though.
Furthermore, the "bug" in this case is due to an unimplemented feature causing a flag to be silently ignored... It's not exactly something that any static analyser (or runtime ones for that matter) can prevent, unless an explicit assert/todo is added to the codepath.