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

[oleid]

This is my last post on this subject.

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.

Rust's bound checks can be disabled. This is about the only thing which should affect runtime performance. Apart from that, it can really be memory safe _and_ fast.

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

As said before, writing the code is often not the big issue. Keeping it correct over time is.

You don't skip writing tests, only it is annoying and holds you back. Or even worse: ignore tests if they signal you've shot into your foot?

2. Be at least as flexible as C and at least as performant as C (when writing performance oriented code).

Is C really that flexible? I mean, it is not very expressive. The macros you have at hand are poor. You have no support for interfaces (or Traits in rust-speak). There is no support for templates. No support for iterators. I could go on...

Granted, the compiler will let you write stuff, which would not compile in rust. But from my experience, if you've to "fight the borrow checker" too much (as in: you've to do strange stuff that it compiles), you should reconsider your architecture anyway. And this is often a good thing. Better to learn that something is bullshit upfront than in production. It might take you a little longer to get something working to play with, but you save tears in the long run.

3. It should not be verbose. A C like syntax looks just right. Adding useless keywords like "let" cannot be good.

This is about personal taste. Personally, I find

const int32 a = 4;

more verbose than

let a = 4i32;

And

void main() {
    const int a[3] = {123, 456, 789};
    const int N = sizeof(a)/sizeof(int);
    for (int i=0; i < N; i++)
    {
        printf("%i: %i", i, a[i]);
    }
}

to be more verbose than

fn main() {
    let a = [123, 456, 789];
    for (i, v) in a.iter().enumerate()
    {
        println!("{}: {}", i, v);
    }
}

- but clearly, this is only a matter of taste.

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

Then the big question is: what is an extra feature, what is not. You can always forbid certain features for your project, if you don't like them.

[Almindor]

This is my last post on this subject.

...

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.

I can appreciate this, and generally agree at least in the embedded/kernel space.

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

Disagree, people will ignore and shoot themselves in the foot. You do have unsafe for this tho.

2. Be at least as flexible as C and at least as performant as C (when writing performance oriented code).

Rust already is as flexible as C (just use unsafe if you really need to). It is about the same performance as C and it has potential to consistently outperform C once aliasing rules are fixed in LLVM.

3. It should not be verbose. A C like syntax looks just right. Adding useless keywords like "let" cannot be good.

That's subjective, I think C is fine, but then again I like Pascal syntax too.

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

Indeed but I disagree with the gcc intrinsics. Those are hacks and should be removed.

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

[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

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

[Soul_keeper]

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

[cyring]

Don't do that

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

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

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?