rust coreutils aren’t bad, but they are new. They probably work a bit faster than the originals, and they probably are long term more stable… but they are also probably short term less reliable because they don’t have decades of problem solving supporting them yet.
Most people likely won’t even notice a change has happened.
They probably work a bit faster than the originals
There are some commands doing string processing that have been rewritten to use SIMD instructions which makes them inherently faster. On the other hand there are other commands where they’re performing worse than GNU coreutils: https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
Over time they will probably close the performance gap for those outliers, but if the GNU coreutils maintainers wanted to accelerate the same commands with SIMD instructions they could also do that. There’s no real reason why long-term one should be faster than the other, except for whichever project gets more attention from maintainers.
Rust-coreutils may eventually become a suitable replacement for coreutils but it hasn’t yet existed for long enough to iron out all the bugs and there’s no real advantage to using it right now.
The idea is that Rust will make everything easier to maintain and improve in the long run, or something like that. It’s somewhat plausible, but it’s not totally obvious whether that will prove correct. So it’s easy to suspect that there must be some other unstated motivations behind it, although to me there don’t appear to be any in view.
I think with things like this that are so foundational and far-reaching, there’s a point where you kind of just have to decide that the new thing is good enough and be ready for the rough parts of the transition.
Time is definitely a huge component of making a robust piece of software, but I think user diversity is also really important, and a project is going to hit a plateau of features and stability without wider adoption (even if it’s meant as a replacement for an existing thing) because the people working on it just don’t know about certain edge cases and don’t know to look for them.
That’s not me saying we should be migrating libraries and software just because someone remade them in a new language, but from what I know of Rust, it really does sound like a safer and and more approachable language than C++ and especially C.
Ubuntu wanted to fully switch to rust for 26.04 but they weren’t fully ready yet so some are still Classic(?)
Whenever you’re replacing something tried and true it needs to be at least as good as the original. Too many bugs or missing features and all hell will break loose.
Is this bad? I’m afraid I don’t have a good grasp on what the implications are of this.
rust coreutils aren’t bad, but they are new. They probably work a bit faster than the originals, and they probably are long term more stable… but they are also probably short term less reliable because they don’t have decades of problem solving supporting them yet.
Most people likely won’t even notice a change has happened.
There are some commands doing string processing that have been rewritten to use SIMD instructions which makes them inherently faster. On the other hand there are other commands where they’re performing worse than GNU coreutils: https://www.phoronix.com/news/Ubuntu-Rust-Coreutils-Perf
Over time they will probably close the performance gap for those outliers, but if the GNU coreutils maintainers wanted to accelerate the same commands with SIMD instructions they could also do that. There’s no real reason why long-term one should be faster than the other, except for whichever project gets more attention from maintainers.
You get your well measured response out of here.
Reactive answers only
Oh shit, sorry.
The things that I like are better than the things that you like!
They’re only MIT licensed and not GPL so in that sense yeah
I couldn’t imagine putting significant volunteer work into something that is not at least licensed under Apache, or more ideally at least LGPL.
That is not ideal.
Rust-coreutils may eventually become a suitable replacement for coreutils but it hasn’t yet existed for long enough to iron out all the bugs and there’s no real advantage to using it right now.
The idea is that Rust will make everything easier to maintain and improve in the long run, or something like that. It’s somewhat plausible, but it’s not totally obvious whether that will prove correct. So it’s easy to suspect that there must be some other unstated motivations behind it, although to me there don’t appear to be any in view.
I think with things like this that are so foundational and far-reaching, there’s a point where you kind of just have to decide that the new thing is good enough and be ready for the rough parts of the transition.
Time is definitely a huge component of making a robust piece of software, but I think user diversity is also really important, and a project is going to hit a plateau of features and stability without wider adoption (even if it’s meant as a replacement for an existing thing) because the people working on it just don’t know about certain edge cases and don’t know to look for them.
That’s not me saying we should be migrating libraries and software just because someone remade them in a new language, but from what I know of Rust, it really does sound like a safer and and more approachable language than C++ and especially C.
The motivations are purely dogmatic. Buggy and incomplete implementations have no place in mainstream distros.
Ubuntu wanted to fully switch to rust for 26.04 but they weren’t fully ready yet so some are still Classic(?)
Whenever you’re replacing something tried and true it needs to be at least as good as the original. Too many bugs or missing features and all hell will break loose.