3 ms·

I've been of the same opinion for a long time... if an operating system was to provide its lowest-level tools in Rust (not just coreutils, but everything a mini

I've been of the same opinion for a long time... if an operating system was to provide its lowest-level tools in Rust (not just coreutils, but everything a minimal Debian is comprised of), Cargo and the crates.io ecosystem would likely not be part of it. Very similar to how they are not part of the Linux kernel. It shows Rust can be used without it, but... it's so much of a regression for building systems compared to C.

nightpool 2y ago
> it's so much of a regression for building systems compared to C. huh?
- whytevuhuni 2y ago
  That is with regards to the points raised in the article, specifically, how hard it is to manage dependencies, and their security, when you have 300 of them instead of 12. For a developer, crates.io makes managing dependencies a breeze. For a user, they might just download a static binary, or a FlatPak, and they'll be happy. But for system binaries? Those need to be part of a small base, with trusted dependencies. The crates.io model works against that; the massively distributed ownership of micro-dependencies makes trusting the security of your system almost impossible. Statically built binaries means that updating your system means re-downloading the entire OS on every security update. The only solution to this is to ditch crates.io and vendor a small base of dependencies, the same way the Linux kernel does it, the same way Firefox does it, and the same way the Rust compiler does it. Using crates.io is really hard.
  - nightpool 2y ago
    Setting aside whether or not I agree with the premise that smaller dependencies are worse for building system binaries (I think Nix provides a compelling counterargument), how is vendoring Rust dependencies "like C" (the same way Firefox and the kernel do) a regression from building C? All Linux dependencies are already vendored, and even without access to crates.io, getting access to Rust's language features is still a Pareto improvement over C, not a regression.

nightpool 2y ago

> it's so much of a regression for building systems compared to C. huh?

whytevuhuni 2y ago
That is with regards to the points raised in the article, specifically, how hard it is to manage dependencies, and their security, when you have 300 of them instead of 12. For a developer, crates.io makes managing dependencies a breeze. For a user, they might just download a static binary, or a FlatPak, and they'll be happy. But for system binaries? Those need to be part of a small base, with trusted dependencies. The crates.io model works against that; the massively distributed ownership of micro-dependencies makes trusting the security of your system almost impossible. Statically built binaries means that updating your system means re-downloading the entire OS on every security update. The only solution to this is to ditch crates.io and vendor a small base of dependencies, the same way the Linux kernel does it, the same way Firefox does it, and the same way the Rust compiler does it. Using crates.io is really hard.
- nightpool 2y ago
  Setting aside whether or not I agree with the premise that smaller dependencies are worse for building system binaries (I think Nix provides a compelling counterargument), how is vendoring Rust dependencies "like C" (the same way Firefox and the kernel do) a regression from building C? All Linux dependencies are already vendored, and even without access to crates.io, getting access to Rust's language features is still a Pareto improvement over C, not a regression.