If your definition of "safe language" is "Rust/Zig/ATS/whatever", our premises aren't compatible, because I am talking about things like Java and Python. In the 1990s and early 2000s, we were still building application code in C/C++.

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.

This is true, largely because no one outside the HN bubble knows Rust/Zig/ATS/whatever. Most companies and people want to get stuff done, and a new language can get in the way of that. It'll take a while for those newer languages to pick up main-stream traction, and by a while I mean a few years of pushy college grads who used it in CS 101, 202, or 303.

Don’t be so sure about that. I don’t know any C++ dev who hasn’t heard (good things) about Rust. It’s definitely well known in the systems programming community at this point. That’s different from using it in production though.

And that's precisely the point. You don't use C++ because it's the best thing since sliced bread. You use it because you want to easily use decades of optimized libraries and get a result that's highly performant without spending a long time creating wrappers in Rust (that may not even be easy to do w/ libraries that rely on a lot of templating).

A lot of C++ projects (not all!) have relatively few dependencies. I think this "decades of optimized libraries" is a bit hyperbole.

Besides, libraries that were optimized for HW 20-30 years ago don't age all that well and are far from optimal these days. They also tend to still have a ton of bugs.

Now, I'm not saying there aren't cases where you really need to build on legacy library base. Merely that it's a bit rare case.

Libraries that are 20-30 years old and that people still use today are generally in continuous development over that time period, often with the same team (in a ship-of-Theseus sense). That means that they have been optimized for today's hardware for about 20 years worth of todays.

Now there are cases where libraries have ossified and there is room for a new library to come and eat their cake (look at ripgrep for an example), but there are also a lot of cases where they are going to be very hard to beat (a lot of boost is in this area, I believe, and there are many other examples in specialized domains).

boost fills more of a role that standard libraries play in other languages (think go).

And tooling.

Mixed language development experience in Java and .NET IDEs, UI frameworks, game engines and GPGPU shaders.

C is deprecated on Windows, where the focus is now C++ and .NET, old style C code has been made compatibile with C89's C++ subset.

Even the new Universal C runtime is written in C++ using extern "C".

On Android, C is reserved for the Linux kernel and "legacy drivers" (pre-Treble), everything else is C++ and Java/Kotlin.

On Apple OSes, C is left for the UNIX style compatibility layer, everything else is a mix of Objective-C, Swift and C++.

By the way it is either C or C++, not C/C++.

VS now ships clang, so that should improve support for C considerably.

Objective-C is C, with extensions. Swift interoperates with C, not C++.

It ships clang, because that is Microsoft's answer to C support on Windows, for those that still want to use C.

Visual C++ focus is naturally C++.

C with extensions, by definition, is not C, rather something else.

Swift interoperates with Objective-C, thus C interoperability comes for free.

IO Kit, DriverKit, Metal Shaders, LLVM make all use of C++.