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

[goTouch]

What I found out was that it gives less power to the developers than C (most restrictions can be worked around, but it is considered harmful). It actually makes your life harder if you know what you are doing, just because someone who doesn't know what they are doing can screw up if allowed to.

Apply similar thinking on C replacing assembly, you can see assembly gives more power, performance and freedom of using registers the way you want to developers than C. However C wins for much easier development. Nowadays the importance to let most developers able to write safe code more easily could overweight the inconvenience of Rust. It is fairly reasonable to say Rust has its advantage over C, thought not in every aspect.

There is no perfect language that is powerful, flexible and yet doesn't let you shoot on your own foot, if you actually want the freedom to shoot on your own foot.

[oleid]

After reading about Rust in the Kernel, I started thinking "why such hype for Rust?". I searched the internet and found out about the safety stuff. I then searched about the "safety stuff" and found out that it can be more harm than good.

Harm to whom? Personally, I'm happy that MISRA exists and that it is used in safety critical cases. If you mean: harm to developer time- I guess that is a small price to pay if lifes are saved.

I should have stopped there and not read anything then. If you find something useless at a first glance than don't try to think more on it. However I did not stop there. I tried to understand more about the uses of Rust and potential benefits. What I found out was that it gives less power to the developers than C (most restrictions can be worked around, but it is considered harmful). It actually makes your life harder if you know what you are doing, just because someone who doesn't know what they are doing can screw up if allowed to. Did I get it wrong?

Yes, people who think they know what they are doing and think they are infailible are usually wrong. And even if _you_ managed to get it all right in the first iteration, consider this:

• usually, you don't work allone. can the same be said about your coworkers?
• how about having to refacture the whole pile of code three months later? would you still remember all the corner cases you thought about when writing the code? Could there be new corner cases due to the new architecture?

An "informed" choice would be stop caring about Linux because of that. My post was just an informed opinion.

But why? Most people will never notice what's inside the kernel.

1: https://drewdevault.com/2019/03/25/R...ment.html#fn:1 (don't completely agree with him, but it looks like I am not alone in beliving that Rust cannot replace C)

Number of features per year taken from release notes is not really a good measure, especially if you use it to prove that the youngest gets most features.


The only real point he has is the lack of specs and other implementations. The former is being worked on (AFAIR a subset of rust for safety critical stuff) and there are humble beginnings of creating a gcc frontend. I'd very much like it to succeed.

If rust will ever be used in the kernel, I'm positive those issues will be worked on even harder.

[oleid]

I'd give you my list, but I couldn't explain it half as well as this old Bell Labs scientist: https://www.youtube.com/watch?v=QTiAWZ1YfzI

Hilarious! Thanks for sharing I agree, we should all use lisp. Maybe then we could run emacs extensions in the kernel?

[mdedetrich]

