The Rust Implementation Of GNU Coreutils Is Becoming Remarkably Robust

[patrick1946]

Rust is designed to make programmer easier for human and I'm not aware any widely used PL that designed for AI.

My impression was always that Rust tries to make it harder to write memory related bugs. That doesn't mean it makes programming generally easier.

Personally I think a successor to C++ should not only tackle that problem but also make it easier to avoid other bugs.

For example it would be very desirable to easier write testable code in C++. It is possible but not really easy. As I looked into Rust it is even sometimes harder. I would expect that tests would be part of the language design. That's I am quite sceptical about Rust. Maybe it is like Pascal, very successful but in the end something new comes around.

[RahulSundaram]

Shouldn't a tool X be the originator and authoritative source of Xcolors library? Not be a consumer of a 3rd party's interpretation of another projects behavior?

Not necessary. If there is a mature existing library that you can reuse easily there is no reason to reinvent the wheel there just to avoid a dependency. In the C world, pulling in dependencies is a hassle so projects avoid dependencies as much as possible but when the tooling support for handling dependencies is reasonable in a language, there is no need to repeat that pattern. You can always vendorize it if you need to.

[fitzie]

There's zero benefit to writing software from scratch. It's always going to be better to use standardized libraries that are specifically built for each purpose. Let's not encourage software to rewrite the same algorithms poorly, or copy and paste source code from another crate. No one's going to want to maintain that.

I'm happy that the essential user base is being written in a more secure and productive language, and I'm happy that the licensing and efficiency/performance make it more likely that embedded use cases and targets like android will make it more likely to converge on this project.

However, the simplicity of importing random crates in such a crucial piece of software, that is probably run as $UID == 0 more than $UID != 0, is that all of these crates are a vector for attacks. we see all the time that libraries in pypi node have caused attacks users of software that use those dependencies two, three levels deep. While this tradeoff might be worth it, it is still a tradeoff, and vastly widens the scope of code bases and techniques needed to analyze and understand the code that you are executing. I don't consider this a solved problem today, although i do think a lot of progress could be made in this area.

[trapexit]

It's much easier to port software written in Rust to another platform. It's trivial to submit a PR to a crate with annotations for conditional compilation for specific operating systems. And then everyone who utilizes that crate gets the opportunity to have the platform support for free. And at the end of the day, Rust has LLVM and GCC support so it can compile to the same wide range of exotic architectures.

There is nothing special about that. It's the same as every other langauge. If libraries support multiple platforms then great. That's not what we are talking about. We're talking about the language itself and C is still king there. And since these are *core* utilities and need to be somewhat platform focused having abstractions sometimes doesn't make sense. Someone has to support the platform. Someone needs to write the ioctl calls for cp to manage reflink cow. Putting that behavior into a library is fine and dandy but it's not a big deal.

There's zero benefit to writing software from scratch. It's always going to be better to use standardized libraries that are specifically built for each purpose. Let's not encourage software to rewrite the same algorithms poorly, or copy and paste source code from another crate. No one's going to want to maintain that.

Zero? How about security? Speed? Functionality? API issue? Conflict of vision? Acting as if abstractions are perfect and there won't be issues with abstracting low level software or interactions with other project is just not realistic. You want core utils to become standard libs? Great. I agree and said that in my comment. If you think creating *core* utils with code maintained by others and not treated as carefully as coreutils needs to be is a good idea... I disagree. Projects die, maintainers abandon projects, focus changes, conflicts arise. I don't want my core utils to be relying on some library that mimics the actual coreutils ls behavior. I want the coreutils folks to provide the functionality as a library. Don't put the horse in front of the cart.

Many of the Rust coreutils are faster than the GNU ones, and it's definitely much easier to be competitive. Part of the reason for that is precisely because it relies on crates instead of writing everything from scratch. You could use the aho-corasick crate and have a SIMD-optimized algorithm for quick string searches for grep. And I'd much rather they utilize standardized open source libraries, that every Rust project in the community is standardizing around, instead of duplicating the time and energy for something that's less maintained.

You're making it sound like shared libraries don't exist outside Rust. Lots of languages and platforms have centralized or semi-centralized library repos. And you get code reuse. Lots of it. That's not new. You also end up with industry wide pad left outages at some point. Acting like there are no tradeoffs to these things is just not reality. What happens if aho-corasick is abandoned? What if I need to support some esoteric platform. These are real issues that happen and should be part of the calculus when determining if a dependency is worth it.

Stating it is easier to get good perf in Rust is fine. Lots of languages are easier to use and offer easier initial optimization opportunities. Stating that for whatever reason some Rust devs have written libs that aren't as popular in other languages that make it easier to get some functionality is fine. But these things are in no way unique to Rust. It's happenstance.

[trapexit]

Not necessary. If there is a mature existing library that you can reuse easily there is no reason to reinvent the wheel there just to avoid a dependency. In the C world, pulling in dependencies is a hassle so projects avoid dependencies as much as possible but when the tooling support for handling dependencies is reasonable in a language, there is no need to repeat that pattern. You can always vendorize it if you need to.

"no reason"

Of course there are reasons. Just because you aren't familiar or unconcerned with them doesn't mean they don't exist. Security is a big reason to reinvent a wheel. And given coreutils run with elevated privs all the time it's pretty critical.

[RahulSundaram]

"no reason"

Of course there are reasons. Just because you aren't familiar or unconcerned with them doesn't mean they don't exist. Security is a big reason to reinvent a wheel. And given coreutils run with elevated privs all the time it's pretty critical.

Reinventing the wheel doesn't make things magically more secure than a library and often can make things worse. Security is a very poor reason to do this.

[trapexit]

Reinventing the wheel doesn't make things magically more secure than a library and often can make things worse. Security is a very poor reason to do this.

Increasing the surface area of attack and giving up control over the depth of that area of attack makes things... better? Maybe check the pypi and npm scenes.

[mdedetrich]

For the record, I'm not worried about losing my job to a new programming language, but I am worried about losing my job to AI. If you say that Rust makes it really easy to write an AI, then I definitely do not like Rust. 'Cause I like my job. But AI sure does seem inevitable. Unless it's all hype and no substance, which I hope.

If your worried about losing your job to AI you are not a good programmer.

[mdedetrich]

Reinventing the wheel doesn't make things magically more secure than a library and often can make things worse. Security is a very poor reason to do this.

Except that Rust proves that a significant subset of security bugs cannot occur (~70% of security are related to memory management bugs which Rust catches at compile time). Thats not magic, thats math and while your argument would normally make sense the fact that its being rewritten in Rust puts a massive a hole in it.

[RahulSundaram]

Increasing the surface area of attack and giving up control over the depth of that area of attack makes things... better? Maybe check the pypi and npm scenes.

Using a library doesn't automatically increase the surface area of attack. On the contrary, good code reuse reduces it significantly. Using a library doesn't include giving up control either. Cargo creates a lock file by default and you can readily use cargo-vendor to have a local copy of all the libraries you use in the same source. NPM and PyPI have a poor history of best practices but those experiences aren't the same here.