Lots of standard tools of the GNU ecosystem have a faster, safer, cleaner Rust alternative. (think of ripgrep, fcp, tac...)
Is it conceivable that these tools become GNU packages, and replace the old C ones in the major GNU/Linux distros?
I feel like GNU, GCC, etc. are becoming obsolete...
Or are we stuck with the old GNU tools, because of their thousands of legacy features that nobody would want to implement nowadays but that we need for compatibility? or because the distros' maintainers would refuse?
This would be beneficial for Rust, because it would prove to everyone that it can handle it, and because it would attract a lot of developers to improve these tools.
Is it conceivable to replace the various GNU tools with Rust equivalents? Yes. Is Rust a good fit for the job? Yes. Is it a wise investment in engineering time? Absolutely not. Would this sort of Rewrite-it-in-Rust campaign get much traction? Probably not.
I think you would need a better reason to duplicate several developer-decades worth of work than to prove Rust can do it or attract developers to improve the standard GNU tools.
Besides the duplication of efford issue, if you want people to switch they'll need a drop-in replacement... meaning your Rust program needs to be bug-for-bug compatible with the C version. Anything less and people will lose confidence in the Rust program because they'll run into subtle bugs where they've relied on an undocumented aspect of the C program's implementation (relevant XKCD) and are surprised when Rust behaves differently.
If it isn't a drop-in replacement that means people will need to rewrite all their old code to work with the Rust equivalents, which is a bit optimistic. People also have inertia, and if they've become an expert in using GNU grep they probably won't want to throw that knowledge away and to learn ripgrep from scratch. It's just a lot of code to rewrite for no tangible benefit.
I love Rust as much as the next person and it has been my favourite language to use in day-to-day applications for about 5 years now, but I don't think rewriting the GNU tools would be a good way to spend your time unless it's purely a hobby.
That said, the coreutils project seems to be taking on the challenge.
You can't ergonomically output non-UTF8 in Rust by design (Display is really WriteUTF8), so outputting unescaped OsStrings is permanently a pain
Not a big deal but (in rather un-Rust like fashion IMO) you're indirectly encouraged to panic on non-UTF8 arguments or environment by using args and vars vs vars_os (the panicky versions are shorter and I don't think I have ever seen an example use the _os variants, and this includes the front page examples of extension crates like clap)
No locale support in the native formatting
Signal handling is also a pain (have fun with SIGPIPE)
Not to say people shouldn't try if they like. I'd love that really; gaining traction would inevitably mean some more libraries would be created to fill the gaps, and probably filter into std eventually.
But in general I'd say GNU's Not Usurped. Won't be for decades at minimum.
I disagree. I use several tools that work better, faster, and more conveniently, thanks to the rewrite. I use rg and fd daily, and the difference in speed is vast. Granted, it's not only because it's Rust, but still, if we re-design and rewrite software in order to use better algorithms and provide better ergonomics, we might as well do it in a safer, higher-level language.
I really hope there is one day some (even if hobby) Linux distro that runs on mostly Rust-tools rather than C-tools. One of the biggest differences to me about Rust vs C is:
I rarely read source of external C libs, and almost never modify them.
I regularly read random Rust crates, and frequently maintain local modifications.
There's something, and I might be biased here, that makes Rust code that much more easier to read + modify (measured as in: confident it is correct after beating compiler errors) compared to C code.
For this reason alone, I would love to have a Linux distro that is mostly Rust based, just because I would be more likely to read / tinker with the code.
I don't particularly see the motivation to rewrite billions of lines of existing C/C++ in Rust just because we have a new shiny language. All that stuff has taken uncountable lifetimes of effort to create and for the most part works very well. Seems to me that rewriting it would be a gigantic effort with little gain.
Rather, we should look to the future. There is an ever growing number of programmers in the world and and lot of new software that will need to be written. The future of Rust looks bright in that place.
Of course if someone feels the itch to create some kind of grep or sort or whatever that offers useful features, even if only speed, by all means they should go ahead and scratch that itch, that would be great.
Ultimately perhaps we will get an operating system in Rust from the ground up, together with a user land that is Rust friendly and not tied to the POSIX API. Wishful thinking perhaps.
I would not write off GCC as obsolete. Especially since there seems to be some effort underway to create a Rust front end for it.