5 ms·

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

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.

ratorx 5y ago
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 https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
- jbirer 5y ago
  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.
- lionkor 5y ago
  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.
pornel 5y ago
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.
dt12345 5y ago
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
bravetraveler 5y ago
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 https://www.pixelbeat.org/docs/coreutils-gotchas.html
- eric__cartman 5y ago
  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"
  - bravetraveler 5y ago
    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_
IshKebab 5y ago
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.
zibzab 5y ago
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.
jart 5y ago
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.

ratorx 5y ago

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 https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

jbirer 5y ago
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.
lionkor 5y ago
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.

pornel 5y ago

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.

dt12345 5y ago

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

bravetraveler 5y ago

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 https://www.pixelbeat.org/docs/coreutils-gotchas.html

eric__cartman 5y ago
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"
- bravetraveler 5y ago
  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_

IshKebab 5y ago

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.

zibzab 5y ago

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.

jart 5y ago

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.