Definitely. There's loads of value delivered by C++ implementations, including implementations of C++ and other languages. The language design of speed over safety mostly imposes a cost in developer / debugging time and fear of upgrading the compiler toolchain. Occasionally it shows up in real world disasters.

I think we've got the balance wrong, partly because some engineering considerations derive directly from separate compilation. ODR no diagnostic required doesn't have to be a thing any more.

But it isn’t Rust.

Hardly anything is. Literally none of the programs on my machine are coded in Rust. (Firefox is reputed to have a bit in it.)

About FF and Rust:

https://news.ycombinator.com/item?id=30743577

If you're running Windows 11, you have Rust running in your kernel. Look it up.

Someone else posted statistics that show Firefox being 10% Rust, but I'm not sure it makes sense to include HTML and Python and JavaScript in the comparison. If you compare Rust against C/C++, it's 20%

Who runs Windows?

There is no such language as C/C++. I presume you mean the sum of C and C++, and that you omit external libraries from the tally.

> I presume you mean the sum of C and C++

"I'd just like to interject for a moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX."

Pedant

>and that you omit external libraries from the tally.

Mozilla vendors their dependencies. They're counted.

Lots of things 'aren't Rust'. In fact almost everything isn't Rust. For now. That may change in due course but right now I would guestimate the amount of Rust code running on my daily drivers to pretty close to zero%. The bulk is C or C++.

And we have the core dumps to prove it.

When any Costco sells a desktop ten thousand times faster than the one I started on, we can afford runtime sanity checks. We don’t have to keep living like this, with stacks that randomly explode.

I don't know what line of work you're in, but I use a desktop orders of magnitude faster than my first computer also, and image processing, compilation, rendering, and plenty of other tasks aren't suddenly thousands of times faster. Not to mention that memory safety is just one type of failure in a cornucopia of potential logical bugs. In addition, I like core dumps because the failure is immediate, obvious, and fatal. Finally, stacks don't "randomly explode." You can overflow a stack in other languages also, I really just don't see what you're getting at.

I don’t mean a call stack, I mean “stack” in the LAMP sense—the kernel, drivers, shared libraries, datastores, applications, and display servers we try to depend on.

> Not to mention that memory safety is just one type of failure in a cornucopia of potential logical bugs.

You can die of multiple illnesses so there's no point in develop treatment for a particular one of them.

> I like core dumps because the failure is immediate, obvious, and fatal.

Core dumps provide a terrible debugging experience, as the failure root cause is often disjoint from the dump itself. Not to mention that core dumps are but one outcome of memory errors, with other funnier outcomes such as data corruption and exploitable vulnerabilities as likely.

Lastly, memory safe languages throw an exception or panic on out of bound access, which can be made as immediate and fatal as core dumps. And much more obvious to debug, since you can trust that the cause starts indeed at the point of failure

I dunno, my computers seems to keep running slower and slower despite being faster and faster. I blame programmers increasingly using languages with more and more guardrails which are slower. I'd rather have a few core dumps and my fast computer back.