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 took notes for the benefit of anyone who doesn’t like their info in video form. My attempt to summarize what Linus says:
He enjoys the arguments, it’s nice that Rust has livened up the discussion. It shows that people care.
It’s more contentious than it should be sometimes with religious overtones reminiscent of vi versus emacs. Some like it, some don’t, and that’s okay.
Too early to see if Rust in the kernel ultimately fails or succeeds, that will take time, but he’s optimistic about it.
The kernel is not normal C. They use tools that enforce rules that are not part of the language, including memory safety infrastructure. This has been incrementally added over a long time, which is what allowed people to do it without the kind of outcry that the Rust efforts produce by trying to change things more quickly.
There aren’t many languages that can deal with system issues, so unless you want to use assembler it’s going to be C, C-like, or Rust. So probably there will be some systems other than Linux that do use Rust.
If you make your own he’s looking forward to seeing it.
I love you.
This is a great summary. Thanks!
As always, Ada gets no respect.
Start the linuxa or alinux project and off you trot. Find a better name than I did here and you’ll be fine.
Ladux? Linda? +Linux, pronounced “Add a Linux” -> Ada Linux? LinLace?
Lada
Images of smoking Eastern European jalopy intensifies.
I prefer Trabant.
Anixa for the win
Adux
Nor does Forth (which used to be a common choice for “first thing to bootstrap on this new chip architecture we have no real OS for yet”). Alas, they’re just not popular languages these days.
Forth is fun but not really suitable for large, long-lasting projects with huge developer communities. Linux isn’t being bootstrapped, it’s already here and has been around for decades and it’s huge. And, I think bootstrapping-by-poking-around on a new architecture has stopped being important. Today, you have compiler and OS’s targeted to the new architecture under simulation long before there is any hardware, with excellent debugging tools available in the simulator.
I blame Ian Dury.
Possibly NSFW.
https://www.youtube.com/watch?v=1kFnHPHBcb4
Have you actually ever used Ada? It’s like programming with handcuffs on.
I have played with Ada but not done anything “real” with it. I think I’d be ok with using it. It seems better than C in most regards. I haven’t really looked into Rust but from what I can gather, its main innovation is the borrow checker, and Ada might get something like that too (influenced by Rust).
I don’t understand why Linux is so huge and complicaed anyway. At least on servers, most Linux kernels are running under hypervisors that abstract away the hardware. So what else is going on in there? Linux is at least 10x as much code as BSD kernels from back in the day (idk about now). It might be feasible to write a usable Posix kernel as a hypervisor guest in a garbage collected language. But, I haven’t looked into this very much.
Here’s an ok overview of Ada: http://cowlark.com/2014-04-27-ada/index.html
This is how they want to frame it. C has footguns, therefore use Rust—instead of Rust is one of the options you could use.
I don’t think Ada in the kernel would get any cultural acceptance. Rust has been hard enough. C++ was vehemently rejected decades ago though the reasons made some sense at the time. Adopting C++ today would be pretty crazy. I don’t see much alternative to Rust (or in a different world, Ada) in the monolithic kernel. But Rust seems like it’s still in beta test, and the kernel architecture itself seems like a legacy beast. Do you know of anything else? I can’t take D or Eiffel or anything like that seriously. And part of it is the crappiness of the hardware companies. Maybe it will have to be left to future generations.
Good human.
There’s one called Redox that is entirely written in Rust. Still in fairly early stages, though. https://www.redox-os.org/
Not a programmer whatsoever but I’ve heard about Zig and people comparing it to Rust, what’s the deal with it?
Zig is indeed designed specifically for such tasks as system programming and interoperability with C code. However it is not yet ready for production usage as necessary infrastructure is not yet done and each new version introduces breaking changes. Developers recomend waiting version 1.0 before using it in any serious project.
Zig is “c”, but modern and safe.
The big selling points compared to Rust are:
The syntax is really close to the C language; any C programmer can pick up Zig really fast.
IMO Zig is a far better choice to go in the kernel than Rust.
Linux has tried to include CPP in it, and it failed.
So imagine if trying to fit in a C-like cousin failed, how far they are to fit an alien language like Rust…
For more information: https://ziglang.org/learn/why_zig_rust_d_cpp/
Zig is safer than C, but not on a level that is comparable to Rust, so it lacks its biggest selling point. Unfortunately just being a more modern language is not enough to sell it.
C++ was not added to Linux because Linus Torvalds thought it was an horrible language, not because it was not possible to integrate in the kernel.
Zig has other selling points, that are arguably more suitable for system programming. Rust’s obsession with safety (which is still not absolute even in rust) is not the only thing to consider.
It is absolue in safe Rust, aka 99% of Rust code.
UB is only one class of error though. I get nervous when people talk about re-writing battle hardened code which has been used - and reviewed by the community - for decades because there are going to be many subtleties and edge cases which are not immediately apparent for any developer attempting a re-implementation.
Like sudo that has had zero days lurking for 10 years?
I’m not advocating for reimplementing stuff for no good reason though.
You mean old code that has bugs that are no just being discovered. Battle hardened code and many eyeballs means nothing.
Zig is a very new and immature language. It won’t be kernel-ready for at l’East another 10 years.
That’s pretty suggestive. Rust syntax is pretty good. Postfix
tryis just better for example.Zig also uses special syntax for things like error and nullability instead of having them just be enums, making the language more complex and less flexible for no benefit.
Syntax is also not everything. Rust has extremely good error messages. Going through Zig’s learning documentation, half the error messages are unreadable because I have to scroll to see the actual error and data because it’s on the same line as the absolute path as the file were the error comes from
That’s a library design question, not a language question. Rust for Linux uses its own data collections that don’t perform hidden memory allocations instead of the ones from the standard library.
I don’t know, Rust is one of the most readablelangueage for me.
Is it still the case once you have a very large project and make use of comptime?
Not true. Because it doesn’t have the guardrails that rust has, you must build a mental model of where the guardrails should be so you don’t make mistakes. Arguably this is something that C maintainers already know how to do, but it’s also not something they do flawlessly from just looking at the bugs that regularly need to be fixed.
Being able to write code faster does not equate being able to write correct code faster.
Yes, because it’s basically C with some syntax sugar. Rust is a Generational change.
But that wasn’t about the syntax, but about the fastnesses, size and control, want it? Things that shouldn’t be much of an issue to Rust.
Zig is feasible for systems programming and some, (most notably, the Primeagen in one video) claim it should have gone into the kernel instead of Rust, but I don’t know Zig so I don’t feel qualified to comment beyond that.
On a tangential note, what does Linus used, Vi or Emacs?
He uses a version of Emacs called MicroEmacs.
I recall seeing his MicroEmacs configuration a while back when I was exploring options to start using Emacs.
TIL that version appears to be on the AUR: MicroEMACS/PK 4.0.15 customized by Linus Torvalds.
Last updated in 2014, it probably has serious cobwebs now. Even the upstream hasn’t been touched in 6 years.
In testing, to settle a bet by a rabid cult-of-vi peer, I opened a given set of files in each editor, each a day apart because I couldn’t be arsed to clear caches. This guy, otherwise a prince, was railing about emacs, but otherwise suffered days of waiting.
10/10 the memory usage by his precious vi was same-or-more than emacs.
There’s so many shared libs pulled in by the shell that all the fuddy doomsaying about bloat is now just noise.
I avoid vi because even in 1992 it was crusty and wrong-headed. 30 years on the hard-headed cult and the app haven’t changed.
I don’t see how microEmacs can improve on what we have by default, and I worry that the more niche the product is the harder it will be to find answers online. But I’m willing to be swayed if anyone can pitch its virtues.
MicroEmacs was written in 1985 and has nothing to do with GNU Emacs (which people just call Emacs these days). It’s entirely outside of the vi-vs-emacs war.
Yeah the interface for it - and functionality - is more like nano than actual Emacs.
If we can believe random strangers in the internet, then Linus uses a self maintained lighter version of Emacs, or has. Looks like Linus is an Emacs guy.
my money is on vi or vi derivates.
Thank you for the summary!
Doing the lord’s work, thank you.
Isn’t there Redox OS?
Edit: yes, it’s still alive and kicking.
I think Linus mentioned Redox directly during the interview
what did he say about it?
He just mentioned it as an example of a kernel written in Rust. The interviewer asked if Rust isn’t accepted into the Linux kernel, would someone go out and build their own in Rust, and Linus mentioned Redox saying that’s already happened.
You write “vi versus the world” funny.
I use Micro except for when I forget to install it and can’t, at which point I use Nano
it’s a polite way of saying, “intelligence vs emacs”
I think it can be summed up to C is more mature than Rust so we wait for Rust to shine Rust can overcome some complex things in C and vice versa
Thank you for the write-up!!
How is it that no matter what the damn topic is, Linus always seems to be the most level-headed in the room? I really admire him for that…
Edit: Lol, Linus, not Linux. Linus. xD
Linus did have emotion control issues and was not always completely rational, but he’s gone a long way towards being incredibly responsible to his child that powers the world.
Also, he long understands that Linux ain’t a hobby project, which some programmers still get to think.
Good bot!
Linus Torvalds has made some interesting comments on the Rust vs C debate in the Linux kernel. He enjoys the discussions because it shows that people care about the project, even though things can get a little heated like the classic vi vs emacs arguments. The Rust conversation is still in its early days, and while Linus is optimistic about its future in the kernel, it’s too soon to say whether it will ultimately succeed or fail.
He points out that the Linux kernel isn’t just “normal” C it’s C with additional tools and rules that ensure memory safety and other protections. This incremental approach has allowed for changes without causing the kind of backlash that Rust has faced with its more dramatic changes.
At the end of the day, the kernel has to deal with system-level issues, and unless you’re working in assembly, it’s going to be C, C-like, or Rust. Linus is looking forward to seeing how other systems outside of Linux might adopt Rust for their own needs.
If you’re interested in exploring more of these tech discussions or maybe looking for some related tools, you can download APK for access to various Linux utilities on mobile.