The unsafe C in popular language runtimes has hopefully been written or at least reviewed by someone who knew what they were doing, and it presents a relatively controllable interface.

Most people who write code in C are not that good at avoiding memory safety issues. The process is mostly to write some code, run it, then fix it until it doesn't crash immediately anymore.

Have you ever been the first person to run valgrind on a codebase? Lots of uninitialized reads and use-after-free issues will be flagged, because they don't normally crash the program and therefore go undetected without using an additional checker.

It can be fun to watch the error messages flow by, until you realize that now you have to file tickets for all of them. And some people won't even see the problem with those errors that don't crash the program, because potentially exploitable vulnerabilities are not as obviously bad as crashes.

I agree, but this does not mean that some experienced developers can't have some fun creating some tools in C, they may even be less buggy and more performant then some of the other tools written in high level languages.

Btw, I am not a C fan, in fact I think I have no favorite language, I use what I have to for the project

This isn't about cool this is about dangerous. C makes shooting yourself in the foot so easy and efficient it even asks for artillery support.

The time and effort to secure a C program against malicious input is absolutely huge. It would be quicker to write a secure dsl that using raw C. Which brings us back to scripting languages that have that implemented already as a library you load to run your requests through.

C lovers are downvoting you but you're entirely right.