It's well established that writing safe and sound C code is an impossible feat (even OpenSSH had a number of memory corruption bugs in the past). Some people are better at it than others, yes.

That doesn't mean we should drop everything, throw away our C code and rewrite ot in Rust, but the issue is real.

> It's well established that writing safe and sound C code is an impossible feat

You make it sound like this is somehow particular to C.

I hold the opinion that when you're using such an open definition of "sound and safe" (e.g. code will never do anything that could reasonably called a "bug" from a user's perspective) it is impossible to write "safe and sound" code in any programming language.

But that is not really a problem with the language, but with the definition of the term "sound and safe".

If you use a more constrained definition of "sound and safe"; one that would actually allow you to write "correct" code in a language, then C code can just be as sound and safe as rust code or Coq. It really just depends on your definitions.

In a way I agree with what I believe the grandparent tried to say; one thing that consistently rubs me about the Rust community is that they oftem seem to be using a very constrained definition of "safe" when advertising that rust is a "safe language", but a very open definition of safe when proclaiming that more or less every other systems language is "unsafe". That may be true using their definition of safe, but is a bit of dirty PR trick.

> ... throw away our C code and rewrite ot (sic) in Rust...

well, to me at least, it seems a bit premature to compare the two languages at this juncture. rust is quite nascent, and doesn't have enough data points (imho) to make an objective comparison.

perhaps, when we have large code-bases available in rust doing safety+security critical applications (which might then be worthy targets) it might make more sense.

Did you notice the smiley ";-)" ? It indicated irony.