There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've been released in the spirit of trying to make everyone happy simultaneously.

I am solidly in the camp that believes C++ is unsafe. With enough discipline and tooling, it is possible to write safe C++. Are there more than a sliver of shops jumping through those hoops?

Of course, there may be a survivorship bias involved that proves me wrong. If it turned out that every remaining C++ shop is great at writing C++ code, because all the shops that weren't gave up and migrated to something else, I wouldn't be shocked.

> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++. My CppCon 2023 keynote outlines that evolution,

C++ safety may have improved a lot, but it’s still far, far behind most other languages we use. It’s not even a close comparison.

You throw a bunch of programmers at a problem and you will get some number of bugs in the code. In C++, some percentage of those bugs will be memory errors. You can eliminate raw pointers but that doesn’t solve the problem—there are all sorts of places that dangling pointers crop up anyways, like in references that get captured in lambdas which get stored somewhere and then the programmer doesn’t realize that the lambda is called after the object is destroyed.

I’ve seen various solutions proposed to these problems. The worst solution is to “just hire better programmers and be careful”. The easiest solution for greenfield projects, most of the time, is to pick a different language.

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that

If only people were perfect, then things would be perfect.

There’s, what, 40 years of evidence to suggest that most people, most of the time, simply cannot write memory-safe C++ code (50 years if you count C.)

Maybe we should continue the experiment for another 50 years, just to be really sure the language is the problem.

He seems to be in denial. I watched Stroustrup's CppCon 2023 talk about safety[0] a few months back. He spends about an hour talking about how important safety is and all the new things C++ offers to write safe code. Why did he suddenly start caring about safety now?

C++ is like a mad hatter's bad acid trip and somehow people are convinced it's still a great language to use in 2024.

[0]: https://www.youtube.com/watch?v=I8UvQKvOSSw

Stroustrup needs to realize that "just wait a few more years" isn't an acceptable answer when you're already a decade late to the party. The white house is not some radical pioneer at the frontier of programming language design. By the time it says anything on the subject, it's been obvious to everyone else for years.

