All the different tests ive seen comparing Rust and C put compile times in the same ballpark. Even if somehow every test is unrepresentative of real-world compile times, I doubt it is “order[s] of magnitude” worse.
I remember watching someone test the performance of host a HTTP webpage and comparing the performance of Zig, Rust w/ C HTTP library, and Rust native. Rust native easily beat them out and was able to handle like 10s of thousands more client connections. While I know this isnt directly relevant to Kernels, the most popular C HTTP library is most likely quite optimized.
Memory related vulnerabilities are consistently in the top reported vulnerabilities. It is a big deal, and no, you can’t just program around it. Everyone makes mistakes, has a bad day, or something on their mind. Moments of human fallibility. Eliminating an entire class of the vulnerabilites while staying competitive with C is a hard task, but entirely worth doing.
I was curious, so I ran a not-very-scientific test based on packages built from source on my desktop. The short version of a very long post (in the repos) is that the median build time for Rust packages is, indeed, pretty close to an order of magnitude greater than that of the C packages.
One caveat is that Rust (at least, through cargo) imports dependencies at build time, and that download/compile is included whereas with C dependencies are already installed in other packages or are included. Go behaves the same as Rust, and yet the median build times are even shorter than C, so it can’t all be blamed on dependency downloads, but it also can’t be ignored.
For my purposes, it makes no difference because upgrading software on my computer always includes this build time penalty for Rust programs - and this is why Rust programs, while being a fraction (50/800) of all from-source packages installed on my system consume a disproportionately large amount of the time it takes for me to do updates from AUR. And that’s why I’ve started ignoring packages that depend on cargo or rustc.
All the different tests ive seen comparing Rust and C put compile times in the same ballpark. Even if somehow every test is unrepresentative of real-world compile times, I doubt it is “order[s] of magnitude” worse.
I remember watching someone test the performance of host a HTTP webpage and comparing the performance of Zig, Rust w/ C HTTP library, and Rust native. Rust native easily beat them out and was able to handle like 10s of thousands more client connections. While I know this isnt directly relevant to Kernels, the most popular C HTTP library is most likely quite optimized.
Memory related vulnerabilities are consistently in the top reported vulnerabilities. It is a big deal, and no, you can’t just program around it. Everyone makes mistakes, has a bad day, or something on their mind. Moments of human fallibility. Eliminating an entire class of the vulnerabilites while staying competitive with C is a hard task, but entirely worth doing.
Just FYI, because I think this was in a different thread:
https://midwest.social/comment/15427570
I was curious, so I ran a not-very-scientific test based on packages built from source on my desktop. The short version of a very long post (in the repos) is that the median build time for Rust packages is, indeed, pretty close to an order of magnitude greater than that of the C packages.
One caveat is that Rust (at least, through cargo) imports dependencies at build time, and that download/compile is included whereas with C dependencies are already installed in other packages or are included. Go behaves the same as Rust, and yet the median build times are even shorter than C, so it can’t all be blamed on dependency downloads, but it also can’t be ignored.
For my purposes, it makes no difference because upgrading software on my computer always includes this build time penalty for Rust programs - and this is why Rust programs, while being a fraction (50/800) of all from-source packages installed on my system consume a disproportionately large amount of the time it takes for me to do updates from AUR. And that’s why I’ve started ignoring packages that depend on cargo or rustc.