I'm surprised Torvalds is so sanguine about Rust. Maybe it's age but I remember his epic gamer rant about how he would never allow C++ in the kernel. Either Rust is significantly better than C++ in his view, or he's accepted that C is likely not going to be the dominant systems programming language forever and opted for the least dangerous alternative.
Guess I should start my 5th attempt at finally getting good at Rust.
Sounds like Torvalds is taking a measured and pragmatic approach. Which is the only thing that will work. Kudos for taking it slow, allowing maintainers to opt out until the integrations are more proven, and resisting the urge to rush such a huge change. If anything, Linus is moving very rapidly, given that Rust still requires unstable features to work with the kernel.
I have a number of negative stereotypes associated with Rust and Rust programmers that I am trying to set aside right now and just look at this from a technical perspective. Has the Rust-portability situation been addressed? Or will this change restrict the number of platforms the Linux kernel will be usable on? Assuming that is the case (I remember reading that GCC will acquire Rust support), what will the advantages be? I would guess stability might improve due to more static analysis, but what about performance? Build-time? And will this have any effect on Rust?
Read the article, mentally replacing Rust with C++ (or terms like gccrs with g++). Interesting times for the kernel; you have to wonder whether Rust will be a success or if there will be a repeat of the 1992 attempt [1] to include C++.
Does anyone have good resources to learning rust? I have a fairly good working knowledge of C, C++, and Swift.
I understand there's the Rust Book, Rustlings, and Rust By Example at https://www.rust-lang.org/learn. Are there other good resources? Does anyone have a strong suggestion on which of those official resources I should start with?
I appreciate the write-up representing the flow of discussion, not just the outcome, for the insight it carries about how decisions move through the group.
It appears Linus has said it is happening, and a bit how it should happen, but has not given strong guidance or even parameters on how long any experiment would last.
Instead, he says the maintainers can decide to accept or reject or use Rust however they like. He doesn't even say they should state their policy, so they can let people try and still reject them.
Giving maintainers the ultimate discretion I think tracks the incentive system in the kernel: maintainers, who do boatloads of work, get to be deciders. That also gives companies a strong incentive to employ maintainers.
On the tools front, Linus expressly said he wants not just an anointed compiler on kernel.org, but compilers from the distributors. He's driving Rust normalization and platform adoption as a condition of use, even though the kernel historically adopts a fairly narrow (if not archaic) set of tools.
Somehow this all seems like a bunch of rafts tied together with (platform) boats pushing at the edges -- somewhat tenuous, hard to drive, but vaguely heading in the right direction.
As others have mentioned, it's interesting that Linus and many maintainers are getting older, and instead of getting freedom and flexibility in their maturity, they can look forward to more low-level bouts of increasing complexity. When they talk about the integration of Rust, they're clearly anticipating it might not fully happen until after they're gone. That, too, could change the incentives.
I believe that in 10 years, we'll look back at Rust in the kernel and see it as a big disaster. Some people will blame the kernel team (they didn't adopt Rust well enough), and some will blame Rust itself (writing a non-toy kernel in it hasn't been tried before).
But heck, we should TRY it. So I'm glad this is finally happening.
Rust covers an infinitesimal footprint of the C/C++ code out there running the world. Rust won't replace anything substantial or meaningful in the embedded world for the time being.
If this happens, and it seems inevitable at the moment, I personally see this resulting in a potential decline of a Linux kernel in the next few years.
Just a few questions off top of my head:
* How much will it affect the development velocity? Existing devs (and maintainers) will at least need to learn how to read and debug Rust code. New devs will likely have no good competences in C which is 99% of the codebase so how good/quickly will they be able to blend in?
* How many existing kernel developers will community potentially loose because of the increased complexity?
* How much new talent will it actually be able to attract? Now people will need to learn two completely different languages and their vastly different ecosystems.
* Does Rust have high enough entry bar to produce competent kernel developers? Sometimes high entry bar acts as a very good filter to end up in a pool with a highly skilled (and motivated) engineers.
* Coordination of development efforts is now going to become much more complex. This includes writing new features (C or Rust or both?), maintaining the old ones (rewrite pieces in Rust or not?) but also code-reviews which will now pose a bigger challenge given that it will consist of mixed Rust+C code.
Having worked in codebases which mixed C and C++, I already understand what kind of issues mixing C and Rust is going to produce. And I expect them to be much more accentuated because distance(C, C++) << distance(C, Rust).
Whatever happened to that effort to write a QNX-compatible kernel in Rust. The QNX kernel is tiny. That should be working by now.
That's what you really want in Raspberry Pi sized projects.
For those with better understanding of where zig is at, why not zig for kernel development? Is it merely because it's still in heavy dev?
I love this, but also very surprised Trovalds is ok with a language that changes so much. But with git and all it maybe easier to manage just as if you would C89/99/11.
I always have reservations about clicking LWN "subscriber links" since I have not subscribed.
Perhaps it's worth waiting a week before posting these? LWN's paywall is dropped at that point.
I know the article is serious, but it has the writing-style of an onion/babylonbee article lol.
esp the last paragraph: >As time ran out, Matthew Wilcox asked whether kernel developers should be writing idiomatic Rust code, or whether they will be writing "C in Rust". Ojeda answered that code might be more C-like toward the beginning; adoption of more advanced features (such as async) might take longer. Gleixner asked what could be done to prevent developers from using unstable features (once the features used by the kernel are stabilized); the answer was to specify the version of the compiler to be used with kernel development.
> Instead, Bottomley suggested that, rather than bringing in Rust, it might be better to just move more Rust-like features into C. Ojeda said that he has actually been working with the C language committee to push for that to happen, but any such change will take a long time if it happens at all. Christoph Hellwig said that this sort of change will have to happen anyway unless the plan is to rewrite the whole kernel in Rust; he was not pleased at the idea of rewriting working code in a new language. Perhaps the sparse static analyzer could be enhanced to do more Rust-like checking, he said. Ojeda answered that the result of such efforts would be like having Rust — but much later.
Some reasonable people in this sea of sectarian crabs, glad to hear that
> Torvalds added that Rust isn't that terrible in the end; "it's not Perl".
Glowing endorsement from Torvalds right there. I'm really curious about how this will work out, Rust is my favourite programming language by a fair margin and seeing it being used more and more in places where C or C++ has traditionally dominated is very exciting. The future is looking bright (for those of us who like Rust).