|
|
Log in / Subscribe / Register

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:

  1. 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 yank crate 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.
  2. The cargo vendor command 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.
  3. 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.)
  4. C has _Bool because too many people typedef'd bool. Rust has namespaces and editions so they can introduce new keywords like async and 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.
  5. 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.)
  6. There are ongoing efforts to improve things further.


to post comments

Rustaceans at the border

Posted Apr 19, 2022 17:48 UTC (Tue) by jsakkine (subscriber, #80603) [Link]

In this discussion I realized that it is better to experiment with the code rather than complain from the side. I did learn about "cargo vendor" command today, and it looks like a valid option for selected components. And I'm experimenting on bringing some of the stuff that I'm maintaining in the kernel to Rust. I'm also now following the vger list, which I also learned about thanks to this article.

One thing that might become obstacle is the state of Rust front-end support in GCC because it is hard to imagine that this could end up to mainline without being able to compile it fully with stock GCC. Also, in order to use Rust ever in the core would probably require full coverage of arch/*. But I guess the latter is not end of the world as far as drivers are concerned.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds