> You are committing the perfect solution fallacy.
Rust is also not a perfect solution. You have to prove that the benefits of solving for the bugs Rust can prevent outweighs the downsides of asking a bunch of C experts who are currently developing kernel subsystems in C to stop what they are doing and rewrite millions of lines in C in a language that has very low marketshare in the space and is far, far more complex in terms of abstracting over assembly. People write systems software in C not because they have a fetish for bugs, but because we do in fact still have to stay close to the hardware and not get lost in a minefield of abstractions.
C is successful despite all the bugs, not because of it. If there are newer methodologies that solve bugs, one should use them, rather than sticking to their "tried and true way" while suffering through segmentation faults. Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts. They also don't have to rewrite millions of lines, they can incrementally improve the codebase.
All this to say that even in your above comment you're still committing the perfect solution fallacy. You are still talking about how Rust is not perfect even though no one said it was, and you mention trying to convince all of those C experts to rewrite millions of lines of code when, again, no one said they have to do.
> Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts.
The C experts I was referring to are the subsystem maintainers and none of them are currently working on migrating to Rust AFAIK. So far the work in Linux with Rust has been a few driver rewrites. Keep in mind that there are subsystems like eBPF, io_uring, etc. that are under rapid development and are completely in C. I think if you really believe that kernel code should be written in Rust, you should start submitting patches instead of telling people that they have some sort of moral obligation to use Rust when you aren't the one that has to do any of the work.
You aren't being charitable. Please stop fussing it's rather immature. People have addressed your points, please actually respond to theirs.
It's not helpful to keep saying "look there still some people writing C" and use that as an argument for how C has somehow solved the problem where C programers regardless of how good they are ultimately write bugs that lead to takeover of the program counter. Rust makes the world better. If you don't want to pay the semantic price of that then fine, but it means you're okay with still writing horrible bugs. Some of us aren't. I promise Rust's semantics are better than C++ even though Rust has its rough edges and could be improved.
What would be helpful to your cause is to mention the examples of people starting to add tooling to C to solve problems people are solving with Rust, but without the semantic price of Rust.
Rust is also not a perfect solution. You have to prove that the benefits of solving for the bugs Rust can prevent outweighs the downsides of asking a bunch of C experts who are currently developing kernel subsystems in C to stop what they are doing and rewrite millions of lines in C in a language that has very low marketshare in the space and is far, far more complex in terms of abstracting over assembly. People write systems software in C not because they have a fetish for bugs, but because we do in fact still have to stay close to the hardware and not get lost in a minefield of abstractions.