Linux Developers Continue Evaluating The Path To Adding Rust Code To The Kernel

[Stupido]

well, not much addition to the discussion, but what I don't understand is why so much negativism towards Rust...
it is a system language as C & C++, but being newer, builds on top of the knowledge based on usage of C/C++ and improves!
Further more it delivers what's promised, so what is not to like?

But I guess, if one need to bash, then one will bash...

[jacob]

well, not much addition to the discussion, but what I don't understand is why so much negativism towards Rust...
it is a system language as C & C++, but being newer, builds on top of the knowledge based on usage of C/C++ and improves!
Further more it delivers what's promised, so what is not to like?

But I guess, if one need to bash, then one will bash...

I don't think the negativism should be taken too seriously. From what I can tell it's overwhelmingly "baby duck" syndromers who can't tolerate that "their" language is no longer regarded as the mostest bestest. Then there are ignorants, who bash Rust without obviously knowing the first thing about it, and then very, very occasionally, there is someone with an actual, serious and founded grievance. There is a lot of negativity about C++ in the C community more or less for the same reasons; there is a lot of acrimony towards Rust in the dlang community mainly because Rust has succeeded where D hasn't (for a number of reasons), if/when a new language comes up that has learnt from Rust and does the same things better, you can expect many of the less mature Rustaceans to look for reasons to bash it.

[marios]

Here we go again...

I have already stated my opinion about Rust in older threads (the language itself and its community). I find the language a decent choice (I would not make that choice though) for many (maybe most) use cases, but it is not "a better C" (nor worse, just something else). However I hate its community, mainly because of some toxic minorities ("Everything should be written in Rust" guys, guys treating C and C++ as a single language etc).

That being said, in order to have Rust in the Kernel, some red lines should be defined. Also the toxic guys should be kept out at all costs. My thoughts about red lines:
0: C should be the only language needed to work with core Kernel stuff. Anything else should be used only for "leaf" stuff (like a driver for a specific device).
1: There should be zero tolerance to guys proposing stuff like "lets rewrite the scheduler in Rust" or "lets implement the next-gen interrupt framework in Rust".

And a final thought: Linus once said "[...] Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.". Are Rust programmers any better than C++ programmers?

[cl333r]

The unsafe{} stuff is obviously good to isolate potentially unsafe sections, but I think it it might be a bit oversold. For example a section could be both completely safe and completely unsafe depending on the context it is called. For example it is very easy to make Rust OpenGL bindings crash (even though unsafe{} tags are used correctly), you just need to bind and call operations in invalid orders. And the kernel is full of this complexity.

unsafe{} is about Rust, not about making sure the external API you call into somehow magically never crashes. unsafe{} isn't AI, it just lifts some barriers inside Rust.

[kpedersen]

A pure Rust project can easily be built on Windows/Mac/Linux/etc and fetch and build all of its dependencies on its own without issue.

Absolutely but a pure Rust program is ultimately going to be fairly restrictive (until most underlying APIs are rust of course). Just like a C program without 3rd party librarys can't really "connect" to the underlying OS.
If rust could consume C header files and .libs (perhaps within unsafe{} sections), that would also go some way to allow for a more "distributed" dependency system. I say bolt on a tiny C compiler at least for ~50 years.

unsafe{} is about Rust, not about making sure the external API you call into somehow magically never crashes. unsafe{} isn't AI, it just lifts some barriers inside Rust.

Exactly. So I feel some people may be disappointed with the number of memory problems that Rust does ultimately end up solving in the kernel.

[Xavier]

Here we go again...

I have already stated my opinion about Rust in older threads (the language itself and its community). I find the language a decent choice (I would not make that choice though) for many (maybe most) use cases, but it is not "a better C" (nor worse, just something else). However I hate its community, mainly because of some toxic minorities ("Everything should be written in Rust" guys, guys treating C and C++ as a single language etc).

That being said, in order to have Rust in the Kernel, some red lines should be defined. Also the toxic guys should be kept out at all costs. My thoughts about red lines:
0: C should be the only language needed to work with core Kernel stuff. Anything else should be used only for "leaf" stuff (like a driver for a specific device).
1: There should be zero tolerance to guys proposing stuff like "lets rewrite the scheduler in Rust" or "lets implement the next-gen interrupt framework in Rust".

