Hmm, I had in mind the phrase “insecure systems languages”, but I don’t want to get into a boring debate about what “systems languages” or “systems programming” mean...

It's at least as much my fault as yours, since I said "systems language" as a shorthand for C/C++, not to describe the problem domain, and it's true that the modern zero-cost-abstraction memory-safe languages that can displace the last of the C/C++ code are very new. We'll be out of the era of C/C++ when a mainstream browser is written in one of them.

As I understand it, Firefox now has substantial parts written in Rust, Mozilla's own language. Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.

> Also, unless the OS and drivers are written in a memory-safe language as well, that castle is to a degree built on sand.

You have to start from somewhere. There's Rust. I'd like to see some more language (and tooling) competition with systems that can prove functionality at compile time in practical situations.

Not impressed with current C/C++ static analysis landscape. I've used a ton of static analysis for writing Windows kernel drivers for instance — from known tools like Microsoft's Prefast (requires a ton of annotation, sigh!) to clang. And others. And fuzzing on top.

But it still doesn't come anywhere near replacing a good pair of eyes and some hard thinking. And I'm not talking about logic bugs here, but for example concurrency and memory safety related issues. I've had plenty of "quality time" (not!) with the kernel debugger...

I'm very seriously considering to use Rust instead of C/C++ whenever I have my next Windows (or other OS) kernel mode project. Even though some consider it a bit unproven in this space. At this point, I don't feel like C/C++ is proven either...

To a bit lesser degree, same for anything that touches untrusted inputs, directly or indirectly. Even if you can sandbox it.

I do need to work around some issues with Rust. Like to learn how to minimize code size for those situations where it is a constraint. Like device firmware. However I feel that's easier than writing bulletproof C/C++ code.

Part of me would like to see .NET Native available on all levels of the stack, but with WinDev vs DevTools politics, that is unfortunately just wishful thinking.

The words "to a degree" are doing a lot of work in that sentence, given where browser RCE vulnerabilities actually appear today in code.

Kernel bugs are obviously a part of modern bugchains, but they're used to escalate privileges, and usually not to gain native code execution in the first place. The enabling code execution arises from code that doesn't need to be in C/C++ at all.

From a security standpoint, it really depends on your threat model.

But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs.

Given the above, writing your code using a memory safe language is still a huge net benefit.

> But when it comes to software reliability, you rarely if ever should be worrying about kernel or driver bugs.

Not quite sure what you mean. For an application developer, yeah, you don't need to worry.

In general... If I had a dime just for all various types of kernel memory read/write vulnerabilities due to kernel bugs and bad drivers, I'd have a lot of dimes.

Video codec provided by Cisco is installed with every instance of Firefox. Check your plugins.