- cross-posted to:
- linux@sh.itjust.works
- linux@programming.dev
- cross-posted to:
- linux@sh.itjust.works
- linux@programming.dev
Ubuntu 25.10’s transition to using Rust Coreutils in place of GNU Coreutils has uncovered a few performance issues so far with the Rust version being slower than the C-based GNU Coreutils. Fortunately there still are a few weeks to go until Ubuntu 25.10 releases as stable and upstream developers are working to address these performance gaps.
You must log in or # to comment.
Rust is great, but might it be a bit premature to replace the venerable coreutils with a project boasting version number 0.2, which I imagine reflects its author’s view on its maturity?
Version is just a number, just like age. (of Rust, of course)
A major version of 0 isn’t necessarily any statement regarding the projects maturity, it can also be a hack with semantic versioning. Normally, any change that is not fully backwards compatible requires you to increment the major version, but if the major version is 0, you may only increase the minor version. Because of this, many projects stay at the 0.x.y versions, so they don’t need to release version 2.0.0, 3.0.0, 4.0.0 and so on just because of minor but breaking changes as many users might expect significant new features from that version steps.
They don’t need to use semantic versioning. I doubt coreutils itself uses it, though I admit I haven’t checked. Actually I think semantic versioning is less popular in practice than it looks like.
For a set of tools to that completely replaces another one, announcing a 1.0 version would be a message that the developers think the project has actually reached its initial goals. “0.2” does not.
The author simply listened to the word of 0-Based Versioning. It says more about your maturity than of the projects. Much to learn you still have.
Do I understand the article and github issue correctly and we can put away the pitchforks already because they fixed the specific part already and it’s now even more performant than GNU coreutils?
Yes
No, you are supposed to stop reading after the headline, and then make a comment, not read the whole article.
Wasn’t rust suppose to both more performant and more memory safe than it’s C counterparts?
Rust and C are the same “tier” of performance, but GNU coreutils has the benefit of several decades of development and optimization that the Rust one needs to catch up with.
Language isn’t everything. While Rust provides some features and safety that C doesn’t while being roughly equivalent in performance, the algorithms that developers choose will dominate the performance impact on the program.
GNU core utils has decades of accumulated knowledge and optimisation that results in the speed it has. The Rust core utils should in theory be able to achieve equivalent performance, but differences in the implementation choices between one and another, or even something as simple as the developers not having prioritised speed yet and still focusing on correctness could explain the differences that are being reported.
Well the entire point of the project is that they used algorithms/features of Rust that make it easier to write fast code. This article basically reports on a “bug”. Uutils are in many ways already faster than Coreutils.
Correctness is really more of a byproduct of using Rust. Coreutils have had only a few CVEs in their lifetime so it would be sort of redundant to rewrite them in Rust for “correctness”.
Rust is fundamentally more limiting than C, even with
unsafe. It is often faster if you write naive code (because the Rust compiler can optimize more aggressively due to those same limitations), but an experienced developer with a lot of time for optimization will probably be able to squeeze more performance out of C than they would out of Rust - as you can see in this example. Rust is still better because those limitations all but guarantee that the resulting code will be safer, and the performance differences would be negligible all things considered.you can still mostly hand-write assembly in rust
Sure, but at that point you can also just write assembly. I’m talking about “idiomatic” code in the language itself.
Rust never claimed to be more performant than C. Its performance is equivalent to C.
It’s more a thing like in ripgrep vs. grep; new algorithms being vastly faster in most cases except in some.
This would never happen if it were licensed under GPL. /s
Although if it did happen they could be sued for breaking it. I really don’t get the sarcasm here. with mit/bsd not giving back is fully legal with gpl its not.
