Rust-Based Coreutils 0.0.26 Increases Compatibility With GNU Coreutils

[phoronix]

Phoronix: Rust-Based Coreutils 0.0.26 Increases Compatibility With GNU Coreutils

The uutils' Rust-based Coreutils implementation is out with another update that further increases the drop-in replacement compatibility with GNU Coreutils...

https://www.phoronix.com/news/Coreutils-Uutils-0.0.26

[mirmirmir]

One day uutils will be compatible with gnu coreutils more than gnu coreutils itself.

[NotMine999]

One day uutils will be compatible with gnu coreutils more than gnu coreutils itself.

And by that time both will be obsolete and replaced with a systemd module

[Daktyl198]

And by that time both will be obsolete and replaced with a systemd module

That nobody really wants since it's not compatible with coreutils and works way differently with more complicated names and flags, but Gnome and other software will depend on it's functionality so distros will be forced to ship with it either way, and since the module will conflict with coreutils the distro will just drop coreutils from their releases. Can't wait to see that whole thing play out for the 20th time.

[Developer12]

Compatibility and memory safety are cool and all (and memory safety has become a hot topic with the related gnu libc project) but what I'd really like to start seeing is a measurement of whether the rust uutils are leveraging rust's easy multithreading for speeeeeeeeeeeeeeeeeeeeeeed.

[anarki2]

Compatibility and memory safety are cool and all (and memory safety has become a hot topic with the related gnu libc project) but what I'd really like to start seeing is a measurement of whether the rust uutils are leveraging rust's easy multithreading for speeeeeeeeeeeeeeeeeeeeeeed.

First you need functionality before you can start speeding up functionality.

[reba]

[QUOTE=Daktyl198;n1460330]

That nobody really wants since it's not compatible with coreutils and works way differently with more complicated names and flags, but Gnome and other software will depend on it's functionality so distros will be forced to ship with it either way ...[QUOTE]

Not necessarily, they could just choose not to package Gnone.
Are there already distros dropping Gnome?

[bug77]

Compatibility and memory safety are cool and all (and memory safety has become a hot topic with the related gnu libc project) but what I'd really like to start seeing is a measurement of whether the rust uutils are leveraging rust's easy multithreading for speeeeeeeeeeeeeeeeeeeeeeed.

I haven't tested uutils, but ripgrep is much faster than good old grep.
However, you're making it sound like multithreading wasn't possible before, while I'm sure current GNU utils multithread just fine. Thus, speed won't be the main thing to gain here.

[Developer12]

First you need functionality before you can start speeding up functionality.

They've got 66% of the test suite passing, and more than that is stubbed in. The project is well past the functionality everyone uses on an everyday basis. That's more than enough to start looking at optimizations.

[ahrs]

I haven't tested uutils, but ripgrep is much faster than good old grep.
However, you're making it sound like multithreading wasn't possible before, while I'm sure current GNU utils multithread just fine. Thus, speed won't be the main thing to gain here.

It's a shame its not compatible with grep. I sometimes find myself needing to look up the options for Ripgrep, for example

grep -o

is

rg --no-line-number --only-matching

or

rg -oN

which is not only longer to type out but I'm going to forget it sometimes.

There is value in tools like Uutils that try to maintain compatibility with their GNU counterparts. I would love to see a grep utility that utilises Ripgreps core while keeping the options the same as GNU's.