If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.
If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
If R4L authors want to use Rust so badly, then still:
Maintain your own tree! Let’s see how simple and clean these interfaces are over the longer haul.
They will get mainlined if they are technically superior.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.