There might be a reasonable discussion here if we were discussing profiles when the earliest incarnations of it appeared around 2015, but we're not. It's 2024 and they're still not in the standard. There isn't even a clear proposal for compilers to begin implementing. Once there is, profiles will still be an optional, partial, and incremental solution at best. They won't even fulfill Stroustrup's stated desires to address all kinds of safety (for which there hasn't even been discussion yet).

Stroustrup as always fails to recognize the vast surface area of C++ features, foot cannons, and the heavy weight of C compatibility around C++ neck.

C++ barely made sense in 1995. It makes absolutely no sense today.

> Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ.

The fundamental problem is they’re just guidelines and they’ll always be just guidelines. You can still do all the wild old stuff without so much as a warning and you’ll have to figure out how it even interacts with the new stuff which exposes yet another vector for failure.

Even such basics as initialization is full of traps in C++, its truly language thats awful to produce anything safe with. C on the other hand isnt a bad language, but C's problem comes from the horrible standard library and bad standard. You can create much better C by passing -fno-strict-aliasing -ftrapv -fsigned-char to the compiler even now. Heck rust's unsafe is more unsafe than C. "C" could be improved with a better compiler that ignores the standard, but perhaps it wouldnt be C anymore even if the syntax remained the same.

C++ problem is not helped by the compilers either, shoutouts to msvc++ accepting absolutely wrong and horrible code by default.

Really sad to see such an influential computer scientist lose interest in advancing computing for the perceived slight against his legacy.

Ironically I think Stroupstrup is actually doing more harm than good to his reputation by "evolving" C++ than simply putting it in maintenance mode and contributing to a modern language.

This link is a mobile (AMP) version of the article that has been submitted already:

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

So what it sounds like:

Strousoup: The future is a yet to be defined profiles.

Sutter: The future is a yet to be defined C++v2 that's backwards compatible but also solves the problems.

Chandler: C++ compile times are too slow. Going to build a brand new front-end that really fixes compile performance and maybe fixes memory safety & let's you call C++ code.

My take:

Re Strousoup: From what I've seen, Strousoup's ideas don't seem particularly extra likely to make it to the final standard and that's when he already has a formal standard written up. Prognosis: Modules were much simpler (conceptually at least), took ~6 years, and even 4 years after coming out have seen minimal adoption. This definitely isn't on track for C++26 and likely will encounter real-world roadblocks by C++30. If everything goes well, the industry would be ready to start adopting profiles in ~10 years. Or they could start using Rust today. Still quite vague in terms of whether or not this idea can be implemented by compiler authors.

Re C++v2: Vague hand-waving without a real plan on how to be meaningfully competitive with Rust. Since it's an experiment and experiments can fail, unlikely to lead anywhere and unlikely to see industry adoption.

Re Carbon: interesting experiment and the most likely real-world candidate to displace C++. Being done by a company with a massive C++ codebase that would benefit from migration to Carbon. From the looks of it, they're spending most of their time on compile performance. Neat technical experiment but not really showing that a language that's bidirectionally compatible with C++ can meaningfully improve on safety. Also, Rust compile times have improved significantly in the past few years and are better than C++ in my experience (but of course, hard to have a fair comparison of the two and I'm compiling these days on a much faster machine than I've used for C++ in the past). The recent Cranelift work might reasonably speed things up another ~2-3x.

EDIT: TLDR: C++ today is not safe enough and no idea when it will be, regardless of the work going on to try to make it safer with no idea when that might happen.

Bjarne Stroustrup: Remember the Vasa! (2018) https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0...

Bjarne Stroustrup 2018: We are on a path to disaster though enthusiasm and design-by-committee (or rather “design-by-committees”). During the early days of WG21 the story of the Vasa was popular as warning against overelaboration (from 1992):

“Please also understand that there are dozens of reasonable extensions and changes being proposed. If every extension that is reasonably well-defined, clean and general, and would make life easier for a couple of hundred or couple of thousand C++ programmers were accepted, the language would more than double in size. We do not think this would be an advantage to the C++ community.”

“We often remind ourselves of the good ship Vasa. It was to be the pride of the Swedish navy and was built to be the biggest and most beautiful battleship ever. Unfortunately, to accommodate enough statues and guns it underwent major redesigns and extension during construction. The result was that it only made it half way across Stockholm harbor before a gust of wind blew it over and it sank killing about 50 people.”

“It has been raised and you can now see it in a museum in Stockholm. It is a beauty to behold - far more beautiful at the time than its unextended first design and far more beautiful today than if it had suffered the usual fate of a 17th century battle ship -- but that is no consolation to its designer, builders, and intended users.”

I wish that rather than making excuses, C++ apologists switched to trying to just make the whole language memory safe.

It’s possible. There just aren’t good incentives in place to do it.

What makes me wary of jumping to Rust is the async stuff. From what I read, colored functions were introduced and most of the libraries that do useful stuff adopted async and kind of force you to be aware of it in your own code.

For me, the perfect C++ replacement would be something like Go without the runtime burden. I'm not sure that this exists, so I use Go whenever I can and C++ in the ultra rare cases where I can't.

I just want a safe-ish language that doesn't nerd-snipe 95% of software engineers into creating glorious and incomprehensible syntactic monstrosities that go nuts with allocations and hidden function calls. Really hoping Zig getting some more traction.

Table saw manufacturers wonder why Exacto knife users are so worried about their fingers getting cut off. The simple and obvious explanation is we now live in a world where many people are too lazy and/or dumb to spend time learning the tools of their trade.

3..2..1

With all due respect Stroustrup seems completely delusional about real software out there in the wild. He needs a dose of reality.

Can C++ be safe? Absolutely! Does a jr. developer know how to avoid all the pitfalls and craft this magical, safe code? No examples can be shown.

The amount of iconoclastic knee jerking in this thread is kinda nuts. Equating this rebuttal to an old man yelling at clouds? Saying Cpp never made sense?

The first step to solving a problem is accepting reality. Cpp has been foundational, like C, to our computing world. If the rich legacy of libraries that underpin our "better" language choices is offensive to us, or if we really believe we are powerless to improve the situation around the most popular programming language(s) then we're not being realistic.

This is a huge debate of national importance and it'll shape programming language design for decades, it's important to get this right, and that will take more than just once choice and more than one approach to get right.

C++ is an unsafe language in all of its current implementations except CHERI.

Stroustrup is being tone deaf or maybe he just doesn’t get it.

The issue is that there are so many ways in which you could write a C++ expression that violates memory safety and gives users control of your heap.

In Java or other truly safe languages, there are zero ways to do that short of pwning the JVM with a bug. In Rust and other safe systems languages, to do something unsafe you have to call it out using the unsafe keyword.

So - the places in your C++ code where you might have a memory safety violation are everywhere while in the alternatives they are either nowhere or they are carefully demarcated.

tangentially nothing in my career made me as angry as working through Bjarnes Book because none of the examples worked (that was an early edition of the book maybe later editions added the necessary includes etc)

I mean, you can call it a rebuttal, but this:

“There are two problems related to safety. Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ. I and the C++ standard committee are trying to deal with that,”

sounds like an admission that, following decades of improvements and modernisations to C++, safety and quality remain a practical concern in most actual C++ codebases. In many ways it’s surprising that it has taken this long to call time on it. I can understand Stroustrup’s frustration; the work they’ve been doing has been excellent, but there’s nothing stopping industry or the government switching to other options that are making better headway against problems like this.

> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++

This rhetoric from Stroustrup comes off as disingenuous; what saves it from being outright dishonest is the wording "an aim". As in one of many. Not "the aim".

Firstly, of course we get a jump in safety from K&RC to C++.

But most of the development of C++ has been driven by a hedge between multiple factors, only one of those being safety, and not always having the top priority. Factors like: ease of implementation, performance, safety and backward compatibility.

We can point to recently introduced library features that are not safe, and easily identify backward compatibility issues that prevent improvements in safety.

In the 1990's, C++ introduced a standard library of containers. If safety had been the top priority, iterators would never have had undefined behavior when the target object changes, and std::vector would have been impervious to out-of-bounds accesses. These things could easily have been achieved in what is just library code. A C++ developer can easily ignore the library, and develop their own containers with safe iterators, vectors that can't be misused and other elements. The standard didn't do that because of those other factors: ease of implementation and performance.

(Can someone point to three situations in the development of C++ in which safety ran up against efficiency or implementation ease, and did not lose?)

>https://www.reddit.com/r/cpp/comments/14vcvxg/c_makes_it_eas...

This you bro?

TL;DR: Bjarne Stroustrup is frustrated that the authors of the government's proposal don't realize that, theoretically, there may exist teams of talented developers who are able to consistently write safe C++ code.

Yeah. The language you pick doesn't magically make you Fort Knox regardless of "memory safety". Rewind in time and the White House would be berating all of us to write in Java... you know... a "memory safe" language, only for the worst security fail to come along Log4Shell.