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

[oleid]

It seems they worked around and implemented the adding/removing of children but not of allowing to call mutable methods of children/parents because you can't lift the borrow checker's ban on aliased mutability.

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

[marios]

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)...

[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.

[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.

[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.

[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).

[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.

[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.

[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).

[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 ...