Hacker News Reader

Comment by sylvestre | Hacker News Reader

Significantly bigger than the C version.

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.

View on HN

You can use it as a single binary that's linked to the actual tool name, like busybox. That binary is just 9.6M (0.0.4 from their GitHub, Linux/amd64).

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.

First, symlinks are not really portable, for example they don't work on Windows, or in ancient UNIX systems.

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.

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

> For example for cp, most of the time is spending copying the files.

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/s

> For example, doing a parallel "df" isn't super interesting

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

> For example for cp, most of the time is spending copying the files.

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.

Reply on news.ycombinator.com