Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel

[Veto]

Linus should have just rejected it, just like he has rejected lots of other proposals.
I admit I have never used Rust, but I have read about its major "benefits". I believe that you cannot ensure type/memory/thread safety without paying a huge price.

OK, you are clear on your beliefs, but still, try to keep an open mind.

C is an old language and invented before pervasive multi-threading and internet security was a thing. 30+ years of programming language innovation has revolved around harnessing client-server programming. Systems programming has instead been a slowly evolving niche. It is mind-boggling how little it has changed!

Rust is the first language I have personally seen in 20+ years that really addresses the systems programming space with some sorely needed features. E.g. the really hard-core "safe systems" society (space, avionics, public transportation, automotive etc.) has begrudgingly accepted C/C++ because no viable alternative exists. ADA or the like is too exotic to really make an impact.

However, Rust is the first language in a long time that has seriously addressed the challenge, and Rust is the first language I personally believe will have a chance of superseding/supplementing C/C++ in "real" low-level programming. Linus not rejecting it outright, should be an eye-opener to some of the less independently thinking individuals out there....

However, Rust being an improvement, still has some potential for further improvements, like defining valid ranges of variables. (which ADA already suports...). But "perfection" should not get in the way of progress....

[oleid]

Seems good, I'll test it soon and if doesn't throw (runtime) errors due to aliased mutability I'll be very happy and report back on it.

Looking forward to hear back! Sadly I couldn't test it myself.

Another option would be using garbage collected nodes. A few people are experimenting with garbage-collectors-as-a-library crates. From what I heard it can be implemented fairly efficient _due_ to the borrow checker. Here an older, albeit interesting blog post :

https://boats.gitlab.io/blog/post/shifgrethor-i/

[xorbe]

As long as it also supports the rust-lisp package, and then I can natively boot into Emacs, and then load emacs-systemd.el ...

[CommunityMember]

I don't see why that's an issue. Once some non optional part of Linux gets written in Rust, you'll need a rust compiler to build it. That required compiler might not be under the GNU Compiler Collection umbrella.

There have been some (that obviously have a not so subtle ulterior motive) that suggest that allowing rust code in the kernel will kick some butt in the gcc community to get moving and agree to merge a rust frontend in order to stay relevant to (especially) the Linux kernel (and there are arguably some slopes that could end up being too slippery to easily recover from).

[oleid]

I admit I have never used Rust [...]

I believe that you cannot ensure type/memory/thread safety without paying a huge price. [...]

I believe Rust can never replace C [...]

I believe Linux kernel developers should not be bound by Rust's safety rules. [...]

I do believe that its use should not be endorsed in the kernel [...]

I believe more than few people will share my taste.

Amen. It is always good to make informed choices.

[mdedetrich]

Linus should have just rejected it, just like he has rejected lots of other proposals.
I admit I have never used Rust, but I have read about its major "benefits".

You should have just stopped there and not said anything then. If you don't understand something than don't comment on it.

[F.Ultra]

Linus should have just rejected it, just like he has rejected lots of other proposals.
I admit I have never used Rust, but I have read about its major "benefits". I believe that you cannot ensure type/memory/thread safety without paying a huge price.
The price might include performance penalties and crippling the programmers' freedom on how to code.
I believe Rust can never replace C because, in the name of making wrong code fail to compile, correct code might also fail to compile. It prevents you from doing you best in the name of preventing you from doing your worst.
I believe Linux kernel developers should not be bound by Rust's safety rules. They should not be treated as losers. For sure bugs happen, some of which can be prevented by using a restrictive language, but I prefer the way things are now.
This does not necessarily mean that Rust should be banned from the universe. However I do believe that its use should not be endorsed in the kernel because:
0. It does not guarantee code correctness, so there is no qualitative leap here. It just decreases the odds that the code is bad. Such gain is not convincing.
1. A module written in Rust might be no problem for the kernel. However if something major (i.e. a scheduler) or something that exports symbols is written in Rust, it will add lots of complexity and rust will no longer be an optional dependency. There is no guarantee (quite the opposite) that Rust will be used only for non-core stuff.
2. If Rust is added to the kernel languages (C and lots of assemblies are already in the kernel) anyone who codes in the kernel needs to understand Rust as well. This will be a major problem for people who have no interest in Rust. On the other hand, people who have no interest in C will still have to understand C, in order to code in the kernel.
3. (Just a matter of personal taste) While reading the above post, I had a hard time preventing my eyes from exploding when encountering Rust syntax. I cannot stand reading it in the kernel. I believe more than few people will share my taste.

PS. What happened to Linus? 10 years ago, he would have given a good rejection to such proposal (and a good laugh to anyone who reads Linus's quotes)...

First of I'm quite sure that Linus will only open this venue for modules and nothing more (drivers seem to be the driving factor here). Secondly people in this thread seem to forget that Linus never rejected C++ "just because", he had explicit objections as to why he didn't find C++ fitting for the kernel (or any other of his projects such as git) and many of those objections does not exist in Rust (such as RAII).

[cl333r]

Sure you can mutate a node; there is a getter for a mutable reference to the data of a node.

Seems good, I'll test it soon and if doesn't throw (runtime) errors due to aliased mutability I'll be very happy and report back on it.

[cl333r]

Only if you try to mutate the same data at the same time from multiple places...

No, aliased mutability isn't exactly that, it's a much broader rule.

[Pajn]

RefCell doesn't fix much because it doesn't cancel the borrow checker, it's just that it moves from being detected at compile time to runtime, so your problem moves from not compiling to randomly crashing because of the runtime error.

Only if you try to mutate the same data at the same rime from multiple places...
I guess the famous Linus quote about C++ programmers does hold true then.