The C code at most large companies I've worked at has been total crap. My high school CS teacher probably wouldn't have accepted the code from my last company even to mark it since it lacked descriptions of the projects and comments. This isn't something that can be fixed with a new language. C at least won't compile if someone is an idiot so usually about 25% of the C devs are worth the air they breath which is far better than the JavaScript devs. The issue is managers wanting steady, easy to measure progress but not wanting to invest any time in understanding the project. Concurrency issues are solved by architecting the code correctly but if you only measure progress by how fast a jira ticket is solved by an engineer who has been on the project for 2 hours then you get people manipulation buffers in interrupts as well as in the single thread of the application. If there are no comments about what a buffer is then yes, pointers to it will be miss used. C code runs fast, has a small image size, I can bash memory directly, that's the point. If you don't plan your code, if the logic is never written out then it doesn't matter what the language is, your code will do the wrong thing. Memory bugs are just easier to find but making the language convoluted to stop stupidity just makes it harder to find stupid programmers and even harder to find incorrect logic. Rust is bad coders solving the wrong problems. If, as a manager, your devs can't simplify the architecture enough to explain how the code will meet the functional requirements then either the devs suck or you shouldn't be a manager..... and if you don't have a clear functional requirement, even if you know it will change next week, then you as a manager aren't doing your job.