Yes, but the arguments why we need to replace C code with Rust was not that it is better by "helping the programmer check themselves" but that we need to switch to memory-safe languages because it "removes a whole class of error". (of course, nobody has ever said this, this must be my imagination)
Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow.
> Yes, but the arguments why we need to replace C code with Rust was not that it is better by "helping the programmer check themselves" but that we need to switch to memory-safe languages because it "removes a whole class of error". (of course, nobody has ever said this, this must be my imagination)
Rust being memory safe is a way in which it helps the programmer check themselves. Absolute statements like "removes a whole class of error" are dangerous, there are always caveats. Rust seems to be doing a heck of a good job at this particular task, even if it sometimes falls short.
> Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow.
The kernel has been under the development for north of 30 years at this point. These ways to improve safety in C don't seem to be materialising.
Finally, there are also a lot of ways to improve memory safety in C which are not nowhere exhausted even in the kernel. As long as this is not even the case, I find the argument that there is "too little support for the programmer" quite hollow.