And a final thought: Linus once said "[...] Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.". Are Rust programmers any better than C++ programmers?

Oh yes they are. The compiler literally forces you to write quality code, and has lots of very nice errors messages which explain how to instead of just bluntly refusing to compile.

[mvniekerk86]

I write backend code and embedded code in Rust.
I did Linux kernel dev work ( C ) for 2 years, VOIP stack (C++) for 2 as well. Embedded C for 5 years, Java/Groovy/Kotlin for 12 years, Typescript for 4 years, Rust now for 2,5 years. So take it from where it comes from - with bags of salt.

So - Rust. Smells like Typescript + Kotlin, lots of good ideas shared. Lots of FP way of thinking if you want. Makes writing distributed code tedious at first but fast and safe when you get the flow of things.
The tooling for it in the embedded space is truly amazing. IDE support (Rust Analyzer, Rust Plugin for IntelliJ / CLion) very good (and betters by the month). And Clippy, I love you.

Should Rust be in the kernel space? Absobloodylutely. The amount of footguns in C/C++ abound and I frankly don't have the mental bandwidth to know where I'm shooting myself in the foot the whole time. And these type of buffer overflows/underflows, use after free, use before init can be statically minimized with some linting tools (or MISRA "though shalt not pointer"). But it won't, because people are lazy/forgetful/not skilled enough.
I would even say this - there should be no mission critical piece of software that is not built with Rust.

[jacob]

Here we go again...

I have already stated my opinion about Rust in older threads (the language itself and its community). I find the language a decent choice (I would not make that choice though) for many (maybe most) use cases, but it is not "a better C" (nor worse, just something else). However I hate its community, mainly because of some toxic minorities ("Everything should be written in Rust" guys, guys treating C and C++ as a single language etc).

That being said, in order to have Rust in the Kernel, some red lines should be defined. Also the toxic guys should be kept out at all costs. My thoughts about red lines:
0: C should be the only language needed to work with core Kernel stuff. Anything else should be used only for "leaf" stuff (like a driver for a specific device).
1: There should be zero tolerance to guys proposing stuff like "lets rewrite the scheduler in Rust" or "lets implement the next-gen interrupt framework in Rust".

And a final thought: Linus once said "[...] Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.". Are Rust programmers any better than C++ programmers?

I don't know why there should be "zero tolerance", and even less who are you to determine authoritatively what should be "tolerated". Linus's quote about C++ is typical Linus speak but I would say that - allowing for the obvious exceptions - Rust programmers on the whole are generally better than C programmers; among other reasons (but not only) because the language itself creates a barrier to entry that locks all the "r3alZ pr0gr4mm3rZ" out.

[mdedetrich]

Here we go again...

I have already stated my opinion about Rust in older threads (the language itself and its community). I find the language a decent choice (I would not make that choice though) for many (maybe most) use cases, but it is not "a better C" (nor worse, just something else). However I hate its community, mainly because of some toxic minorities ("Everything should be written in Rust" guys, guys treating C and C++ as a single language etc).

That being said, in order to have Rust in the Kernel, some red lines should be defined. Also the toxic guys should be kept out at all costs. My thoughts about red lines:
0: C should be the only language needed to work with core Kernel stuff. Anything else should be used only for "leaf" stuff (like a driver for a specific device).
1: There should be zero tolerance to guys proposing stuff like "lets rewrite the scheduler in Rust" or "lets implement the next-gen interrupt framework in Rust".

And a final thought: Linus once said "[...] Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.". Are Rust programmers any better than C++ programmers?

Why are you commenting on stuff you don't understand, you are not even a programmer? Your concerns are FUD that has no bearing on reality. If Rust is a better language than C and it fulfills the kernels goals better than C does, they should use it assuming they can integrate it properly into the Kernel build.

Also C++ isn't Rust and Linus had valid reasons for hating C++ (i.e. it has exceptions which doesn't work well in Kernel) but thats not the case with Rust.

[Alexmitter]

As long as there is no way to compile rust with the by-far-better gcc and as long as it relies on cargo, keep that stuff out of the kernel.