Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

[rclark]

It is simply a matter of human nature. Right now Rust is the 'buzz' language. It is 'modern' because it is relatively 'new'. In 10-20 years the modern language will be something else and a rewrite will begin all over again because someone thinks it is a better mouse trap. As the wheel turns. Personally I think the current coreutils has been well validated over the years and is a solid 'set' core of functions. C isn't going anywhere. Be around forever. Why rewrite it? If something isn't broke, don't try to fix it. Resources could be better spent on 'adding' /enhancing the system and if you want to use Rust to do so, so be it... As long as it makes sense. I don't have a problem with that. An analogy could like the code that took the astronauts to the moon. Many many hours spent validating and testing that code and it worked. Then at the last minute deciding to rewrite it in Rust cause it is a 'modern' language..... That's kind of how I see Rust being 'pushed'. Not against Rust at all. I've worked with it a bit and can see it's strengths. But I don't plan to rewrite any of my C/Pascal/Python/etc. applications in it just because it is a a 'modern' language.

[furtadopires]

I’d just like to interject for a moment. What you’re referring to as Linux, is in fact, RUST/Linux, or as I’ve recently taken to calling it, RUST plus Linux.

I think it's nice to see more rust alternatives being developed for common used software, and I personally want to see some big AAA game using it to measure if all these race conditions protections can benefit performance too

[krzyzowiec]

So you imagine. It is however in itself is a piece of software and can have bugs despite all good intentions. My reference is specifically with GNU Coreutils. One can only claim software X to be safer than Y when it actually is. One can certainly use RUST to program nonsense, and one can use C to program safely. But to say GNU Coreutil was less safe requires proof. Just imagining it to be safer does not make it so.

The idea anything written in RUST would automatically be safer based on a language feature, all while the language itself is Turing-complete, is the typical high horse attitude that has been proven many times to lead to failure. It is not the protection from failure, but learning from failure that makes us better.

So I take it you don't remember GOTO? Or structured programming? Language features, in particular those features which restrict what you can do in programming, do lead to easier to reason about and safer code. This is not debatable. A construct like a loop is obviously safer than using jumps because there is less room for error. When Rust places similar restrictions on your ability to alias or write to variables at the same time (without marking the code as unsafe), that is defacto safer than C where you can do it anywhere. And that's just one safety feature advantage that Rust has over C. There are many more.

C is just a broken old language. Brilliant for its time, but we've learned a lot since then. Ignoring that and programming like we're still in the 1980s or 90s makes no sense to me.

[clavko]

Oh shush everyone, and let the people write in whatever they want. If you like it, use it, if not, move along. Don't request people that want to write stuff in Rust to maintain your C codebase instead - do it yourself, if that makes you happy. And if a guy wants to keep his C macros, let him be, there's worse things in life than a memory leak... Yeesh...

[MadCatX]

Are you going to provide proof or are you just sticking your head into the sand and keep imaging it all?

A proof of what exactly? That easily preventable, silly bugs that can lurk in the code for years may cause massive trouble? Take Heartbleed as a prime example.

No, I'm not going to go over the code of all 103 coreutils just to satisfy your ridiculous request. I'm gonna take the track record of programs written in C as a reference. Since C has the phrase "undefined behavior" written all over its specification, *proving* that a C program is really safe might be the difficult task, actually.

[Sethox]

Oh shush everyone, and let the people write in whatever they want. If you like it, use it, if not, move along. Don't request people that want to write stuff in Rust to maintain your C codebase instead - do it yourself, if that makes you happy. And if a guy wants to keep his C macros, let him be, there's worse things in life than a memory leak... Yeesh...

Nah, let people argue. Someone might open their mind and/or enjoy the entertainment of arguments that is a discussion (like a reader/observer).
In the end, it's not about the commentators that will do anything for a change (or no change). It's the developers. Rust in the Linux kernel was not exactly denied for example (sure took time for the code to be implemented). We can complain but as long as it's beneficial it will be replaced and/or used and the end user will only either feel like it's faster or not be aware of it at all.

