Yes, and it’s not just C++, you can see this attitude in a bunch of languages. John Blow’s still unreleased language Jai is explicitly “designed for good programmers”.

Drew DeVault’s Hare language used to have “trust the programmer” among its design principles, but has since changed to “trust the programmer, but not by default”, which is a much better idea in my opinion. They have also added basically all the “low hanging fruit” memory safety features, so while there is no lifetime safety you at least get bounds checks and such.

Build Systems A La Carte

The one paper that gave me hope about build systems. That I might one day actually enjoy using one, even if I have to build it myself. My printed copy is still sitting on my bedroom.

I’m sorry if this made you pessimistic. I’ve spent 15+ years writing C++, 10 actively participating in the standards orbit. The thing is, you don’t need to be in the standard committee’s orbit, you can forge your own path. I will most likely keep writing C++, but it’s the pedantic arguments on the committee. The wrong people in the right place at the right time making the wrong decisions even when the correct solution is right there in front of them.

Keep in mind, you can always write C++ and ignore the committee. It’ll suck, but it’s very doable.

EDIT: Checked your profile and saw your site and all your C++ projects. You’re gonna be totally OK :)

This article made me the most pessimistic about C++ I think I’ve ever been since I first encountered a linker error years ago.

Linker errors fucked me up when I had to write C++ during a university exchange back in the day. Couldn’t really figure out where to get the documentation for this in the first place.

This article made me the most pessimistic about C++

Don’t be, extreme opinions (whether positive or negative) are rarely the correct ones, when it come to complex matters. The truth is always somewhere in the middle and more nuanced. And this is as extreme anti-C++ (both language and people working on it), as you will probably ever see.

Sadly many people don’t care about safety, but only about “efficiency”. “You can take this UB from my cold hands…”.

Yes, definitely. One of the main points in this debate is whether to have array bounds checks by default. For the longest time, the answer from C++ folks was a resounding “No, of course not!”. But they’re very slowly coming around to it: https://chandlerc.blog/posts/2024/11/story-time-bounds-checking/

So yeah, 0.3%. That’s roughly the performance gain that we got by not having bounds checks by default. On the other hand of this tradeoff is the fact that out-of-bounds accesses are among the leading cause of memory unsafety vulnerabilities, second only maybe to use-after-free.

As it should. C++ is a horrible tarpit, supported by legacy, egos (see some of the examples from this post!) and a combination of Stockholm syndrome and unwillingness to expand one’s horizon.

I do not thunk COBOL is a good case study: Companies get surprisingly nimble when it gets just a tiny bit harder to sell their product. Be prepared for emergency meetings as soon as sales people have to show a memory safety roadmap.

Regarding “Cosmopolitan,” it’s worth noting that Justine has another project (also mentioned in a footnote of this blog post) called APE, another dogwhistle, though this time a racist one rather than an antisemitic one. As the post notes, Tunney has generally done a good job of eliminating much of the recorded history of her own prior bigotry, but some records remain. She’s promoted Curtis Yarvin, who himself has advocated in favor of slavery and argued that whites are biologically superior to non-whites.

For what it’s worth, I also believe cosmopolitan to be a dog whistle. In other situations, I would give it the benefit of the doubt, but not this one.

That part was so disappointing for me to read, especially after seeing other people corroborate it. She (along with Isabella Muerte) has been a huge inspiration for me for years.

I concur with folks here that it is a dogwhistle. I wouldn’t believe that absent of all the pre-existing context around Tunney – but with all that in mind it’s hard to not come to that conclusion.

Sort of similarly, I learnt C++ in the mid 90s when templates were new and pretty rarely used. After a few years ill-health crashed me out of the industry, but like you recently I thought it was time to try to catch up, and .. oh god, what a mess.

I’ve spent the last week or so reading rust docs, though admittedly not actually trying to write any code yet. From what I’ve seen it think it will be easier for me to learn rust from scratch than to try to catch up with C++, and probably much more pleasant!

And what really blows my mind is that, despite all these years of creating a deluge of confusing nonsense, it still doesn’t have the most basic memory safety. In C++23, this code generates a warning. Unbelievable.

