There's a small set of systems code for which C is a requirement, for various reasons. (There are experimental systems trying to get non-C languages into those areas too, and more power to them.)<p>But today, writing large piles of new C code interacting with untrusted users and data is both painful and irresponsible. Pick a higher-level language, <i>any</i> higher-level language.<p>As far as I can tell, the main thing keeping C in its entrenched position these days isn't performance, or preference; it's C's status as the language of the native platform, that every other decently powerful language can talk to via FFI. If you write a new library in language $FOO, it'll mostly get used by other code in $FOO; if you write a new library in C, many different languages can use it.<p>However, adhering to the C ABI does not require writing code in C. And if enough new libraries start providing a C interface backed by a more powerful language, perhaps we can start establishing careful extensions to the C ABI to better fit higher-level languages (such as standard ways to pass buffers).<p>That's not to say there aren't new classes of systemic bugs in other languages, too. And FFI code, by necessity, lets you write C-like bugs. However, there's no excuse for buffer overflows and integer overflows anymore when any decent high-level language has buffer types and bignums.