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

[phoronix]

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

Along with the broader industry trend of transitioning security-sensitive code to memory-safe languages like Rust, there has been an effort to write a Rust-based replacement to GNU Coreutils. For nearly a year that Rust Coreutils has been able to run a basic Debian system while more recently they have been increasing their level of GNU Coreutils compatibility and in some cases now even outperforming the upstream project...

https://www.phoronix.com/scan.php?page=news_item&px=Rust-Coreutils-Jan-2022

[skeevy420]

Even better is the licensing. MIT. That means that all sorts of operating systems can pick it up and fully integrate it into their stack without worrying about violating the GPL.

And possibility of everyone else picking it up is great news for crossplatform scripting. There's already a neat list of operating systems picking this up.

[Quackdoc]

A bit of a shame about the licensingm but for coreutils it's basic stuff anyways, but the preformance increase is always nice

[JellyBrain]

But doesn't the Coreutils inherntly need to use unsafe code in rust (because it's directly interacting with the operating system)?
It doesn't gain the advantage of rust's memory safety, right?
Or is it still reduces the amount of unsafe code they use, and they still gain it on all the other code?
I am really asking, I don't know if my assumption is correct.

[sdack]

Unless there is proof of GNU Coreutils actually being unsafe is the project a waste of time. It would be better to improve GNU Coreutils directly than to have yet another clone or fork of something with an unproven claim on it being supposedly safer without ever providing hard evidence.

[flower]

But doesn't the Coreutils inherntly need to use unsafe code in rust (because it's directly interacting with the operating system)?
It doesn't gain the advantage of rust's memory safety, right?
Or is it still reduces the amount of unsafe code they use, and they still gain it on all the other code?
I am really asking, I don't know if my assumption is correct.

why should cat, head (or the other examples in this article) need to interact with ram directly? that's basic fs stuff

[kylew77]

I will need to see benchmarks of any language being faster than C that is not named machine code or assembly. I find it VERY hard to believe that any Rust language program can beat a pure C language program. I have some friends that are die hard Rust fans and I don't see the point in learning it when I already know C and C++. Throw in a bit of shell scripting, Perl Scripting, and good old C and you can write an entire OS!

[mirmirmir]

it is sad that they don't use GPL. if this project somehow being picked up by many distro, we have less thing that's truly ours.

also, what the hell are these ads? it keeps pushing my comment text filed off screen as i type. i disabled my adblock on this site. how could you? Michael

[oleid]

I will need to see benchmarks of any language being faster than C that is not named machine code or assembly.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-clang.html

C and you can write an entire OS!

You can write an entire OS in Pascal as well. So what?

[Quackdoc]

Unless there is proof of GNU Coreutils actually being unsafe is the project a waste of time. It would be better to improve GNU Coreutils directly than to have yet another clone or fork of something with an unproven claim on it being supposedly safer without ever providing hard evidence.

actually it's the exact opposite. considering the more permissive licensing (I personally disagree with it, but there is absolutely benefit to this) and preformance gains, hardly a "waste of time" but if you read the article you would know that

...but for some binaries they are now seeing "significantly" better performance than out of the GNU package...

not to mention it's well established that rust is safer than C, with little performance overhead for optimized code in cases like these. so why bother risking it? if you already know you are going to get preformance increase by changing languages, and could very well close some unknown security vulns, it seems like a no-brainer to me...