What a ridiculous way to make an argument. Even a silly seatbelt had to wait for about 10 years after being released before it was required to be in cars. Maybe write a few other kernels in Rust before using it in billions of devices? But no, shoot straight for Linux because "C bad, Rust good".
For the Linux kernel? Absolutely. Rust is way too unstable right now for such an important piece of software. Give it 20 years and a standard, then we can talk.
Do you imagine how long it would take to compile the Linux kernel if it were rust only? Not to mention the kernel has to allow for third party closed source stuff like drivers, wouldn't that force you to allow unsafe Rust and put you back to square one?
Still makes no sense to me to spend energy into pushing Rust into Linux instead of creating some new better kernels, I mean having some of this big companies paying a few experts to do such a kernel and keep compatibility with user applications. If Rust is much better then C and adding on top the fact you start fresh with no baggage you should get a better Linux and everyone would use it since is safer and faster especially on servers.
I don't know of such a Rust kernel being worked on that is not some hobby side project but something more like Servo was, where you have paid experienced in domain developers.
I would also be interested if there's any specific reasoning there, especially because there's an effort to get rust supported as way of writing kernel modules in linux, a pretty dogmatically C (though not standard C) codebase. I am personally very exciting for rust's potential in low-level embedded applications.
Writing an operating system is hard and laborious. There are many bugs beyond memory and there are already many tools the Linux team uses to make it safer. That you can make a better, more stable version of the Linux kernel with rust is still to be proven. Not arguing that the language is not better than C or that, if Linux was being started today, it wouldn't be a more sensible pick. But the language is just one component among many others that make such a projects successful.
I would actually be very surprised if there was anything nearly as good as Linux written in rust already. I'm not sure why a company would invest the huge amount of resources to get it done by now and, unless the language had some really unprecedented productivity, I don't think a community led protect would've had it finished by now.
"Rust does not run any critical component like Linux Kernel..." - and the only reason why it is not happening (provided that C and Rust have perfect interoperability, more and more C/C++ developers get familiar with Rust) is the fact that Linus Torvalds convinced by voices from Ethernet socket not to use anything but C. I can't wait for him to retire so that Linux kernel devs could pick up more modern toolset
The kernel has accumulated a lot of technical debt.
Linus speaks openly about it.
Mixing in the new flavor into a codebase that is
95% (?) using (and abusing) C with warts and all does
not strike me as a good idea.
Interaction between assembly, C and Rust is not nearly
well, enough understood to start.
Now if it does go ahead, it will be a great platform
to figure out the edge cases, bugs and all those things
nobody thought about.
I am in favor of Linux.NEXT
Write a new kernel in Rust (if it's the best choice)
Take all the learnings from Linux and all the research in
operating systems that have occurred since
and make Linux.NEXT.
Steal from Linux, WindowsNT, Quebes, OS/400, Solaris, Minix, z/OS
Plan 9, Fuchsia, BeOS/Haiku, ESXi, QNX, and of course TempleOS
Creating an operating system suitable for 2020 with the way
technology, infrastructure, connectiveness, pervasiveness,
privacy conscious, built for the hostile world of the Internet.
Every (popular) modern operating system sits on decades old foundations written in C that can't just be replaced, so that's not a particularly strong argument.
It's noteworthy that Google is financing the effort to bring Rust to the Linux kernel, that Microsoft is also investing in the language and that there are newer, production usage focused operating systems written in Rust. (eg Hubris [1])
If I ommited that first part of the sentence the points made afterwards would remain the same. I did so to indicate that it's not the first time the Rust community suggests that something should be (re-)written in Rust for memory-safety reasons, in a project that has a well-established C-codebase. I'd argue it's the same "Just install Linux" situation that you mention, and that "Linux" may not be the answer.
I understand what the kernel devs are afraid of. Rust needs to demonstrate beyond a shadow of a doubt that it's a good replacement for C in the kernel, or they risk alienating people who don't want to learn another language, and losing those developers to FreeBSD or something.
I'm opposed to this, and it's not because of some idiologic kernel-should-be-pure-c thing. I'm opposed to it because the rust compiler is slow. And the rust compiler is written in rust. Compiling rust is a nightmare if you don't have a high-end PC.
I want to be able to actually compile my software if I wish so. This is becoming increasingly difficult. Rust is adding to the problem.
> Rust should not be used in the Linux kernel until it supports 100% of the architectures supported by Linux itself.
I don't think that's realistic.
If we buy the idea that Rust will allow kernel developers to write more robust, safer, more secure drivers, I think that should override a desire to allow things like driver portability to arches that hardware manufacturers never expected or intended. I would judge that support to be a "nice to have", but it shouldn't block what I consider to be more important concerns (security and robustness).
Regardless, the Rust support here is still considered experimental. I would be surprised if any company adopted it for a Linux driver for at least a year or more. That's plenty of time for people to get esoteric platforms supported in LLVM/Rust if they want to. And it also gives more time for the Rust GCC backend to become more mature and usable, and I believe that will give Rust support for every arch that GCC supports (more or less), which should cover your objection.
(At any rate, LLVM+Rust does currently support PPC, so your specific argument here isn't relevant.)
reply