Most different implementations of the coreutils have different goals in mind. GNU's implementation, as is common of GNU is to treat memory for performance, and busybox's attempts to achieve the converse. — so what is the purpose of this one? simply being written in Rust?
How does it compare to the established ones?
Rust: 73M source: https://packages.debian.org/experimental/rust-coreutils
C: 17M https://packages.debian.org/unstable/coreutils
Note that no size optimization that been done and there is a lot ways to do it in Rust https://github.com/johnthagen/min-sized-rust
In term of performance, well, it depends on the binary. For example for cp, most of the time is spending copying the files. For the factor command, some work happened to make it faster https://github.com/uutils/coreutils/commits/master/src/uu/fa... (getting closer).
Using Rust also opens some great capabilities like parallelism. But this makes sense only for complex commands. For example, doing a parallel "df" isn't super interesting (I tried it was too expensive just to start threads to do it).
Anyway, performances should be a focus but only after correctness is implemented.
The Debian version ships with separate binaries though (109 of them), and is much larger. There is probably a lot of duplication as many tools use the same Rust libraries for flag parsing and whatnot which are compiled in the binaries. This is why those 73M compresses down to just 8M.
Also, that way every command executes with the same privileges because it's the same binary. And at least in Linux capabilities are bounded to a binary. So for utility that necessitate of special capabilities (e.g. ping, passwd, sudo, etc) this approach will not work.
Yes, it works on busybox since everything is owned by root on the typical system so nobody cares about privileges.
Finally, you need to load in memory every time you run a single binary all the thing needed by all the other binaries, even for the `true` binary. To me is stupid.
The solution exists, and exists since ever, and it's encapsulating common functionalities in shared libraries, and have very small binaries linked to only the libraries they use. Unfortunately Rust choose not to support them for stupid reasons like problems that were resolved decades ago.
Rust has a stable a.b.i., simply not it's own stable a.b.i. as distinct from C's.
`repr(C)` is what gives a stable a.b.i. in Rust.
As it turns out, cp can be made significantly faster by using (very) modern kernel APIs: https://wheybags.com/blog/wcp.html
20 512MiB files
wcp 3.97s, 2579.59 MiB/s
cp 8.44s, 1213.38 MiB/s
rsync 17.26s, 593.33 MiB/sActually I would enjoy that. Sometimes slow filesystems (e.g. stuck nfs) prevent the whole list from being displayed, or displayed only up to some point.
If ctrl-c let me break out the command yet list all the collected data (preserving non-parallel order), it would be nice at times.
Bonus: list skipped mountpoints to stderr..
There's a lot of ways to "copy a file" though. Finding the right buffer sizes, making concurrent read/write ops for different backend devices, and many other things can influence this. A good cp is not trivial.
> Why?
> Many GNU, Linux and other utilities are useful, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old and abandoned, are hosted on CVS (which makes it more difficult for new contributors to contribute to them), are written in platform-specific C, or suffer from other issues.
> Rust provides a good, platform-agnostic way of writing systems utilities that are easy to compile anywhere, and this is as good a way as any to try and learn it.
For some value of "anywhere".
It's pretty naive - a simple linewise read_until loop, a conditional to avoid word splitting and such if it's not needed, and for some reason it collects results into an array and prints when it's done rather than printing as it goes.
It doesn't support --files0-from like GNU wc, so isn't a drop-in replacement from that perspective. It also has the sadly common Rust trope of only supporting filenames that are valid UTF-8.
It doesn't seem overly slow considering its simplicity - usually trading blows with GNU and BSD wc. Perhaps the most glaring omission is the lack of a fast path for -c, which should reduce to a stat() call. Also unfortunate not to use the excellent bytecount crate to provide a very fast -l/m path.
The read_until loop also makes its memory use unpredictable compared with other wc's. If you run it on /dev/zero it will try to eat your computer.
$ wc -c /proc/self/cmdline
25 /proc/self/cmdline
$ stat -c '%s' /proc/self/cmdline
0FreeBSD just uses fstat: https://github.com/freebsd/freebsd-src/blob/e4b8deb222278b2a...
[0]: https://github.com/uutils/coreutils/blob/master/src/uu/yes/s...
[1]: https://github.com/coreutils/coreutils/blob/master/src/yes.c
[2]: http://github.com//coreutils/coreutils/commit/35217221c211f3...
[3]: https://github.com/coreutils/coreutils/blob/ccbd1d7dc5189f46...
[4]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug...
This is an interesting article that outlines why GNU grep outperforms almost any other grep quite significantly, at the cost of more memory.
Also, to be clear, in a strict apples to apples comparison, GNU grep and ripgrep will tend to have comparable performance. ripgrep does edge it out a bit in many cases, but it isn't always earth shattering. However, if you don't limit yourself to apples-to-apples comparisons and instead look at the user experience, then yes, ripgrep will likely be "a lot" faster. Primarily because of automatic parallelism and its "smart" filtering.
In your second link ripgrep is even marketed as having "the raw performance of GNU grep" (though it managed to exceed it).