In this video I discuss Ubuntu's decision to switch to using rust implementations of the core utilities (mkdir, ls, cat, etc...) and what it could mean for the broader Linux ecosystem. My merch is ...
Code written in Rust has been shown to have significantly fewer security vulnerabilities than code written in C. Distributions like Ubuntu ship a lot of security updates, so by switching to Rust-based utils, they can reduce their workload in the long run.
But looking at the security vulnerability records of gnu coreutils that wasn’t really needed. There were like a handful in the last 15 years… So I don’t really see a need or benefit here.
The success of FOSS can in large part be attributed to copyleft licenses like the GPL. Without the protections of copyleft clauses, software just gets exploited by large corporations and end users are locked out. For just one example, if GNU software had used MIT, the entire free router movement (i.e ddwrt, openwrt and co.) would probably not exist today.
Edit: actually, I think by the time of this specific lawsuit, the sources for wrt54g were already released after community pressure, this article details the history a bit better.
In large part it’s a matter of opinions and different perspectives. A common consensus is libraries should be MIT and entire applications should be GPL. However, this is not held by all community members.
Overall, Rust is easier to read and harder to fuck up, so there’s one argument in favour if it, in terms of community engagement. For an example of this, compare ls.c by Apple, GNU, FreeBSd and OpenBSD.
On the other hand, I should imagine most people simply install ripgrep and fd anyway.
Rust is better for writing multithreaded applications which means that the small amount of utilities that can utilize parallelism receive a significant speedup. uutils multithreaded sort was apparently 6x faster than the GNU utils single threaded version.
P.S. I strongly doubt handwritten assembly is more efficient than modern C compilers.
P.S. I strongly doubt handwritten assembly is more efficient than modern C compilers.
As with everything, it all depends.
When writing super efficient assembly you write towards the destination and not necessarily to fit higher level language constructs. There are often ways to cut corners for aspects not needed, reduction in instructions and loops all based on well designed assembly.
The problem is you aren’t going to do that for every single CPU instruction because it would take forever and not provide a good ROI. It is far more common to write 99% of your system code in C and then write just the parts that can really benefit from fine tuned assembly. And please note that unless you’re writing for an RTOS or something crazy critical on efficiency, its going to be even less assembly.
Of course, for hot paths or small examples it is, but I doubt it’s feasible or maintainable to write a “real” projects like core utilities in assembly.
Outside of security you have some very really world benefits, like performance gains in various scenarios as well as lots more people willing to contribute and a much better type system (more maintainability).
Exactly! I would never PR, extend or build off find.c, And I sure as shit I’m not gonna work on C or C++ in my own free time. However, Rust is really fun to use, and it’s got a great ecosystem. In this vein, this is a good thing for the community, and it’s not just hype.
The Fish blog post discussed this and I think they had a good point when they were talking about how hard it was to get contributors from a large pool when they were working with C++.
Without a doubt, anything you can do in Rust you can do in C and C++, but I think it’s fair to say the large majority of people are going to be more productive in Rust or at least have a more enjoyable development experience.
Is there any actual benefit ?
Code written in Rust has been shown to have significantly fewer security vulnerabilities than code written in C. Distributions like Ubuntu ship a lot of security updates, so by switching to Rust-based utils, they can reduce their workload in the long run.
But looking at the security vulnerability records of gnu coreutils that wasn’t really needed. There were like a handful in the last 15 years… So I don’t really see a need or benefit here.
After introducing the Pro I don’t think so.
There’s probably some zero day exploit someone is holding onto until everything is rust and then, bam!. Yeah, that’s just silly to think. Just silly.
Well the rust project is MIT licensed, so definitely not.
I thought MIT licensing was a good thing?? What am i missing??
The success of FOSS can in large part be attributed to copyleft licenses like the GPL. Without the protections of copyleft clauses, software just gets exploited by large corporations and end users are locked out. For just one example, if GNU software had used MIT, the entire free router movement (i.e ddwrt, openwrt and co.) would probably not exist today.
See: Free Software Foundation, Inc. v. Cisco Systems, Inc..
Edit: actually, I think by the time of this specific lawsuit, the sources for wrt54g were already released after community pressure, this article details the history a bit better.
In large part it’s a matter of opinions and different perspectives. A common consensus is libraries should be MIT and entire applications should be GPL. However, this is not held by all community members.
Overall, Rust is easier to read and harder to fuck up, so there’s one argument in favour if it, in terms of community engagement. For an example of this, compare
ls.cby Apple, GNU, FreeBSd and OpenBSD.On the other hand, I should imagine most people simply install ripgrep and fd anyway.
It’s been proven faster. That’s all I personally know.
Nothing except for binary coding can be faster than C I think.
Rust is better for writing multithreaded applications which means that the small amount of utilities that can utilize parallelism receive a significant speedup. uutils multithreaded sort was apparently 6x faster than the GNU utils single threaded version.
P.S. I strongly doubt handwritten assembly is more efficient than modern C compilers.
As with everything, it all depends.
When writing super efficient assembly you write towards the destination and not necessarily to fit higher level language constructs. There are often ways to cut corners for aspects not needed, reduction in instructions and loops all based on well designed assembly.
The problem is you aren’t going to do that for every single CPU instruction because it would take forever and not provide a good ROI. It is far more common to write 99% of your system code in C and then write just the parts that can really benefit from fine tuned assembly. And please note that unless you’re writing for an RTOS or something crazy critical on efficiency, its going to be even less assembly.
In large applications maybe not, but in benchmarks there can be a perfectly optimized assembly
Of course, for hot paths or small examples it is, but I doubt it’s feasible or maintainable to write a “real” projects like core utilities in assembly.
Everyone knows you can do Roller Coaster Tycoon at most, no way you could do core utilities.
I’m sure you can do
catin assemblyMy simple assembly program can rum circles around compilers. As long as something is small it is possible to optimize better than a C compiler.
Multithreading isn’t a true efficiency benefit. I was talking about different things there.
Fortran
I’m not sure why people are downvoting you, since Fortran is known to be extremely performant when dealing with multidimensional arrays.
Just security and hype afaik.
No, it isn’t just hype. The hype is justified.
Outside of security you have some very really world benefits, like performance gains in various scenarios as well as lots more people willing to contribute and a much better type system (more maintainability).
Exactly! I would never PR, extend or build off
find.c, And I sure as shit I’m not gonna work on C or C++ in my own free time. However, Rust is really fun to use, and it’s got a great ecosystem. In this vein, this is a good thing for the community, and it’s not just hype.The Fish blog post discussed this and I think they had a good point when they were talking about how hard it was to get contributors from a large pool when they were working with C++.
Without a doubt, anything you can do in Rust you can do in C and C++, but I think it’s fair to say the large majority of people are going to be more productive in Rust or at least have a more enjoyable development experience.