4 ms·

They're faster? They must have been working on performance then, maybe I should take another look at how that project has been maturing. When I last looked 'dd

by Arcuru 2y ago

They're faster? They must have been working on performance then, maybe I should take another look at how that project has been maturing. When I last looked 'dd' was significantly slower, though I did make it a bit closer a while back - https://jackson.dev/post/rust-coreutils-dd/ https://jackson.dev/post/rust-coreutils-dd/ A lot of the Rust coreutils were written by people learning the language, and the code is often _more_ complicated than the corresponding code for the Unix utils. They don't seem to get enough experienced programmers fixing them up or usage for me to actually recommend anybody use them, but maybe that's changing.

mustache_kimono 2y ago
> When I last looked 'dd' was significantly slower, though I did make it a bit closer a while back - https://jackson.dev/post/rust-coreutils-dd/ https://jackson.dev/post/rust-coreutils-dd/ I read your blog. Maybe you should take a look at some of the other utils. I worked on sort and ls and both have long been faster than their GNU equivalents. > They don't seem to get enough experienced programmers fixing them up or usage for me to actually recommend anybody use them, but maybe that's changing. The issue is obviously compatibility and the uutils won't be broadly "usable" or stable until is hits 100% PASS/0% FAIL on the GNU test coverage, although the numbers are getting better and better. See: https://raw.githubusercontent.com/uutils/coreutils-tracking/refs/heads/main/gnu-results.png https://raw.githubusercontent.com/uutils/coreutils-tracking/... > A lot of the Rust coreutils were written by people learning the language, I really, really hate this way of framing the project -- which implicitly sounds like GNU is full of pros. Yes, lots of code was written by people just learning Rust and systems programming. Once it reaches parity on GNU test coverage, which it is rapidly approaching, GNU coreutils would wish it had this kind of enthusiasm behind it. > and the code is often _more_ complicated than the corresponding code for the Unix utils. I think it really depends. Much of the code is much simpler. For instance -- I think it's much easier to generically do hashing in Rust, and it shows.
- oguz-ismail 2y ago
  Yeah just two more weeks

by Arcuru 2y ago

mustache_kimono 2y ago

> When I last looked 'dd' was significantly slower, though I did make it a bit closer a while back - https://jackson.dev/post/rust-coreutils-dd/ https://jackson.dev/post/rust-coreutils-dd/ I read your blog. Maybe you should take a look at some of the other utils. I worked on sort and ls and both have long been faster than their GNU equivalents. > They don't seem to get enough experienced programmers fixing them up or usage for me to actually recommend anybody use them, but maybe that's changing. The issue is obviously compatibility and the uutils won't be broadly "usable" or stable until is hits 100% PASS/0% FAIL on the GNU test coverage, although the numbers are getting better and better. See: https://raw.githubusercontent.com/uutils/coreutils-tracking/refs/heads/main/gnu-results.png https://raw.githubusercontent.com/uutils/coreutils-tracking/... > A lot of the Rust coreutils were written by people learning the language, I really, really hate this way of framing the project -- which implicitly sounds like GNU is full of pros. Yes, lots of code was written by people just learning Rust and systems programming. Once it reaches parity on GNU test coverage, which it is rapidly approaching, GNU coreutils would wish it had this kind of enthusiasm behind it. > and the code is often _more_ complicated than the corresponding code for the Unix utils. I think it really depends. Much of the code is much simpler. For instance -- I think it's much easier to generically do hashing in Rust, and it shows.

oguz-ismail 2y ago
Yeah just two more weeks