On: Why Is C Faster Than Java (2009)

[throwaway894345]

Security is only one reason to rewrite utilities in another language. In particular for these foundational utilities, it means more of your dependency tree can be reproducibly built without the help of specialist package maintainers. Other reasons also include “fun” and “learning”.

[kovac → throwaway894345]

Considering that package mgmt is a well solved problem, rewriting these tools for that in return for slow, bloated alternative sounds like a huge tradeoff to me. Fun and learning on the other hand, sure.

[the_duke → kovac]

Rust rewrites are often excellent and very fast. (ripgrep, fd, ...)

A big reason is that they are usually multi-threaded, while the C counterparts are not.

Writing (memory)safe and maintainable parallel code is much, much easier in Rust than in C.

[blub → the_duke]

Can’t say I disagree with you. A multi-threaded, memory safe cat sounds like a worthwhile future project for the Rust community.

[fractalb → blub]

I didn’t understand the need for a multi-threaded version of cat. File reading/writing is a sequential thing, right?

[kreeben → fractalb]

AFAIK operating systems delegate reads/writes to their IO subsystem. This subsystem can optimize the IO operations by scheduling them in an order that differs from when they arrived to the IO queue and this improves performance in some cases. Instead of FIFO the subsystem operates on the segment of your storage device that is closest to its current location. Modern IO subsystems are both thread-safe and smarter than the average programmer.

[adrianN → kovac]

I'm not so sure that package management is really a well solved problem. Sure, there are some solutions, but as far as I know all leave some things to be desired.

[nineteen999 → adrianN]

The obvious solution, of course, is to write yet another package manager.