Originally posted by cl333r
View Post
Announcement
Collapse
No announcement yet.
Linus Torvalds' Initial Comment On Rust Code Prospects Within The Linux Kernel
Collapse
X
-
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)...
- Likes 2
Comment
-
Originally posted by cl333r View Post
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.
I guess the famous Linus quote about C++ programmers does hold true then.
- Likes 2
Comment
-
Originally posted by oleid View Post
Sure you can mutate a node; there is a getter for a mutable reference to the data of a node.
Comment
-
Originally posted by marios View PostLinus 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)...
- Likes 7
Comment
-
Originally posted by marios View PostLinus 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".
- Likes 11
Comment
-
Originally posted by marios View PostI 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.
- Likes 6
Comment
-
Originally posted by p91paul View Post
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.
Comment
Comment