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

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

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

[Zan Lynx]

Some of you seem to find Rust overly restrictive.

Well, I've been programming in C and C++ since I was a teenager. That's 30 years now. So I have experience. And other experienced C++ developers I work with agree with me: Rust is great.

That's because as you get more experience with writing C++ and importantly, maintaining C++ code that other people wrote, you come to realize that no one can keep everything straight.

Experienced C++ developers already use linters and static analyzers and max-level compiler warnings because IT IS SO EASY TO SCREW UP. And your mistakes will often work and pass all the tests and only break with unrelated changes made by another developer next year.

Rust is a static analyzer built into the language itself. It does its best to prevent you from writing code that it cannot analyze.

[qarium]

Ok, but how is the code written in Rust compared to C at the performance level ?
Is Rust adding any safety checks at runtime that makes the code slower based on the assumption that the code is badly written ?

i read the wikipedia article on rust and it tells that it only use performance neutral abstraction.
means zero performance penalty abstraction.
anything what would cause a performance penalty is rejected in rust.

means it has the same performance than C

[qarium]

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.

they only accept zero performance penalties compared to C... the stuff what happens in compiler time is not a factor of what makes it slow after it had compiled.

[Scellow]

bloated linux incoming, oh wait, it is already

[Royi]

What about Zig as an alternative to C? I find it to be a real contender.

[cl333r]

Looking forward to hear back! Sadly I couldn't test it myself.

Well so far it's clear that you have to use typical ugly bloated Rust hacks (Rc<RefCell>>, cloning) because you have to pass in a reference to Arena at every call to most methods of this library hence each of my nodes has to have a reference to it to be able to dynamically deal with the tree.

And so it seems to have a similar Rc<RefCell> problem as my previous solution because you have to pass in a reference to Arena in many cases, so you need it to be Rc<>, and because you'll also need it mutable - RefCell.

I don't know if it will eventually panic at runtime cause I'm just testing on a little test project, I expect it to start panicking when there's a lot more code which at some point violates the aliased mutability rule at runtime. I'll report later if this happens.

Rust seems very nice in those little Rust tutorial snippets but when you want to use it IRL it's a completely different story. Like ESR said:

In my last blog post I expressed my severe disappointment with the gap between the Rust language in theory (as I had read about it) and the Rust language in practice, as I encountered it when I actually tried to write something in it.

[1]

[1] http://esr.ibiblio.org/?p=7303

[oleid]

Well so far it's clear that you have to use typical ugly bloated Rust hacks (Rc<RefCell>>, cloning) because you have to pass in a reference to Arena at every call to most methods of this library hence each of my nodes has to have a reference to it to be able to dynamically deal with the tree.

It is quite possible you're doing something in a very unidiomatic way. Which then feels strange. I had that quite a few times for new code. After design changes things looked a lot better and were faster.

Do you happen to have the code uploaded somewhere public ?

Rust seems very nice in those little Rust tutorial snippets but when you want to use it IRL it's a completely different story. Like ESR said:

A little later he said :

I understand now that I tested the language too soon. My use case – foundational network infrastructure with planning horizons on a decadal scale – needs stability guarantees that Rust is not yet equipped to give. But I’m somewhat more optimistic about Rust’s odds of maturing into a fully production-quality tool than I was.

That was about three years ago. The crates he was missing are quite stable by now.

[cl333r]

Rust is equipped even worse to deal with my code - all of it is around managing a dom tree structure - which a LibreOffice .ods file is all about:
you have an office:body which has office:spreadsheet etc etc until you get to table:table-cell and almost all of them have parents, children, values and styles which might be shared across multiple nodes. To create a convenient api each of these types of nodes has to be a class and needs to call into other classes and modify them at any place in code. And so each of them has to have a &mut Arena instance - it's impossible to have it unless you wrap it in Rc<RefCell<>>. I mean Rc<RefCell> works if your code is reasonably small, but once it gets sophisticated (an .ods file needs like 60 types of classes that must interact/modify each other) - you can't design around not violating RefCell's aliased mutability rule at some point at runtime. I guess that's one of the reasons why Mozilla's rust WebRender's dom structure is gc managed by JavaScript.