Someone with say 10-20 years of experience in a language will write a more secure program then someone just started in any language ... And even if you program in a "safe" language, you still make bugs, and all those bugs passed the compiler/parser, so your language obviously didn't help you there. There are a lot of code written in C in the wild, witch means there are also a lot of bad code.
There are business logic bugs, and there are memory corruption bugs. One of those leads to RCEs a lot more often than the other. One of those is a lot easier for the compiler to prevent than the other.
Yes, but there are ways to prevent most memory corruption bugs, even, if you're using an OS with a non-terrible malloc implementation. The gnu malloc that most people know is a terrible antiquity that should have been replaced decades ago -- mallocs like OpenBSD's make a lot of memory corruption bugs a lot harder to exploit.
Someone who capably sets out to write their web application back-end in C most likely is aware of any security issues. If they exist in the finished product, their presence is going to be due to laziness, not ignorance.
You don't get points for internet pedantry. Especially when it should be obvious that you're choosing to use a definition of "significant" that doesn't match what I was using in my comment.
virtually,
adverb
[ as submodifier ] nearly; almost: the disease destroyed virtually all the vineyards in Orange County | the college became virtually bankrupt.
Not the person you replied to, but I'm actually quite conflicted on this count. I enjoy C, both aesthetically and for its performance, yet I care a lot about security, so I feel obligated to avoid C for anything important. I'm a big fan of Rust, but it's nowhere near replicating what I like about C.
