News for hackers. Stuff that matters.
Re:Why Is C Faster Than Java (2009) by kovac on Monday December 27, 2021 @01:59AM (#29700171)
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.
Re:Why Is C Faster Than Java (2009) by the_duke on Monday December 27, 2021 @03:02AM (#29700479)
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.

Re:Why Is C Faster Than Java (2009) by blub on Monday December 27, 2021 @03:53AM (#29700752)
Can’t say I disagree with you. A multi-threaded, memory safe cat sounds like a worthwhile future project for the Rust community.
Re:Why Is C Faster Than Java (2009) by fractalb on Monday December 27, 2021 @04:25AM (#29700925)
I didn’t understand the need for a multi-threaded version of cat. File reading/writing is a sequential thing, right?
Re:Why Is C Faster Than Java (2009) by kreeben on Monday December 27, 2021 @06:09AM (#29701441)
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.
Re:Why Is C Faster Than Java (2009) by adrianN on Monday December 27, 2021 @02:30AM (#29700327)
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.
Re:Why Is C Faster Than Java (2009) by nineteen999 on Monday December 27, 2021 @04:48AM (#29701047)
The obvious solution, of course, is to write yet another package manager.