Rustaceans at the border
Rustaceans at the border
Posted Apr 17, 2022 23:08 UTC (Sun) by ssokolow (guest, #94568)In reply to: Rustaceans at the border by wtarreau
Parent article: Rustaceans at the border
I think the "random code being injected all the time just to add a line on a resume" being undesirable is the important thing.
Cargo isn't NPM and they provide multiple layers of protection against kernel code failing to build ten years from now:
- Crates.io is designed so that only the admins can remove things and they don't do that unless either they're legally compelled to or the thing in question is out-and-out malicious. Developers can
cargo yankcrate versions with security vulnerabilities to prevent new things from depending on them, but they're still available to be downloaded by any project that has them in the lockfile that Cargo automatically maintains, and you're encouraged to commit your lockfiles to version control alongside your code. - The
cargo vendorcommand automates what the kernel devs currently do with things like zstd, providing something similar to the status quo, but while still preserving machine-readable info on where they came from that allows you to streamline monitoring for updates and auditing them for manually approved inclusion. - They care enough about forward compatibility and their v1.0 stability promise that, when they're considering making a change to the compiler or standard library in line with "We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations.", they've got a bot named Crater that can build and run the test suites for a chosen subset of the crates on crates.io, with "every single one" being a valid option. (Thank goodness for Microsoft donating the Azure time. It's a resource-expensive process.)
- C has
_Boolbecause too many peopletypedef'dbool. Rust has namespaces and editions so they can introduce new keywords likeasyncand add new things to the prelude (the set of identifiers that get pulled into scope by default) without breaking existing code, because you have to opt into newer editions... and you can mix editions in the same build. They're just different frontends to produce the same underlying AST. - The compiler, standard library, etc. have an extensive test suite that gets run on every pull. (Another thing that would have become either prohibitively expensive or cripplingly slow with the growing number of platform targets without Microsoft donating Azure time.)
- There are ongoing efforts to improve things further.
