> It disappoints me to see hardware compensate for the failures of software. We should have done better.
I disagree. From a user's point of view, hardware-assisted memory safety is always beneficial. As a user of any software, you cannot verify that you are running a program that is free of memory access errors. This is true even when the software is written in Rust or an automatic memory-managed language.
I hope that one day I will be able to enable memory integrity enforcement for all processes running on my computers and servers, even those that were not designed for it. I would rather see a crash than expose my machine to possible security vulnerabilities due to memory access bugs.
It is one out of many since 1958, starting with JOVIAL, how the industry has been aware of the security flaws that C allows for, which WG14 has very little interest in fixing, including turning down Dennis Ritchie proposal for fat pointers in 1990.
Note that C authors were aware of many flaws, hence why in 1979 they designed lint, which C programmers were supposed to use as part of their workflow, and as mentioned above proposed fat pointers.
Also note that C authors eventually moved on, first creating Alef (granted failed experiment), then on Inferno, Limbo, finalising with Go.
Also Rust ideas are based on Cyclone, AT&T Research work on how to replace C.
It was needed the tipping point of amount money spent fixing CVEs, ransomware, for companies and government to start thinking this is no longer tolerable.
You have a whole class of dumb and dangerous bugs completely wiped off, which not even a new/junior untrusted developer can introduce. That's not nothing.
Of course, not checking if a user has permissions to perform an operation is not something Rust or any language will protect you against, but come on it's almost 2026 and we still are talking about use after free...
I agree. The underlying hardware should be as simple as needed and thus be cheap and consume little power. Fixing bad software practices (like using an unsafe language) via hardware hacks is a terrible mistake.
ARM and lots of non-x86 architectures often use a series of bootloaders to kick up ram, wake up parts of the hardware, blah blah, and read devicetree blobs to know what the hardware looks like
The author does point out that these problems come up when implementing various data structures.
It might be surprising to some folks, but there is a lot of unsafe code in Rust, and a lot of that is in the standard’s data structure implementations.
Also —
Common in network programming, the pain of lifetimes, is in async.
The model sort of keels over and becomes obtuse when every task requires ownership of its data with static lifetimes.
What's all this controversy with GNOME? I must be missing something. Isn't it perfectly reasonable to say that some security issue in a dependency (which is maintained and open and funded, like WebKit or Linux) is not the fault of someone down the line to fix?
I can't imagine someone reporting a bug to one of my repos about some race condition in the kernel. Why the hell are you bothering me with that? Tell the LKML.
That's not to say I'm not sympathetic, it's just, like, what do you expect me to do?
One the one hand: Yes, if it's not your code then it's not exactly your responsibility to fix.
On the other hand: As a user, the takeaway isn't "well that's not their fault", the takeaway is "if I use this software, then I am vulnerable to this problem". The question of who's responsible or where the fault lies is irrelevant.
Off the top of my head: you could broadcast it more publicly that there is a known issue (particularly important if this is a security issue). You could change code to avoid whatever kernel features trigger the race. You could print a warning if you detect the kernel version is an unpatched one and/or has Kconfig in whatever state exposes the issue.
C++ is not going anywhere. It's even still used in gamedev to make new games. It's used in HPC and scientific computing. Windows applications often use it. And so on.
For better or worse, modern C++ is still the most capable and expressive systems language. To replace it, we need (at a minimum) a language with similar capability and expressiveness in the low-level systems domain. The options are really thin; Zig probably comes the closest but it is a bit austere coming from recent C++ versions.
I think we can do significantly better than C++ as a systems language. We just haven’t landed on a language that really nails the design.
> For better or worse, modern C++ is still the most capable and expressive systems language.
Not really. Rust, ATS, D, and some implementations of Lisp and even Haskell if you slay the dragon of actually learning GHC. Modern C++ is honestly overrated in my opinion as an extensive user of the language with 300k lines in a modern dialect alone. It's a pain in the ass to step through in a visual debugger and core dumps may as well be useless no matter the platform. It's extremely grating to read and to write. Compilers have a tendency to crash like crazy if you get too cute. There's still no compile-time (or runtime) reflection. I would literally rather be writing proofs for a dependent type system than deal with heavy template metaprogramming.
C++20 metaprogramming is pretty clean and straightforward. It became usable around C++17, though the learning curve is a bit steep. I can’t remember the last time I saw a compiler crash, and I’ve used many compilers on code bases that use a lot of dark corners of C++. The occasional compiler bug is a thing though.
I didn’t say C++ was amazing, just that recent dialects are better than the alternatives in practice, many of which I have also used for similar code.
Rust is not a substitute for C++ unless your code isn’t all that low-level, it lives closer to the abstraction level of Java. There are a number of odd gaps in the Rust feature set for low-level systems programming (database kernels in my case), the rigid ownership/lifetime model doesn’t play nicely with fairly standard systems-y things like DMA, and the code is always runs slower for some inexplicable reason.
I’d love something to replace C++ but to be a candidate it can’t be less expressive, slower, and so rigid that it is difficult to do some ordinary systems-y things. A nerfed programming language is not the answer to this question.
> C++20 metaprogramming is pretty clean and straightforward.
I disagree. Having to juggle two type systems and two languages simultaneously is inherently unclean, to say nothing of how noisy and unergonomic templates end up being. For anything non-trivial they're a mess. Imagine I handed you a codebase with a few hundred templated structures, averaging about 50 parameters each, many of which are variadic, many of which are nesting as parameters within each other. As you climb through this pile, you end up in a totally different layer, where these more complicated templated structures are passing around and working on a much larger collection of simpler templated structures and constexpr. You're not going to have a fun time, no matter how comfortable you are with templates.
> I can’t remember the last time I saw a compiler crash
How long of a parameter pack do you think it will take to cause a crash? Of course eventually the compiler has no more memory to spare, and that'll be a crash. Clang will helpfully complain:
warning: stack nearly exhausted; compilation time may suffer, and crashes due to stack overflow are likely
But I assure you, the compiler will crash long before it runs out of memory. If you're in the domain of non-trivial meta-templates, these packs can explode to ludicrous sizes from recursive concatenation, and especially if you have a logic error somewhere that generates and concatenates packs you didn't want. And that's just the obviously intuitive example. Now contextualize this in the codebase I describe above.
The more you push templates as a turing-complete language to their maximum potential, the more compiler issues you run into. Templates are probably the most rigid and unstable metaprogramming facility I've experienced, honestly. GCC and cl.exe are the worst for it.
> it lives closer to the abstraction level of Java.
That's interesting, because Java isn't very abstracted over the JVM. It's that extra layer of the JVM being an abstraction over another CPU architecture that makes Java abstract. C and C++ are arguably more abstracted, because they have to be. But just like Rust, they provide good general semantics for any register machine that the abstractions can mostly be compiled away.
> the rigid ownership/lifetime model doesn’t play nicely with fairly standard systems-y things like DMA
Choosing references as your default is insane, honestly. Safe Rust is akin to writing formally verified software in the mental and ergonomic overhead it incurs. That's not coincidental. I've come to the conclusion one of the biggest mistakes of the community is not pushing pointer-only Rust harder, given they want it to be taken seriously as a systems language.
Rust's safety is irrelevant as far as I'm concerned. It's nice that it has it, but I (and everybody else working in C++) is used to working without it and don't really miss it when it's gone.
> and the code is always runs slower for some inexplicable reason.
As you come to understand Rust as a set of assembler macros and rewrite rules applied over them, I've found they're neither more or less granular than the C/C++ ones. They're just a different family, and it stems from a different style of assembly programming (of which there are many). If you've ever translated a lisp with manual memory management onto a register machine, it's similar to that way of thinking about how to compose LOAD/STORE/JUMP + arithmetic, which it got from the ISWIM/ML heritage. Just like with C/C++, everything else is syntax sugar and metaprogramming. At the core of it, you should still be able to translate your Rust code into your target's machine code in your head relatively trivially.
> Choosing references as your default is insane, honestly. Safe Rust is akin to writing formally verified software in the mental and ergonomic overhead it incurs. That's not coincidental. I've come to the conclusion one of the biggest mistakes of the community is not pushing pointer-only Rust harder, given they want it to be taken seriously as a systems language.
That's an interesting perspective I hadn't heard before, but I think there are a couple problems. One, the culture is really against using unsafe unless it's impossible to write the code using safe Rust. This happened with the Actix web drama in 2020 [1]. And, there is the opinion that unsafe Rust is harder than C [2]. Not just that, but unsafe Rust is really ugly and annoying to use compared to safe Rust. I think that hinders the potential adoption of your idea, too.
Fortran may still be used but is considered functionally dead nonetheless. Nobody is hiring Fortran devs anymore (and those who do put themselves in a really hard market position). Yet, learning C++ might still be a more valuable skill than learning Rust.
> Why would a company rewrite a codebase that has decades of error free functionality? What do they get?
All well and good if it is something you do not have to modify/maintain on a regular basis. But, if you do, then the ROI on replacing it might be high, depending on how much pain it is to keep maintaining it.
We have an old web app written in asp.net web forms. It mostly works. But we have to maintain it and add functionality to it. And that is where the pain is. We've been doing it for a few years but the amount of pain it is to work on it is quite high. So we are slowly replacing it. One page at a time.
the insurance companies running COBOL don't care. it's cheaper to pay a cowboy $X00,000/yr to keep the gravy dispenser running than trying to modify it. by definition, this is code that's been in use for decades. Why change it?
I suspect the committee agrees with you. I think they’ve anticipated a competitor coming to kill C++ for two decades now and see themselves as keeping C++ on life support for those who need it.
It’s shameful that there’s no good successor to C++ outside of C# and Java (and those really aren’t successors). Carbon was the closest we came and Google seems to have preemptively dropped it.
The addition of a safety design is a shift in our milestones for v0.1, and you can see the difference here. Both of these are fundamental parts of v0.1, and will take long enough that the earliest date for v0.1 is pushed out to the end of 2026
Look, no one is more excited than me for this, but this is reaching Star Citizen levels of delays.
reply