Hacker News new | past | comments | ask | show | jobs | submit login
Rewriting the GNU Coreutils in Rust (lwn.net)
29 points by signa11 39 days ago | hide | past | favorite | 18 comments



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.


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


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"


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_


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


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.


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.


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.


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.


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.


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


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.


The way I see it, rust's "safety" arguments provide endless fuel for justifying NIH efforts and enabling the always more appealing creating new problems vs. resolving existing ones (aka rewrites vs. inheriting+maintenance).

That's not to say it never makes sense to rewrite, but we need to at least be cognizant of these constant forces and normalize the justification on a case-by-case basis accordingly.

Although, at this point, it might just be a matter of getting these projects maintained by the new guard who seems to have little interest in writing C. By letting them rewrite the world in rust, they hopefully take ownership and become the old guard living with that syntax until the next generation shows up and wants to rewrite it all in some newfangled safe-C because rust is too hideous to read.

I digress...


Would these replace the standard C versions of the coreutils? Would development efforts cease, or reduce, on the C versions (factoring in the little active development they currently see).

I ask because there was a recent discussion [0] on Python's crypto library integrating Rust code, and the fact that this limits the platforms that can be supported. Poettering also rejected Rust code from the systemd utilities for the same reason [1]. One of the main reasons I love the GNU/Linux ecosystem is that I have been able to run it on a variety of old and esoteric hardware. I don't wish to see this arbitrarily taken away, in the future. C is a great language at least in the fact that every architecture I have ever heard of has a (mostly) standards-compliant C compiler. A little finagling may be needed to get code to compile, but it's rarely a project stopping issue.

[0] https://news.ycombinator.com/item?id=26097153

[1] https://github.com/systemd/systemd/issues/18767


> Poettering also rejected Rust code from the systemd utilities for the same reason

Maybe I'm misunderstanding something, but that doesn't seem to be the case, at least according to [0], which is more recent that the link you posted. They seem to be taking the same approach as the Linux kernel in terms of rust support.

[0] https://github.com/systemd/systemd/pull/19598


ouch, I hadn't seen the updates, or followed along, thanks for the heads up.

I fought many years by hopping distros to keep init.d as my initialization environment. Eventually I gave up and accepted systemd on Debian, my otherwise preferred distro. Maybe it's time I go back to some frankenstein'ed Gentoo build or some other obscure distro.

This isn't any sort of "threat", we're not "customers" leaving money on the table or anything. But the permeation of LLVM into being a hard dependency to have an up to date FOSS system feels against part of the spirit of the movement. At least if I become part of some botnet or scanner getting distro popularity metrics my vote will be counted the way I like. I say this as someone who likes what LLVM has done, and appreciate having more compiler options. It feels somewhat wrong that we're putting so much weight on it though, its off putting we're now leveraging these languages that have only a single implementation. It's hard to describe because it's not inherently against anything FOSS or POSIX philosophy, but whereas one could make a mediocre C compiler in ASM in a few weeks effort, I don't think I can do the same with Rust, Go, or any other modern full featured language. Perhaps it's just me becoming increasingly the curmudengous old man that fits the stereotypes.

I don't really mind Rust, or Go, but I don't really use them either. I learned on C++ but later found I really appreciated the simplicity of C. Maybe I'll just finally start putting in real effort to contribute in the areas I care about.


it would also make sense to build new command line tools to complement coreutils...


If the point of Rust is memory safety, perhaps the community should be focusing on safety critical code. I don't see a reason that Rust needs to be the EveryLanguage, much as I love it. It'd be nice to see a quintessential safety/security focused community form around Rust.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: