I'll await your Rust ports of Windows, Linux and MacOS then.

This isn't really a fair take. Keep in mind that C/C++ has been the backbone of the most important software in the world since the 1970s. At that time we didn't have virtually unlimited compute and memory at our fingertips the way we do now. It was a huge improvement to have a high level language which still could be optimized nearly as well as assembly.

Its staying power is due to the fact that we really haven't had many good alternatives until maybe the last few years. Things are not going to get ported and rewritten overnight, especially when they largely just work like Linux & PostgreSQL. We'd nuke a huge amount of institutional knowledge and inertia to change those up.

And C/C++ are still key in the embedded space where we still have devices constrained on compute and memory. That's not going to go away anytime soon.

This criticism feel like someone complaining about why anyone still uses horses on the day the Model T was announced. Change takes time.

The entire compute world was built on top of C and C++. Saying they're not fit for purpose doesn't seem correct. I think what you're really saying is they're not an optimal choice from a safety perspective.

> All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.

Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like you're discounting the effort that goes into doing that properly.

Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?

C++ has had smart pointers for memory (and other resource) management for a long time now (see e.g. the Windows ATL classes for working with COM objects and resources).

There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust).

1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/simple reference counting will prevent the objects being deallocated).

2. Interacting with (and creating resources in) a garbage collector when running/evaluating JavaScript code.

3. Just-in-Time (JIT) compilation of JavaScript and other complicated interpretation-compilation pipelines that can allocate and transfer objects between the different stages.

You can also take the opposite conclusion from this: C++ is now viable because LLMs can catch the security bugs.

I'm obviously not entirely serious here, but I think this is true to some extent: the number of memory safety bugs in a codebase is finite. Once you have a way to find them, you can drive that number down to zero.

C++ has become a far safer language thanks to LLMs - at least if you run the LLMs before you are attacked.

You make a false equivalence between being an idiot/“didn’t know what they were doing” and not knowing how to properly manage memory. Also, why do you think the devs who worked on google chrome weren’t idiots?

Some of the most important and safety critical large scale projects in the history of humanity had/have manual memory management. If you think the effort of doing it correctly is not worth it for certain projects, that may be a reasonable opinion. But the idea that humans cannot write correct C/C++ programs is in direct contradiction to historical fact.

Rust certainly helps for certain classes of errors but doesn't help at all for logic errors or incompletely understood requirements or occasional need for hacks due to business needs.

This seems an awful lot like confirmation bias. Web browsers are themselves extremely complicated.

Also, this doesn't address why the rate increased, which is the interesting part!

blaming bugs on C++ has got to be the most leetcode thing I've heard in my life

[dead]