Huh, looks like it’s passing the amounts of tests GNU coreutils had a few years ago. Not a whole lot of gap left.
Nice. But I’m still against that kind of rust rewrite until the replacement is absolutely 100% identical with the current version.
Every argument, every input, every output, every specification for interaction.
Don’t care about the language : do not break userland compatibility please.
That’s an argument against replacing the coreutils on your systems.
Which no one is forcing you to.
But how are you against someone rewriting them using their own time and resources?Maybe I was not clear about what I think, english is not my best.
Yes, backward compatibility is my first issue with the rewrite approach, whatever the new language is, nothing against rust in particular. I am not against someone rewriting something unless it break things, fragment linux or the userland.
No one is forcing me to use new coreutils, that’s not exactly true. The day my distribution switches to rust coreutils I have two choices: deal with it, or migrate to another distribution.
The only good choice would be to select a distribution that promises not to switch coreutils packages.
Does that reminds you of init vs systemD ? Debian vs Devuan ? That approach is doomed.
this is just more proof of rust’s maturity and feasibility as a system language as it was initially architected
it will now go on to conquer the rest of the programming world lol
Side note: Considering the rewrite comes with a licence model change, conquering is the right word.
It doesn’t help, but that is entierely another matter.
