[orangeboats]

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

[StopDisinfo910]

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.

[unscaled]

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.

[Avamander]

> Well, you can annotate C code to do a lot more than lifetime annotations today. The tooling for C analysis is best in class.

Where can I see these annotations for coreutils?

[consp]

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

[pepoluan]

The "rust is better" point is always "prevent memory-related bugs from happening".

Memory-related bugs is, like, 70% of bugs found in programs written in C and C++.

So, by rewriting in Rust, you prevent 70% of new bugs from happening, because a whole class of bugs just cease to exist.

[xorcist]

But that's hardly relevant to coreutils, is it? Do these utilities even manage memory?

These are command line utilities meant to be a human porcelain for libc. And last I checked, libc was C.

Ideally these should be developed in tandem, and so should the kernel. This is not the case in Linux for historical reasons, but some of the other utilities such as iputils and netfilter are. The kernel should be Rust long before these porcelain parts are.

[1718627440]

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

[gkbrk]

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.

[rurban]

In safe rust, yes. But in unsafe rust, no guarantees. And as long as rust itself is unsafe, you cannot call it safe.

[orangeboats]

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.

[0]: https://xkcd.com/1053/

[rurban]

You don't silently allow unhandled args.

You do coverage testing, which would have found the missing date -r path.

You do proper code review, which would have found the missing date -r path.

And many coreutils options will not be implemented at all. ENOFIX

[orangeboats]

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

[xorcist]

Then any replacement project should start with implementing a better test suite in order to know what you're doing. That has been the case with many other utilities such as ntp.

And it should most certainly not be possible to declare options and leave them as empty placeholders. That should be flagged just like an unused variable is flagged. That is a problem with whatever option library they chose to use.

That alone should disqualify it from being a replacement yet. We're talking about a stable operating system used in production here. This is simply wrong on so many levels.

[orangeboats]

>Then any replacement project should start with implementing a better test suite in order to know what you're doing

"Then any replacement project should not include bugs in their code."

Like I said before, broad statements like these are borderline pointless.

Of course we all know the should, the real problem is how -- how can you realistically make a "better test suite" when your goal is to create a bug-for-bug compatible replacement project?

And given the size of the original project, how should a better test suite be created?

>That is a problem with whatever option library they chose to use.

Instead of being vague, why not show a precise example of what you are talking about?