Rewriting the GNU Coreutils in Rust
lwn.net
lwn.net
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.
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
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_
Right now Rust toolchain is not stable enough for something we will use the next 30 years.
> 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.
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...
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.
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.
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.