int* wtf() {
    int x { 42 };
    return &x;
}

Sure, on the surface this looks idiotic. But, as I mentioned in the sibling comment, the truth is not on the surface and is more nuanced. The example you have shown is trivial and the compiler can detect the issue (which is why you are getting the warning). But consider this slightly more complicated case:

int* wtf () {
  int x {42};
  return f (x);
}

// And in another translation unit we have:
//
int* f (const int& r)
{
  return &r;
}

Now, when the compiler compiles wtf(), it doesn’t know what f() does so it cannot decide whether this code is safe or not. You can argue that a little bit of safety is better than no safety, and maybe you are right. But I personally feel that partially-safe is still unsafe.

How could we possibly make the above more complex case safe? There are currently two main alternatives: let me call them the “Rust way” and the “Profiles way”.

With the Rust way we would have to somehow pass the lifetime information around similar to Rust. So far (as far as I know), nobody figured out how to do this without essentially creating a new language with a new ABI that will have about as much difficultly inter-operating with existing C++ as Rust. Some think this is the way to go and maybe they are right, but I don’t think one can also dismiss the concerns of those who don’t share this opinion as not being valid (we still have to work with the tons of the C++ code out there, somehow).

With the Profiles way you essentially rely on static analysis of your entire codebase. So in the above example, the compiler (or static analyzer) will see both wtf() and f() and will be able to figure out that your code is unsafe. While this can theoretically work and keep C++ the way it is (and maybe even be applied to the existing code), nobody has demonstrated that this approach can be implemented in practice and in a reasonable time. But again, I don’t think one can dismiss it because the potential benefits compared to the alternative are very substantial.

maybe don’t throw in an aside implying that liking Go is a form of brain damage, ha ha, how funny.

Honestly, not my best moment. The decision to keep it in came down to a coin toss, and I was 7 days into writing the post with only 20 hours of sleep.

Thanks for the heads up. I think you had tried to inform me on other platforms but it got lost in notifications. This should be fixed now :)

I think a key point Izzy is making here is that C++ as a project has a fundamentally safety-hostile culture, both in terms of:

• Technical hostility to advancement of safety techniques, rooted in the insular, defensive, and denialist central wielders of power, and backstopped by abuse of ISO’s own rules to silence critics and dissent.
• Hostility to physical safety, especially for those from marginalized groups. The post documents many instances, some known, some new, of the C++ project protecting sexual harassers and supporting the inclusion of someone previously convicted of multiple sex crimes (including one against a child) whose status as a sex criminal was known but not disclosed to others in the community.

The conclusion in the post is little short of despair that the C++ project’s participants and norms make it highly unlikely that it will adapt to meaningfully advance safety in the language, and that it will continue to be an unsafe language built by an unsafe project.

This is personally very disappointing. I wrote “C++ Must Become Safer” earlier this year because I think advancing safety in C++ would do meaningful good. However, it is hard to feel optimistic after reading this post.

Hey, you were warned from the very first sentence, and at least to me, the subject matter was clear after the first couple paragraphs. And yet you inflicted this upon yourself. Or you didn’t, and just wrote this comment from the warnings alone? I’m halfway through the article, and “incoherent, full of profanity” sounds… inaccurate at best.

When I read this article, my very first thought was “this is just an unmediated stream of ranting occasionally broken up by technical wording, it’s like a simulation of me ranting to myself when a tool doesn’t work.”

After it was posted, before anyone commented, I was going to write a post like yours, but figured it wasn’t worth the time. After seeing so many people praising it, I have to assume this is some sort of community bias and this person is just really famous or something. To be honest, I’m shocked this is allowed to stay on this site. Go ahead and look in the moderation logs and you’ll see someone was banned for comparing bitcoin to a handjob.

The biggest red flag was how the blog post mentions “all technical topics are also political.” I can tell whoever this is, they’re somebody I never want to talk with.

that your Rust code might be used by the military to kill people.

All free and open source software can be used for any purpose. That’s not limited to Rust.