Yes, but this is a core part of the economy. As soon as we "solve" something, it becomes commodity in a matter of years and the bottom falls out of our current employment/revenue models.
Improving legacy software is boring; consequently, less people are willing to do it, and those people tend to work slower. Rewriting a legacy program in a new language may take more work, but because it's more interesting, more people who work faster will do it, such that it takes less time overall.
Yes! Why is every company hiring for LLM talent? Companies that have no business doing so. They probably don't even know that supervised machine learning exists.
No mention of the relicensing going on. All the GNU utilities are GPL licensed.
At a time when relicensing and other rug pulls are making headlines I find it disturbing that so many developers are going with "permissive" licenses for their recreation of things in Rust.
Edit: not technically relicensing, which would not be legal. They are writing functional clones from scratch under a new license.
Because it's a step towards larger Rust adoption in Linux, simple.
It's a way to get good parts of the community wet and accustomed to the Rust tool chain and form plenty of developers in writing Linux software at scale.
Not really the world's biggest Rust fan, for multiple reasons. However, I find the arguments in this particular article to not be very compelling. The only concrete argument that is actually worth addressing is this one, and it's predicated on a false premise:
> I’ve also briefly touched upon that at best in the absolute best case scenario a rewritten version of GNU Core Utils in Rust would be able to match the performance of the original implementation. As we know GNU Core Utils are mostly written in C and some C++ mixed in sparingly. So far benchmarks have shown time and time again that at best with a lot of optimizations and tweaks Rust can only ever match the performance of C and in most cases it is actually slower. So the best case outcome of this rewrite is that we get a tool that does the same thing as the original and at best offers the same performance. So what is the actual benefit of this rewrite?
This assumes that the C code is already fully optimal, but it very obviously is not.
Of course, I call bullshit anyways. Most Rust vs C comparisons are going to compare similar idiomatic code in both languages, which gives you a nice baseline to compare against. That's useful for determining the baseline performance, which is indeed, "C but a tiny bit slower in some cases", which is due to things like additional checks that can't be elided at compile time (bounds checks, overflow checks.)
However, in practice, Rust provides better abstraction tools than C, which makes more complex optimizations a lot more practical. A good example would be SIMD optimizations. And Rust does this while giving better tools to ensure correctness, sometimes allowing optimal code to be surprisingly high-level (i.e. iterator usage compiling down to surprisingly straight-forward assembly.) (And to be clear, Rust is not the only language that offers better abstraction tools than C, but I do think it is one of the most promising options available. C++ is a mess, but it does work. New options like Zig are interesting but still need more time to mature.)
Ultimately, I do personally think that Rust coreutils is not very important in terms of safety. GNU coreutils does not really suffer from any particular problems that uutils solves. But still, it's a really good test case for Rust, and it does definitely open up some opportunities for better performance and correctness. Plus, I'm sure uutils will find itself in many places, such as places where GPL-licensed software can't really go (which may very well be a net negative, but I'm stating the fact here) or new operating systems that are based on Rust and want to keep as much stuff as possible free of requiring a C toolchain.
GNU core utils are single-threaded. Rust allows safely to use several threads without much efforts. That alone will speed up utilities even if they are IO-bounded. Finally one could stop running double tar instead of cp -a on a huge tree to speed up things when coping big trees.
This is all about destroying free software and allowing "open source" to take over, nothing with memory safety whatsoever. This can sound conspiracy but the main idea is to push permissive licenses, so companies can exploit your work without even mentioning your name. I believe the goal of Canonical and similar companies is to create a fully alternative Linux+GNU environment without GPL/AGPL, push it with embrace, extend, extinguish tactics and eventually create a developer culture that contributing to permissive license parallel project is a better alternative than original copyleft one.
The problem is that coreutils isn't done. It is still getting new features - it even had a release today [0]! And if new features are being added, then we're getting new bugs as well. Using Rust eliminates an entire class of rather serious bugs, so in a greenfield environment it would almost certainly be a better choice for a critical project like coreutils.
In practice it's of course more complicated. Any rewrite will also introduce a lot of bugs, so short-term the rewrite will probably have a negative result. I think it's a weird decision for Ubuntu to switch to uutils when it is still incomplete and probably buggier than the GNU version, but perhaps in the long run (5+ / 10+ years?) it might turn out to be the better option.
It's also important to keep the wider ecosystem in mind. Even if C and Rust were functionally identical, a rewrite could still make sense. Imagine if coreutils was written in a language like COBOL: the language choice would severely restrict the number of potential contributors. Who's going to learn it solely for the thankless job of maintaining boring tooling like coreutils? With the current generation of OSS maintainers slowly dying off, you need to recruit new (younger) developers to take over. If all the kids love Rust and hate C, then perhaps a switch to Rust might be a necessary evil to ensure we'll have well-maintained coreutils for another generation. You still need to be careful to avoid the fad of the day, but I think it's pretty clear by now that Rust is here to stay.
As an aside, as [1] shows, the "it'll at best be equal" argument is factually incorrect. There is no good reason to believe that GNU coreutils could not possibly be improved upon.
I don’t get why people are so militantly opposed. I get not wanting to contribute to something you don’t believe in but if it’s a good faith effort by others doing the work - let them
On one hand, I think it's hype and a waste of time, but on the other, I fully support people doing what they want. On the plus side, it IS a lot easier rewriting things that exist than solving novel problems.
> as it had basically never had any major security vulnerabilities in its entire existence.
This link[0] shows a CVE with CVSS of 9.8 in 2015 (and a handful of smaller ones). From this other page on the same site[1], it claims that all of all 5 of the CVE's are caused by overflow or memory corruption.
Language hype always justifies itself through intellectualizing its own desire.
In this incarnation we don't always hear, "Rust is the future."[1] We hear:
* "improving security, ensuring long-term maintainability, and optimizing performance" "memory safety, concurrency, and performance" [2]
* "its ability to prevent common programming errors such as null pointer dereferences and buffer overflows" [3]
* "is that it's very portable." [4]
* "I believe that we should shift the focus away from memory safety (which many other languages also offer) and instead focus on the explicitness, expressiveness, and ecosystem of Rust that is highly competitive" [5]
All of these things are operational and thus quantifiable, and some (perhaps even most), are probably true. But none of them engage with evidence-based decision making. Therefore it's not really about any of these, but that's what we've been doing since the beginning of time.
I understand there are wider issues here but the reason I personally use the new hotness rewrites like fd or rg or zellij is because they are just straight up better. Better interface, prettier presentation. They have the benefit of hindsight behind them which allows them to really solve a lot of problems with the originals that need to maintain backward compatibility. My only complaint is they are not gpl.
from the title I thought I was going to find someone agreeing with me that the current LLM craze is chasing natural language processing at the cost of other AI research. ironically I'm a fan of the coreutils rewrite, and the general trend of rewriting projects in more capable languages, I see it as paying future maintenance costs up front.
Since the article emphasizes performance so much, I’d have liked to see some benchmarking of the new core utils against the old, instead of the questionable and unsourced claim that “So far benchmarks have shown time and time again that at best with a lot of optimizations and tweaks Rust can only ever match the performance of C and in most cases it is actually slower.”
First, programming language fads have been a thing since about 10 minutes after the immortal Adm. Grace Hopper came up with COBOL.
Thompson and Ritchie could have used ALGOL, Lisp, FORTRAN, BCPL or PL/I to write Unix, but instead they created C and used that. I guarantee at the time there was someone at Bell Labs bitching about how they should be solving "real problems" instead of messing around with a new programming language.
But more practically, developers write code because they're paid to, or to scratch an itch. If a real problem doesn't substantially bother anyone enough to get solved by a developer, then it's not really a problem.
In general, code maintenance and optimization is always Somebody Else's Problem™. Instead of writing this blog post, the author could have spent that time optimizing some open source code, right?
At the same time, every generation of programmers will come in and will want to make a dent in the space time.
Why would a new developer want to use the stuff grand pa wrote ad nauseam? They want to take charge of their own adventure. Not everyone was born when things were exciting and we didn't know where we were going.
New tools likely wouldn't carry cruft that accumulated through time, as the tools understood their own essence, as they changed and morphed over time.
There is a Not_invented_here syndrome at play, with a New_shiny factor and potentially the benefits of cutting down a tool to the essential.
If anything, it's a good learning practice to rewrite existing tool, your way.
Rust does bring advantages, but if they don't learn the past, they're bound to repeat the mistakes made; memory safety only being a small part of the problem, over time (most of these old C tools now have been vetted many times over and are now pretty 'safe').
I think the other side of this is the fetishization of "if it isn't broken don't fix it" and computing conservatism a la the famous Dropbox/rsync comment. An equally valid inquiry is to ask "why should we not replace it", which can lead to some valid and correct thoughts.
At the end of the day, greybeards are going to retire and new generations are not going to want to deal with code bases built around technology and decisions that were made in the 1990s.
27 comments
[ 8.1 ms ] story [ 133 ms ] threadAt a time when relicensing and other rug pulls are making headlines I find it disturbing that so many developers are going with "permissive" licenses for their recreation of things in Rust.
Edit: not technically relicensing, which would not be legal. They are writing functional clones from scratch under a new license.
It's a way to get good parts of the community wet and accustomed to the Rust tool chain and form plenty of developers in writing Linux software at scale.
Otherwise, of course, it makes no sense.
> I’ve also briefly touched upon that at best in the absolute best case scenario a rewritten version of GNU Core Utils in Rust would be able to match the performance of the original implementation. As we know GNU Core Utils are mostly written in C and some C++ mixed in sparingly. So far benchmarks have shown time and time again that at best with a lot of optimizations and tweaks Rust can only ever match the performance of C and in most cases it is actually slower. So the best case outcome of this rewrite is that we get a tool that does the same thing as the original and at best offers the same performance. So what is the actual benefit of this rewrite?
This assumes that the C code is already fully optimal, but it very obviously is not.
https://www.phoronix.com/news/Rust-Coreutils-0.2.2
Of course, I call bullshit anyways. Most Rust vs C comparisons are going to compare similar idiomatic code in both languages, which gives you a nice baseline to compare against. That's useful for determining the baseline performance, which is indeed, "C but a tiny bit slower in some cases", which is due to things like additional checks that can't be elided at compile time (bounds checks, overflow checks.)
However, in practice, Rust provides better abstraction tools than C, which makes more complex optimizations a lot more practical. A good example would be SIMD optimizations. And Rust does this while giving better tools to ensure correctness, sometimes allowing optimal code to be surprisingly high-level (i.e. iterator usage compiling down to surprisingly straight-forward assembly.) (And to be clear, Rust is not the only language that offers better abstraction tools than C, but I do think it is one of the most promising options available. C++ is a mess, but it does work. New options like Zig are interesting but still need more time to mature.)
Ultimately, I do personally think that Rust coreutils is not very important in terms of safety. GNU coreutils does not really suffer from any particular problems that uutils solves. But still, it's a really good test case for Rust, and it does definitely open up some opportunities for better performance and correctness. Plus, I'm sure uutils will find itself in many places, such as places where GPL-licensed software can't really go (which may very well be a net negative, but I'm stating the fact here) or new operating systems that are based on Rust and want to keep as much stuff as possible free of requiring a C toolchain.
In practice it's of course more complicated. Any rewrite will also introduce a lot of bugs, so short-term the rewrite will probably have a negative result. I think it's a weird decision for Ubuntu to switch to uutils when it is still incomplete and probably buggier than the GNU version, but perhaps in the long run (5+ / 10+ years?) it might turn out to be the better option.
It's also important to keep the wider ecosystem in mind. Even if C and Rust were functionally identical, a rewrite could still make sense. Imagine if coreutils was written in a language like COBOL: the language choice would severely restrict the number of potential contributors. Who's going to learn it solely for the thankless job of maintaining boring tooling like coreutils? With the current generation of OSS maintainers slowly dying off, you need to recruit new (younger) developers to take over. If all the kids love Rust and hate C, then perhaps a switch to Rust might be a necessary evil to ensure we'll have well-maintained coreutils for another generation. You still need to be careful to avoid the fad of the day, but I think it's pretty clear by now that Rust is here to stay.
As an aside, as [1] shows, the "it'll at best be equal" argument is factually incorrect. There is no good reason to believe that GNU coreutils could not possibly be improved upon.
[0]: https://www.phoronix.com/news/GNU-Coreutils-9.8
[1]: https://www.phoronix.com/news/Rust-Coreutils-0.2.2
This link[0] shows a CVE with CVSS of 9.8 in 2015 (and a handful of smaller ones). From this other page on the same site[1], it claims that all of all 5 of the CVE's are caused by overflow or memory corruption.
[0] https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
[1] https://www.cvedetails.com/product/5075/GNU-Coreutils.html?v...
In this incarnation we don't always hear, "Rust is the future."[1] We hear:
* "improving security, ensuring long-term maintainability, and optimizing performance" "memory safety, concurrency, and performance" [2]
* "its ability to prevent common programming errors such as null pointer dereferences and buffer overflows" [3]
* "is that it's very portable." [4]
* "I believe that we should shift the focus away from memory safety (which many other languages also offer) and instead focus on the explicitness, expressiveness, and ecosystem of Rust that is highly competitive" [5]
* "Better error messages.Providing comprehensive internationalization support (UTF-8). Improved performances" [6]
All of these things are operational and thus quantifiable, and some (perhaps even most), are probably true. But none of them engage with evidence-based decision making. Therefore it's not really about any of these, but that's what we've been doing since the beginning of time.
1. Although we do hear this[5].
2. https://uutils.github.io/blog/2025-02-extending/
3. https://bytegoblin.io/blog/the-power-of-rust-on-linux-a-begi...
4. https://lwn.net/Articles/1007907/
5. https://corrode.dev/blog/foundational-software/
6. https://github.com/uutils/coreutils
Thompson and Ritchie could have used ALGOL, Lisp, FORTRAN, BCPL or PL/I to write Unix, but instead they created C and used that. I guarantee at the time there was someone at Bell Labs bitching about how they should be solving "real problems" instead of messing around with a new programming language.
But more practically, developers write code because they're paid to, or to scratch an itch. If a real problem doesn't substantially bother anyone enough to get solved by a developer, then it's not really a problem.
In general, code maintenance and optimization is always Somebody Else's Problem™. Instead of writing this blog post, the author could have spent that time optimizing some open source code, right?
At the same time, every generation of programmers will come in and will want to make a dent in the space time.
Why would a new developer want to use the stuff grand pa wrote ad nauseam? They want to take charge of their own adventure. Not everyone was born when things were exciting and we didn't know where we were going.
New tools likely wouldn't carry cruft that accumulated through time, as the tools understood their own essence, as they changed and morphed over time.
There is a Not_invented_here syndrome at play, with a New_shiny factor and potentially the benefits of cutting down a tool to the essential.
If anything, it's a good learning practice to rewrite existing tool, your way.
Rust does bring advantages, but if they don't learn the past, they're bound to repeat the mistakes made; memory safety only being a small part of the problem, over time (most of these old C tools now have been vetted many times over and are now pretty 'safe').
At the end of the day, greybeards are going to retire and new generations are not going to want to deal with code bases built around technology and decisions that were made in the 1990s.