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

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

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

[andrei_me]

After reading about Rust in the Kernel, I started thinking "why such hype for Rust?".

IMHO, the biggest factors would be a modern development environment for a system programming language, where cargo takes care of everything.

The "guarantee" that if it compiles, it works.
And the CRUCIAL part is that the compilation error messages explains exactly why the error happened.

So you have this PITA compiler/borrow-checker that carries you to solve the issue with it's super detailed message.

Being performant, deterministic, modern without garbage collector and stuff are a plus

[smitty3268]

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? I don't think so.

It's true that Rust is an opinionated language, that restricts code in a way that lets it automatically check various constraints at compile time.

That's a tradeoff not everyone will appreciate.

But keep in mind that such a tradeoff is pretty standard already, just to a lesser degree. There are various coding standards that OSS projects hold contributions to. You can't just commit any old C code to the linux kernel, it has to be done in a manner which fits in to the project - see https://www.kernel.org/doc/html/v4.1...ing-style.html for example. This is nothing but a restriction on the code you as a developer can write and it can make it more difficult for you to work around and do what you need the code to do. That's done in order to avoid bugs and make the code more maintainable.

Personally, I can't say I love Rust. It does do a lot of interesting things though, and proposals like this deserve real thought and consideration rather than being blindly rejected.

[andyprough]

OK diaper? Wow, we are really getting clever now are we?

Why don't you describe in constructive detail what you have of arguments against using Rust in the kernel, instead of just spewing sh*t?

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

[jacob]

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 ?

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.

[marios]

First of I'm quite sure that Linus will only open this venue for modules and nothing more (drivers seem to be the driving factor here). Secondly people in this thread seem to forget that Linus never rejected C++ "just because", he had explicit objections as to why he didn't find C++ fitting for the kernel (or any other of his projects such as git) and many of those objections does not exist in Rust (such as RAII).

I hope you are right and I am wrong. As long as there is no EXPORT_SYMBOL from rust code, it does not hinder C Kernel developers. Also drivers are kind of independent and if for whatever reason a driver is more Rust friendly it cannot harm if it is written in Rust. However I am not sure that it will not spread in (especially future) core components.
I agree about the reasons he rejected C++, but some other objections might hold true for Rust. For example passing Rust callbacks in a struct looks like it will need some glue, while it is trivial for C++.

[marios]

OK, you are clear on your beliefs, but still, try to keep an open mind.

C is an old language and invented before pervasive multi-threading and internet security was a thing. 30+ years of programming language innovation has revolved around harnessing client-server programming. Systems programming has instead been a slowly evolving niche. It is mind-boggling how little it has changed!

Rust is the first language I have personally seen in 20+ years that really addresses the systems programming space with some sorely needed features. E.g. the really hard-core "safe systems" society (space, avionics, public transportation, automotive etc.) has begrudgingly accepted C/C++ because no viable alternative exists. ADA or the like is too exotic to really make an impact.

However, Rust is the first language in a long time that has seriously addressed the challenge, and Rust is the first language I personally believe will have a chance of superseding/supplementing C/C++ in "real" low-level programming. Linus not rejecting it outright, should be an eye-opener to some of the less independently thinking individuals out there....

However, Rust being an improvement, still has some potential for further improvements, like defining valid ranges of variables. (which ADA already suports...). But "perfection" should not get in the way of progress....

It is true that little has changed in systems programming in the past many years. However the only real advancement in computer technology the past many years is SMT (actually the reason threads are used besides blocking IO).
This could justify the replacement of C. It has already forced some extensions on gcc and clang (i.e. __builtin_atomic_ intrinsics and __thread variables). However any C replacement that I can adopt should have similar syntax to C (it works and there is no need to change it), allow everything that C does (I hate seeing the word "enforce" in a language spec, I like absolute control to the developer) and should not have unnessecary features (i.e. oop, gc).
I have some fundamental disagreements with the dominant programming trends. I strongly reject the idea of safety if it hurts the performance or it restricts the correct programmer's choices (The last thing I would like is my otherwise correct code failing to compile due to safety checks (of which I might be aware but know that in my use case are not harmful)). If the code is for hard-core "safe systems" it is a special case, where security is very high in the priority list, and it is not the common case (in the common case performance is more important). However security is achieved mostly by extensive code reviews and testing, no matter which language you are using.
Of course Rust can supplement C in low level programming, but it cannot supersede it. And it can be a language of choice in only specific cases (i.e. concurrency that cannot be solved efficiently with locks and the gcc intrinsics). I have not yet seen such use case in the Linux Kernel.

In conclusion, I believe that C will not be the de-facto low level programming language for ever. But currently it is the only language that passes full responsibility to the developer. The language that supersedes C should have that property (as well as new keywords that offer functionality that cannot be implemented in libraries). Hardening and bug-catching features can also be added, but that should not be enabled by default (unless if it is for free).

[CommunityMember]

ADA or the like is too exotic to really make an impact.

There was a time (during the 1990's) when ADA was (mostly) required for US DoD applications, except if you requested a variance. Every one of the projects I know of during that period requested (and was granted) a variance because it was a language before its time. Rust has achieved many of the important goals of a higher level systems programming language (especially memory safety), so while it may not be perfect, it is perfect enough.

[marios]

You should have just stopped there and not said anything then. If you don't understand something than don't comment on it.

Amen. It is always good to make informed choices.

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. 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? I don't think so. Do you have to actually write Rust to understand that? Certainly not, you just have to read part of the specs. So if I didn't get lost in the translation (which might happen), I understood enough to be able to have an opinion and comment.

Sorry for using the b-word so many times. I don't like stating my opinion (no matter how strong it is) as a fact. And I didn't make a choice yet. An "informed" choice would be stop caring about Linux because of that. My post was just an informed opinion.

This is the last reply to posts that have nothing to offer but irony and speculative accusations.

References
0: https://blog.rust-lang.org/2015/04/1...ncurrency.html (5 instances of derivatives of enforce, so much freedom to the programmer)
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)
2: posts on this thread