In layman terms, if the developers of said project says "fine do it, but do it well or we will reject you" then it's okey until someone forks it and adds their own policies for the fork.

[gukin]

Something I love about the Linux culture is that there are frequently alternatives: clang and gcc, Xorg and Wayland etc. Unfortunately the devil is in the details, rewriting the 'yes' command and assuming the rest will be as easy can be misleading. If rust is the future, the way that Vulkan appears to be the future of 3D graphics API, I, for one, welcome our rust-speaking overlords.

[Luke_Wolf]

But it is. It is a waste of time when they could have spent their time on fixing GNU Coreutils. Instead, have they created yet another clone, made another claim of RUST being safer, and without providing actual evidence.

One could have spent the time to improve GNU Coreutils performance if there is an opportunity to do so. So instead of giving back to the GNU Coreutils, which people have been using for decades, are the GNU Coreutils instead used to make a show.

Frankly, not giving back, but instead making it into some sort of cancel culture is pathetic.

https://ftp.gnu.org/old-gnu/Manuals/...utils_149.html Read the bottom section, does this sound like a man and organization that care about security? I would trust software written by someone coming in fresh over someone asserting this kind of control over their software every day of the week.

[ZuseZ4]

I feel like at least one person here is just trolling, so I'm not sure whether it's worth writing this or not, but maybe it does help someone more open-minded.

I didn't invest the time to rewrite those old tools in Rust, but I'm surely not sad about that effort (or any OS moving towards it).
For Rust we do have Daniel Jung's PhD work here: https://saarland-informatics-campus....s/rust-safety/
tl;dr, having unsafe encapsulated in safe Rust doesn't make the outer code unsafe, if the encapsulation is correct.
Given that we have way below 10% (might even below 1%?) of Rust code being marked as unsafe, that's a pretty big win.
People in the Rust community are well aware of those unsafe sections and usually authors and reviewers will spend a large fraction of their time on exactly those sections. Also, given that we have such a low amount of code to check for these errors, we can tune our verification tools like Miri and Rudra to allow a much larger amount of false-positive, since they just have to check such small sections.

And finally, wrt. the performance. Rust supports inline-asm, so if you hardcore you can write your asm directly, inside of c, or inside of Rust. Have fun.
Everyone else has a limited time budget for a task. Writing asm is incredibly slow. Writing c code and verifying that it's safe is slow and then you still have to hand-roll your datastructures and algorithms, or spend time on dependency handling. Rust gives you extra time by handling most verification checks. It also gives you performance, since you can just use some of the optimized std-lib algorithms and datastructures, or use cargo to easily integrate highly optimized code from someone else.
Finally, a stricter type system often helps with performance rather than crippling it, for example we get __restrict / noalias for free by the compiler where applicable (similar to Fortran), where people on the C/C++ side have to check if they alias manually (and possibly have UB if they decide wrong). So I do think that in the same time budget, you can write faster Rust than C code.

Obviously , Rust is no magic bullet. It's under development, so people made wrong decisions and will make wrong decisions in the future, while designing it. However, those mistakes are so far out that people on the c side might not even notice them, see the latest TOCTOU issue, which isn't even considered a safety issue in C++ (https://www.reddit.com/r/cpp/comment...eb2x&context=3), while given a CVE on the Rust side: https://www.cve.org/CVERecord?id=CVE-2022-21658.
In 20,30 years Rust will probably have accumulated so much wrong decisions that it's time to design a simpler/safer/faster language which learned from that mistakes and then I will move on. But we don't have that yet, so I moved from C++ to Rust for the meantime.

[sdack]

C is just a broken old language. Brilliant for its time ...

This just shows that you do not know why C is successful. C is successful because most people are not afraid of making mistakes with it. They are not as afraid as you are, but they are keen and happy to make mistakes because they want to learn. This is why C is still going strong. Rust is merely overbearing, creates a fear of mistakes, and makes for a terrible motivator. All while one can still make many mistakes with Rust from which it provides no protection, and while it has many C libraries to help people out who do want to avoid repeating old mistakes and to build their code on. Rust's safety feature is about as significant as a feature as the commenting style of any language is.