> Which argues that maybe language choice just doesn't matter that much for security

No it doesn't. There is actually no logical way to infer from the parent statement that language choice doesn't matter for security.

> But in practice they work well enough to push C's foibles down into the noise floor.

This goes against findings from research that has been done into the sources of security vulnerabilities. Microsoft and the chrome dev teams have published that 70% of their security bugs are a result of memory safety.

If C is used in 100 years it will only be because of inertia. Today there are better choices in the domain of low level systems programming languages.

> If C is used in 100 years it will only be because of inertia. Today there are better choices in the domain of low level systems programming languages.

I'm not saying you're wrong, but there's effectively zero real kernel work done in anything other than c and c++. Tons of well-known open source Rust/microkernel stuff exists here in public, but behind closed doors is where almost all firmware work is happening. When someone at Microsoft, Apple, Qualcomm, Samsung, etc sits down to code firmware for billions of devices, it happens in c. I've never seen a serious proposal to switch to managed code at any of my jobs, either

I think we'll see more and more complex stuff move out of the kernel, but I don't think c is going the way of COBOL in the next 20 years at least. I'M definitely not going to start using Rust on my own, and it would take a pretty compelling case from management or a junior engineer to make me switch in the future.

> When someone at Microsoft, Apple, Qualcomm, Samsung, etc sits down to code firmware for billions of devices, it happens in c.

Many of those companies are now in C++, actually.

Web browsers are one of the most poorly designed applications in existence. It's not surprising that such complex applications trying to do everything possible have vulnerabilities. But in no way that should serve as a benchmark for C as being inherently unsafe when far more important systems like databases, operating systems, system libraries are written in c just fine. Most of the common vulnerabilities in general are due to unnecessary complexity of systems that lend themselves to poor programming practices, configuration errors, low calibre programmers, etc (OWASP list for example). Memory safety vulnerabilities tend to just get more attention since they are in critical parts of a system, hard to exploit and so attracts highly sophisticated exploits that affect us at a nation state or industry level. If these systems were written in high languages by those high level developers, I'd go nowhere near any computer system.

They aren't just fine as proven by CVE database.

There were already better options before C came to be, it was UNIX being originally free that made it available everywhere.

> It's equally true that this class of mistakes represents an increasingly vanishing share of real world exploits.

Is this true? It seems implausible to me.

> Which argues that maybe language choice just doesn't matter that much for security.

I think it just means that these languages all have elevated potential for security issues, but there are languages without pervasive gratuitous dynamism or memory problems.

> Static analysis tools and runtime hardening techniques don't "fix" C, exactly. But in practice they work well enough to push C's foibles down into the noise floor.

But that’s all additional effort to integrate these tools and practices onto a language which already has a very low iteration velocity (all of the time spent debugging memory issues, package issues, build system issues, etc which simply don’t exist in many modern languages).

> But at the same time, C remains, and will probably always remain, the easiest language on which to tune and optimize. It's not going anywhere. Our grandkids will still be using systems with C firmware at their core.

This sounds like a concession to me. Of course C will smolder on in obscure, legacy firmware long after it becomes obscure—so did COBOL, but we don’t pretend COBOL’s vestigial existence is owed to its merits rather than a quirk of history.

This is a fine and normal thing. C did it’s job for a time, but languages aren’t emerging which are better suited to modern computing requirements. This process will continue and these languages which are chipping away at C’s market share will be eroded themselves eventually.

> we don’t pretend COBOL’s vestigial existence is owed to its merits rather than a quirk of history.

Um. COBOL survived so long specifically because it did some things better than alternatives, mostly around how it handled numbers. Yes, also inertia and historical accident, but also because it was actually good at its job.

It beat out others of its day on merit, as did C, but we’re talking about C and COBOL competing against modern languages in a modern landscape. In other words, COBOL’s dominance in the 60s was due to merit, but it’s vestigial existence today is a historical artifact—it isn’t simply the best language for the application.