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.
> This assumes that the C code is already fully optimal, but it very obviously is not.
Yeah, there's a lot of crusty old C code out there which has fallen way behind in performance, but everyone still uses because it's proven to be robust by C standards and changing it would be tempting fate. There's a tension between performance and security which doesn't exist to nearly the same degree in Rust, which is why you get instances like this where zero-unsafe Rust can run circles around the canonical C library.
Yeah, I find the notion that coreutils is so proven and solid that it can't possibly be improved in any way to be utterly ridiculous. And I'm not even saying Rust necessarily has to be the thing to do it.
I just don't believe "pile of old C" is any kind of strong indicator of quality or performance, positive or negative.
> 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.