Experimental Rust-Based Coreutils Working Well Enough To Run Debian Basics

[phoronix]

Phoronix: Experimental Rust-Based Coreutils Working Well Enough To Run Debian Basics

Sylvestre Ledru who is a director at Mozilla by day while also being prolific to Debian/Ubuntu and LLVM/Clang development has managed to get a Rust version of Coreutils packaged and running well enough on Debian...

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

[uid313]

I don't see much advantages of porting small utilities like coreutils to Rust because these utilities are many small files and with Rust the file size will grow.
Also these utilities probably are not security sensitive.

I would rather see Rust be used for things such as decoders, parsers, interpreters. Software that deal with reading that data from untrusted sources.
I would like to see Rust in projects like FFmpeg, GStreamer, Poppler, VLC, OpenSSH, OpenSSL, etc.

[kpedersen]

A cool project. Also about time we see the Rust community achieve this. Possibly a good first step into reducing dependency on C.

However: https://github.com/uutils/coreutils/...ter/Cargo.lock

Christ! This drags in a lot of dependencies!

Including (ironically) the original coreutils. Though I am sure this can be bootstrapped one day.
Some of these dependencies really do seem excessive though. I don't like this approach to development at all. It racks up some major technical debt.

That said, one way of reducing dependencies is by eliminating the need for hundreds of bindings on C libraries (and programs) so this is a good direction.

[skeevy420]

A cool project. Also about time we see the Rust community achieve this. Possibly a good first step into reducing dependency on C.

However: https://github.com/uutils/coreutils/...ter/Cargo.lock

Christ! This drags in a lot of dependencies!

Including (ironically) the original coreutils. Though I am sure this can be bootstrapped one day.
Some of these dependencies really do seem excessive though. I don't like this approach to development at all. It racks up some major technical debt.

That said, one way of reducing dependencies is by eliminating the need for hundreds of bindings on C libraries (and programs) so this is a good direction.

Yeah, being able to go full Python with other peoples' code is one of the best and worst parts of Rust. It's great because it allows one to expand from what the community has done. It's bad because Christ! That does drag in a lot of dependencies!

[Maxim Levitsky]

Yeah, being able to go full Python with other peoples' code is one of the best and worst parts of Rust. It's great because it allows one to expand from what the community has done. It's bad because Christ! That does drag in a lot of dependencies!

Its Cargo after all

[kpedersen]

go full Python with other peoples' code

Heh nice phrase. I might borrow that.

Going "full python" is generally the developers mistake rather than the language or build system but yes, I do agree that Cargo makes it too easy to do this and almost encourages it. My main issue with Rust and why I have so far dismissed it for a number of projects is in-fact Cargo's dependency on Crates.io.

I am interested to see if Microsoft's added interest in Rust or Rust becoming involved in the Linux kernel might end up demonstrating some slightly more sustainable and maintainable approaches to dependencies in Rust rather than the classic PIP/CPAN/NPM approaches of "drag in all the shite and rewrite the software every 5 years".

[ivan.cwb]

I don't see much advantages of porting small utilities like coreutils to Rust because these utilities are many small files and with Rust the file size will grow.
Also these utilities probably are not security sensitive.

I would rather see Rust be used for things such as decoders, parsers, interpreters. Software that deal with reading that data from untrusted sources.
I would like to see Rust in projects like FFmpeg, GStreamer, Poppler, VLC, OpenSSH, OpenSSL, etc.

I agree with your whole comment.

However, there is this project to run scripts in rust, in an interpreted way:

https://github.com/DanielKeep/cargo-script

If thoses scripts could seize some components/parsers/whatever from some existent rust code, it could make it worth it...

[Luke_Wolf]

A cool project. Also about time we see the Rust community achieve this. Possibly a good first step into reducing dependency on C.

However: https://github.com/uutils/coreutils/...ter/Cargo.lock

Christ! This drags in a lot of dependencies!

Including (ironically) the original coreutils. Though I am sure this can be bootstrapped one day.
Some of these dependencies really do seem excessive though. I don't like this approach to development at all. It racks up some major technical debt.

That said, one way of reducing dependencies is by eliminating the need for hundreds of bindings on C libraries (and programs) so this is a good direction.

And having a lot of dependencies is a problem because?

Storage space isn't exactly at a premium anymore and since Rust binaries are statically linked by default it doesn't exactly increase the complexity of the overall distribution. Sure it increases compile times but Rust isn't exactly slow at doing that when you're comparing it to other compiled languages

Going "full python" is generally the developers mistake rather than the language or build system but yes, I do agree that Cargo makes it too easy to do this and almost encourages it. My main issue with Rust and why I have so far dismissed it for a number of projects is in-fact Cargo's dependency on Crates.io.

Cargo isn't really dependent on crates.io it's just the easiest way to use it, you can pass in a source argument to any dependency you want to look at either the local filesystem or anywhere on the web for a git repo to pull from. You just don't get automatic resolution.

[ElectricCogs]

This is a really cool way of setting up a new coreutils. The build approach means this is largely platform-agnostic, so there's no need to rewrite these for separate OSes. Windows, Linux, OpenBSD, Redox, etc. can all be built for out of the same tree.

The way the binaries are set up, it looks like the whole of coreutils can be compiled down into a single BusyBox-like binary, or they can be compiled individually. So the advantages of Busybox's approach are available, but aren't required. Certainly worth noting for anyone who's going to complain about each Rust binary being larger - a single binary is going to be competitively small, and possibly smaller than the sum of the existing coreutils binaries.

Finally, I think the number of dependencies is smaller than you might think. Keep in mind that Cargo.lock shows development dependencies, and some of those pull in a lot of extra crates. The lockfile also shows all the individual coreutils as sub-libraries too, which balloons it out further. That said, it's still a total of 45 dependencies. To me, that seems reasonable; I'd rather have them pull in a dependency instead of rolling their own cryptographic hash implementations. But I know there's controversy around "how many dependencies is reasonable", especially for anyone who's been using NPM (too many dependencies) or C (each new dependency is a new source of pain).

[kpedersen]

And having a lot of dependencies is a problem because?

Maintenance mainly. More chance of regression and breakage. More dependencies also reduces portability to new platforms because you have to wait for them to catch up.

If one dependency drops i.e 32-bit or ARM, then you in turn can no longer support those platforms. Possibly angry clients.

Cargo isn't really dependent on crates.io it's just the easiest way to use it, you can pass in a source argument to any dependency you want to look at either the local filesystem or anywhere on the web for a git repo to pull from. You just don't get automatic resolution.

If I used Rust, you can be certain I will not be depending on crates.io. Unfortunately like you said, it is "easy" and non-standard so I would generally be fighting against the tool at almost every turn.