I wish they would start creating a new kernel from scratch
in Rust.
It is needed and will be more cohesive and take more advantage of
the new language than stuffing it into Linux.
There will be a lot to learn from it though.
It will test the interop and cohabitation of Rust and C.
Lessons learned will be unbelievably valuable for other efforts to
mix and match them.
I have to say, I feel a bit “dirty” carrying so much unused and legacy code around with Linux, so I like people trying to reinvent the wheel just for the pleasure of a fresh start. For the aesthetics. Even if it’s merely a fantasy and not replacing anything soon, realistically. They are also keeping OS development accessible to new generations of geeks. The unfriendliness of C, the gigantic codebase and seemingly distinct culture make the Linux kernel quite off putting, filtering possible engagement by unfortunate parameters IMO. Novel OS development in Rust takes away at least some of those barriers and some of the gained knowledge may be applicable with the Linux kernel later.
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'd like to put forward a controversial opinion, if I may: I do not think adding Rust to the Linux kernel is a good idea; and I suspect this project will struggle as soon as the financial backing is removed.
First, a bit of background: I am mainly a C++ and C# user space developer, so presumably despised by all camps involved. Secondly, I have no experience of kernel development whatsoever. Thus, take my comments with a large grain of salt.
My argument is as follows. Every decision you make on a software project is akin to an intersection on sets of programmers. When you choose C, you take a small slice on all possible programmers; when you choose kernel development, you take a slice on the set of competent C programmers, and so on. The intersection of programmers that are competent in Rust _and_ in C _and_ in kernel development - including the interaction between the two languages, at a very low-level (because kernel-space is special) - must be astonishingly small. And herein lies an important problem. Let us posit that the kernel does gain a significant amount of code in Rust; the interaction between these two languages (read: friction) will become significant. Either the Rust people will break things for the C people, or the C people will break things for the Rust people. Those who like C but not Rust - presumably a large subset of the Linux C programmers, else one would assume they would be developing a kernel in Rust - will become alienated. Similarly, those who like Rust will be forced to spend a lot of time doing non-rusty things just to get Rust to work, and they too will not enjoy the experience. Finally, many of the sweeping code clean-ups the kernel experiences periodically will apply differently to Rust, if they apply at all - meaning it will be a second class citizen, barring some major investment to compensate for this.
In the end, I do not think the problems will come from the languages involved per se but due to the complex technical and especially social interactions that this will create.
It is, however, an extremely interesting project technically and I suspect that Rust (and maybe even the kernel) will benefit from it, though not necessarily in ways one would expect. As far as research goes, it is pretty cool.
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.
I think this is a bad idea or at least far too soon.
In my opinion the Rust language and eco system is not yet at
the stability of C.
I feel certain that mixing two different languages inside the kernel
will give all new and challenging errors to debug.
Also it is the fallacy of sunken cost.
So much work has gone into the Linux kernel, but efforts should be made
to replace it.
What I would like to see is a project to create a new and modern kernel,
taking a lot of what has been learned by the "prototype" Linux kernel and
create something new and better.
It would also be free to take full advantage of the language improvements
between Rust and C.
Sure it would take a lot of time, but I think it is time well invested, instead
of slowing trying to port the current Linux kernel to Rust.
Go ahead and rewrite 30+ million lines of C code in Rust, LMAO.
It's not going to happen, Rust support is being added for new code, not specifically to rewrite the kernel.
Really unexpected, that the first kernel feature written in Rust is such a huge driver, I would've expected something much smaller first. The reasoning for the change is well laid out imo. I'm looking forward to this, especially since it looks like performance will be almost on par with the C version which will give Rust a good outlook.
I'm curious why you seem to think that Rust makes new OS architectures possible. Rust is a language, and languages have nothing to do with OSes. Do you mean new kernel structures?
From my perspective, Rust does not belong in kernel. But meanwhile Linux kernel does not belong in modern infrastructure. Until the day a mature kernel-oriented language and an established kernel showed themselves, Frankenstein experiments will continue to trump both parties.
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.
Does anyone have context on how Rust will make its way into the kernel? I'd imagine the initial motions will be pointed towards allowing Rust code to build alongside the existing C codebase without friction. Is the intent to incrementally introduce new modules and subsystems in Rust after that? Is there an end goal to rewrite everything in Rust?
I love the idea of more rust into linux because I think it will make the code more secure and easier to contribute/modify. I am scared of any potential problems an immature ecosystem (relative to C ofcourse, don't jump the gun) can cause to this life-depending tool called the linux kernel. I am glad linus is open to it but careful. Balanced approach
Edit: I am also a proponent of careful re-writes of very old userspace utilities (eg: ping) accompanied by very rigorous tests to ensure there aren't any behavour changes
It is needed and will be more cohesive and take more advantage of the new language than stuffing it into Linux.
There will be a lot to learn from it though. It will test the interop and cohabitation of Rust and C. Lessons learned will be unbelievably valuable for other efforts to mix and match them.
reply