In synthetic benchmarks, Rust is usually more or less on par with C (sometimes worse, sometimes better), however meaningless that may be. Off the top of my mind, it only uses runtime checks in three cases: array bounds checks (can be disabled, the compiler knows how to optimise it away in various cases and besides for 99% of the time it's not really a thing in idiomatic Rust code), RefCells (runtime borrow checking) and .unwrap() calls (unsafe non-checking versions are available, and the same checks should be performed manually in well-written C anyway). In practice, it's about the same as good C code. It also has some inherent performance advantages compared to C, such as much better pointer aliasing and escape analysis that allow it to perform some optimisations that would not be safe to do in C. IMHO the current main performance penalty that can happen in Rust are unnecessary memcpy() (or equivalent) calls, because it tends to always build its objects on the stack and then copy them onto the heap. There are some workarounds available though and it's being worked on. On the other hand, it also seems to me that the compiler does a better job than C at autovectoring.

In practice, if you see some real performance difference between C and equivalent idiomatic Rust, it's likely to reflect mainly a difference between Rust's LLVM back-end and GCC.

Some guy did a comparison of C and Rust projects that achieve the same goal and he found out that the only reason Rust is slower is because of bounds checking (which is on by default in Rust as it should be because a huge amount of security issues are due to not having bounds checking). If you turn off bounds checking in Rust its actually faster than many equivalent C programs.

This makes sense when you consider that Rust does things by default that improve performance which C doesn't, i.e. Rust automatically pads structs so that they are more cache friendly for the underlying architecture. In C you have to do this manually and most people don't.

[oleid]

This makes sense when you consider that Rust does things by default that improve performance which C doesn't, i.e. Rust automatically pads structs so that they are more cache friendly for the underlying architecture. In C you have to do this manually and most people don't.

To be fair, rust can only do that since they guarantee a certain memory layout of a struct. Rust doesn't do that (unless you ask it to). But actually, I think this is a good thing. Consider the Option data type in rust. For certain types, e.g. some enum or a NonNullPointer, rust automagically does value stealing, i.e. Option<NonZeroUsize> will only use the size of an Usize, encoding the None case to Zero.

[cyring]

Don't do that

[Soul_keeper]

This is a horrible idea. Please leave rust out of the kernel.

[marios]

This is my last post on this subject.

I can understand people willing to sacrifice control and/or performance in the sake of partial security. I prefer the other way, more thorough and extensive code reviews and tests (which is always necessary, even in the strictest language in the universe). Relying on the compiler to find security vulns or potential bugs will just create a false sense of security. The chance of being lucky and have the compiler catch a bug that would get through is a nice thing, but as long it is not bullet proof, it is just a bonus feature.

The coding style requirements of various projects (including the Linux Kernel) are not nearly as restrictive as "* safe" languages. Most of the time you can make any code compliant using sed. The same is not true for Rust compiler errors.

Having higher chances that your code works, provided it compiles is always good. Looking for work-arounds to make your working code compile is always bad. You can choose to have both or neither. I choose neither.

Using a restrictive language is not the only way to avoid bad code. Training the developers to avoid potentially harmful practices, unless adequately justified is an alternative.
Also using a restrictive language does not remind corner cases better than comments and documentation.

"Rust replacing C" is not even close to "C replacing assembly". Firstly, coding in assembly means rewriting and reoptimizing you code for every μarch. The same is not true for C. Also another major problem for coding in assembly is it not being natural (cannot use variable names and stuff like that). I don't see Rust beeing beeing more "natural" than C. Finally writing more efficient code in assembly than in C is impossible, unless you are better than a computer at solving NP-complete problems. C lack of "* safety" is no problem for me.

I fundamentally disagree with the "safety first" approach. This disagreement cannot be solved in forum. I will just tell my opinion about a model I would find acceptable for a system language that can replace C:
0. Any hardening and debugging features that affect runtime performance should be switchable as compiler flags.
1. Static checks (like Rusts "borrow checker") should be run independently to the compiler. It could work as "you might shoot your leg by doing this, however you can ignore it and if you really shoot your foot you have been warned".
2. Be at least as flexible as C and at least as performant as C (when writing performance oriented code).
3. It should not be verbose. A C like syntax looks just right. Adding useless keywords like "let" cannot be good.
4. It can have some extra features, as long as It does not become C++. It should natively include stuff that were implemented as gcc intrinsics in C (or some other non-C way).

[daniel_mazurkiewicz]

Well, linux isn't only desktops or servers or phones, nowadays it works even in coffee machines. There is a zillion of hardware platforms that Rust even didn't dream yet to target so if any of you have close connection to Linus, pass him a greetings and kindly ask to say NO to any of such an ideas.

I realize that IT industry is nowadays like a fashion industry and people falls into a fashionable trends, so if there will be a strong force and momentum to get rust into kernel, let it be only through some transpiller that targets C, something like this: https://github.com/thepowersgang/mrustc

[Almindor]

viable c replacement has to understand c headers

Runtime checks are limited to mostly debug builds (overflow being one exception IIRC).

Performance wise Rust is on-par with C in most cases and once LLVM fix their damn aliasing bug, it will outperform C in some cases.