Re:Why Is C Faster Than Java (2009)
by throwaway894345 on Monday December 27, 2021 @01:28AM
(#29700020)
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”.
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.
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.
Can’t say I disagree with you. A multi-threaded, memory safe cat sounds like a worthwhile future project for the Rust community.
I didn’t understand the need for a multi-threaded version of cat. File reading/writing is a sequential thing, right?
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.
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.
On Github I see people rewriting simple UNIX utilties, e.g, cat, in some "safe" language, e.g., Rust. Yes, it is possible there could be some exploit based on an error in cat, maybe triggered by some malicious input that the user fails to detect, but this would not be a concern to the same degreee as errors in large, complex applications with network and other privileged access that are relatively new. For example, using C to write cat versus using C to write git.
Exposure to security vulnerabilities depends not only on the language used, but also when, where and how the application is used.