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

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

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

[andyprough]

trolling the internet

OK boomer.

[cl333r]

How about indextree? They are using an arena for the nodes (my gut feeling agrees). I never used it, but judging by the tests, you can remove parent while you also hold references to the children.

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.

[cl333r]

Aww, this is just cute. We will all learn to be nuanced as we grow older....

Context is key. I meant undefined behavior in the context of this issue.

[cl333r]

Then use unsafe. It's an option for a reason.

Unsafe doesn't solve this issue in any way. Just because it's unsafe doesn't mean you can get rid of the borrow checker, a quote from [1]:

It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked.

[1] https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

[atmartens]

I'd actually like Rust to replace C but not C++ because Rust simply doesn't cut it. Something as simple as a dynamic mutable tree which would take a minute to implement in C++, is next to impossible in Rust - I've spent 2 months and failed, because the naive online examples don't work IRL because of the borrow checker which makes to whole thing a total mess, to this day I haven't seen a viable Rust solution, Mozilla's own Rust code from WebRender uses a JavaScript backend for this.

Then use unsafe. It's an option for a reason.

[oleid]

There's no undefined behavior in C++, you just have to not forget to properly clean up resources in your object's destructor which is one of the very first things you learn in C++. It's easy, effective and simple.

My mistake, I thought you were talking about trouble with RefCell due to concurrent access. Hence, I mentioned undefined behavior.

[oleid]

You can't create an acceptable implementation with raw pointers, I tried and failed (but don't recall exactly why because it was like 12-18 months ago), if you can provide a viable/usable (not demo) solution with raw pointers I'd be more than happy!

How about indextree? They are using an arena for the nodes (my gut feeling agrees). I never used it, but judging by the tests, you can remove parent while you also hold references to the children.

[cl333r]

True, RefCell should only be used as last resort. But if it doesn't help in your example case, how do you prevent undefined behaviour in similar C++ code?

There's no undefined behavior in C++, you just have to not forget to properly clean up resources in your object's destructor which is one of the very first things you learn in C++. It's easy, effective and simple.