Linus Torvalds Speaks on the the divide between Rust and C Linux developers an the future Linux. Will things like fragmentation among the open source community hurt the Linux Kernel? We’ll listen to the Creator of Linux.
For the full key note, checkout: Keynote: Linus Torvalds in Conversation with Dirk Hohndel
The Register’s summary: Torvalds weighs in on ‘nasty’ Rust vs C for Linux debate
I don’t want to watch a video about it.
I’d like to know it, but a couple of sentences wouldn’t have hurt
it’s more “it forces you to make it burrow checker friendly”.
A burrow checker is not the only mechanism to write safe code. All the mess of Rust is all because this is the strategy they adopted.
And this strategy, like everything in this world, has trade offs. It just happens that there are a lot, like, - a lot -, of trade offs, and those are insufferable when it comes to Rust…
And because it looks like C, JavaScript, Bash and a few others all mixed up together.
I’ve heard Rust described as “Rust is what you get when you put all the good features of other programming languages together. You can’t read it, but it’s freaking fast!”
It forces you to be careful in the way it wants you to be careful. Which is fine, but it makes it a strange beastie for anyone not used to it.
I also dont like videos for this stuff. Summarized using kagi’s universal summarizer, sharing here:
- The integration of Rust into the Linux kernel has been a contentious topic, with some long-term maintainers resisting the changes required for memory-safe Rust code.
- The debate over Rust vs. C in the Linux kernel has taken on “almost religious overtones” in certain areas, reflecting the differing design philosophies and expectations.
- Linus Torvalds sees the Rust discussion as a positive thing, as it has “livened up some of the discussions” and shows how much people care about the kernel.
- Not everyone in the kernel community understands everything about the kernel, and specialization is common - some focus on drivers, others on architectures, filesystems, etc. The same is true for Rust and C.
- Linus does not think the Rust integration is a failure, as it’s still early, and even if it were, that’s how the community learns and improves.
- The challenge is that Rust’s memory-safe architecture requires changes to the existing infrastructure, which some long-time maintainers, like the DRM subsystem people, are resistant to.
- The Linux kernel has developed a lot of its own memory safety infrastructure over time for C, which has allowed incremental changes, whereas the Rust changes are more “in your face.”
- Despite the struggles with Rust integration, Linus believes Linux is so widely used and entrenched that alternative “bottom-up grown-up from the start Rust kernels” are unlikely to displace it.
- Linus sees the embedded/IoT space as an area where alternative kernels built around different languages like Rust may emerge, but does not see Linux losing its dominance as a general-purpose OS.
- Overall, Linus views the Rust debate as a positive sign of the community’s passion and an opportunity to learn, even if the integration process is challenging.
FWIW, it’s a 9 min video and doesn’t contain anything earth shattering or easily summarized. Basically there is some friction between C and Rust devs, and Linus doesn’t think that it’s such a bad thing (there has be interesting discussion) and it’s way too early to call Rust in the kernel a failure.
This summary seemed pretty good though.
If you believe in ADTs, limiting mutation, & a type system that goes beyond Rust’s affine types + lack of refinements (including a interleaved proof system), you could be writing kernel code in ATS which compiles to C.
there have been attempts at writing kernels using stuff like Coq https://www.cs.columbia.edu/~rgu/publications/cacm19-gu.pdf
Correct me if I am wrong, but my understanding is that you use Coq to prove your theroem, then need to rewrite it in something else. I think there is some OCaml integration, but OCaml—while having create performance for a high level language & fairly predictable output—isn’t well-suited for very low-level kernel code. The difference in the ATS case (with the ML syntax similarity 🤘) is you can a) write it all in a single language & b) you can interweave proof, type, & value-level code thru the language instead of separating them; which means your functions need to make the proof-level asserts inside their bodies to satisfy the compiler if written with these requirements, or the type level asserting the linear type usage with value-level requirements to if allocating memory, must deallocate memory as well as compeletly prevent double free & use after free.
For those in the back: Rust can’t do this with its affine types only preventing using a resource multiple times (at most once), where linear types say you must use once & can only use once.
You’r right that only OCaml and Haskell can be used as extraction target for Coq programs. However, it is possible to use Coq to write verified C software. On example is the Verified Software Toolchain that lets you translate C programs to a format that Coq understands and can prove theorems regarding their behavior.
This video is full of jarring edits which initially made me wonder if someone had cut out words or phrases to create an abbreviated version. But, then I realized there are way too many of them to have been done manually. I checked the full original video and from the few edits i manually checked it seems like it is just inconsequential pauses etc that were removed: for instance, when Linus says “the other side of that picture” in the original there is an extra “p” sound which is removed here.
Yet another irritating and unnecessary application of neural networks, I guess.
You can’t improve and break silence without discussing and making changes. The existing maintainers won’t live forever, having Rust in the Kernel is a bet on the future. Linus wouldn’t have adopted and accepted Rust, if he wasn’t thinking its worth it. And looks like it was already worth it.
I think you’re correct except for “having Rust in the Kernel is a bet on the future”. That’s something the techbro’s would say.
Do you have something against it? People hate on it like it’s a fad or whatever. But, the people who like it, LOVE it.
Rust is the most admired language, more than 80% of developers that use it want to use it again next year.
https://survey.stackoverflow.co/2023/#overview
Rust is on its seventh year as the most loved language with 87% of developers saying they want to continue using it.
https://survey.stackoverflow.co/2022/#overview
8 years in a row. I can understand the perspective of someone who spent years honing their craft in C/C++ and not wanting to learn a new language. But, the Harassment of the “Rust in Linux Lead” is ridiculous. I’m not saying you are harassing. But, saying it’s a tech bro thing is just negative and doesn’t do justice to how many devs just like rust.
I only have something against the syntax, but nothing against anything else about it, nor is my comment meant as a negative against the language. What I referred to was simply about how that stupid sentence is not a good comment and completely personal opinion. I am sure a lot of programming languages would have gotten the same label at one point in time. And many times they have been superseded by the next big thing.
If anything I think that the current rust discourse is a fad. I’m not sure what it is about rust that makes people have so strong opinions about it but I can’t wait for it to become a “normal” language so that people can chill about it a bit.
It’s also possible the number of people who like it do not outnumber the people who don’t like it
The existing maintainers won’t live forever, having Rust in the Kernel is a bet on the future.
You’re drastically reducing your talent base by requiring membership in two groups of experts. Well done.
The comma splice gives it away, but you’re new at organizing groups and practicing set theory, aren’t you?
No. That does not mean they have to program in both languages. If the programmer only understand one language (which would be a shame), then they only need to program in their field. This increases the talent base, not reduces it. C programmers do not need to be a Rust expert, so what in the world are you saying there? They just need to cooperate!
Spoken like a wise elder!