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

[oleid]

Seems good, I'll test it soon and if doesn't throw (runtime) errors due to aliased mutability I'll be very happy and report back on it.

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

Another option would be using garbage collected nodes. A few people are experimenting with garbage-collectors-as-a-library crates. From what I heard it can be implemented fairly efficient _due_ to the borrow checker. Here an older, albeit interesting blog post :

https://boats.gitlab.io/blog/post/shifgrethor-i/

[Veto]

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.

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

[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

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

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

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

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

[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

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

[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