> I'm only claiming that to be effective at C you must understand computer architecture well.

You still have this problem: We have lots and lots of buggy C code in critical software.

If your claim is to be effective at C you must understand computer architecture well, but unfortunately few are effective at C, because few really understand computer architecture well, and unfortunately we have lots of buggy C code as a result, I'm not sure where you are after that?

Is it possible C hasn't worked as the gate you say it has worked as?

> to be effective at C you must understand computer architecture well.

So long as we are here, I would also quibble with this claim. Knowing loads about C, or more specifically how to prevent C memory safety issues, is perhaps not the best indication one knows anything about network security or cryptography. In fact, we know the reverse is the case. There are plenty of OpenSSL devs who are domain experts in cryptography, who have not proven themselves well adapted to deal with C memory safety issues. Something like Rust sounds perfect for such a use case?

> Right, because the only way to fix problems is to rewrite? Typical inexperienced programmer attitude.

What do you think writing a borrow checker for C would entail?! Do I think it would be a tremendous effort, with little gained? Oh yeah. Do I think we should just use Rust for new software? Yep, because why wait for this C borrow checker? I just don't get it. I think saying "Just use Rust" makes me sensible. "Let's build a borrow checker for C!" is tilting at windmills.

I've programmed in C for 20 years and Rust for 3 and I'm a _much_ better programmer after using Rust. From experience, Rust doesn't make you a lazy programmer, it makes you a much better programmer.