Rewriting the GNU Coreutils in Rust

Re:Rewriting the GNU Coreutils in Rust by lionkor on Friday June 18, 2021 @04:15AM (#27548404)

I will take the risk of being told off and explain why I don't see the point, or maybe don't want to see the point.

I heavily disagree that "what isn't broken shouldn't be touched", BUT: I feel like, if we're going to rewrite something in Rust, why not take something that has serious issues? Now, I get the cross-platform part, windows users want to use unix-y tools without using a unix, that's fair and good.

But beyond that, the fourth sentence in the readme,

> platform-specific C, a language considered unsafe compared to Rust

which I generally agree with, makes me suspicious; I see an issue with this, because of all possible C programs, I believe the GNU Coreutils are written in pretty good style and, due to a lot of them being super simple, have very little room for the common "C bad, Rust good" kind of issues.

The GNU Coreutils are heavily tested, and have proven themselves to be quite a solid codebase, so I don't see why rewriting it is necessary. Especially when it turns out that they are not close to done after even 8 years and seem very complicated compared to the C equivalents.

All this is not even mentioning the countless "crash when doing X" issues on the uutils github.

I'm probably just a grumpy C/C++ programmer, and I think I'm missing the big "this needs to happen" argument here, so take this with a grain of salt.

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by bravetraveler on Friday June 18, 2021 @09:27AM (#27550038)

I'll start by saying... I'm not a developer by any serious sense anymore. I did C over a decade ago and realized it was just not for me

With that out it the way... This rust infatuation seems like those people using one click tools to interpolate videos with "AI"

The end result is objectively worse and it's done because of subjective opinion: (gleefully) these artifacts are so SMOOTH!

Moving coreutils to rust is similar. The unit test coverage is low, and the problems they're seeing don't inspire confidence

Predictability in the tools is being traded for memory safety. I'd worry about using these behind any scripts, an extra \n from an obscure pipe driven bug could mean portability disaster

Edit: For example, these quirks https://www.pixelbeat.org/docs/coreutils-gotchas.html

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by eric__cartman on Friday June 18, 2021 @10:18AM (#27550570)

I agree. When talking about tools that millions have been using and depending on for decades, "If it ain't broke don't fix it"

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by bravetraveler on Friday June 18, 2021 @03:48PM (#27554185)

Precisely

Even with all of the talent in the world and infinite time to plan, I still feel confident saying that perfect compatibility wouldn't exist

There's simply so much scope, and different edge cases that may be depended on... somewhere

Cost/benefit doesn't make sense

Edit: Write new tools in whatever language, but coreutils is like the _cornerstone_

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by ratorx on Friday June 18, 2021 @06:34AM (#27549054)

There’s a semi-famous comment by the leader of OpenBSD where one of the reasons for dismissing Rust was the lack of ‘proper’ Unix utilities written in Rust (as well as a claim that no one would bother): https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by jbirer on Friday June 18, 2021 @06:40AM (#27549069)

It's not just that. He also mentions that Rust can't compile itself on i386 because it exhausts address space. It's just too bloated.

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by lionkor on Friday June 18, 2021 @06:49AM (#27549122)

That makes sense, but I doubt the Rust coreutils would make it into that source tree anytime soon, especially since it only satisfies around 120 out of 600+ unit tests and has been in development for 8 years.

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by zibzab on Friday June 18, 2021 @05:47PM (#27555361)

Here is another reason why this is a bad idea:

Right now Rust toolchain is not stable enough for something we will use the next 30 years.

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by IshKebab on Friday June 18, 2021 @01:55PM (#27552989)

Of course it's not necessary. That doesn't mean it isn't worthwhile.

> I'm probably just a grumpy C/C++ programmer

Yes! I always find it weird that technologists can be some of the most conservative luddites there are. I guess it is just human nature.

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by jart on Friday June 18, 2021 @06:59PM (#27555934)

The point is that software labor is infinitely replicable and the economy assumes labor is a continual process which can be taxed. If there's no labor to do then I'd imagine the people who plan the economy would want to invent some. Fact is that technologies like the Java crusade of the 90's or the Rust crusade we're seeing today create jobs. If it weren't for them we'd all be dusting off FORTRAN programs from the 1960's which got the job done.

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by dt12345 on Friday June 18, 2021 @08:37AM (#27549666)

another benefit I guess is the fact that this project uses the MIT licence, which would allow this to be used on Mac OS (currently they use an old version of GNU coreutils due to being (very reasonably imho) against including any software under the GPLv3). Obviously this is unrelated to Rust, but it's one benefit of the rewrite and I guess if you're going to rewrite, might as well do it in Rust

[ Parent | on HN ]

Re:Rewriting the GNU Coreutils in Rust by pornel on Friday June 18, 2021 @06:38AM (#27549064)

I don't think it needs to happen. But if it succeeds and matures, it will be nice to have modernized tools, possibly with improved multi-threading and other niceties of the Rust ecosystem.

[ Parent | on HN ]