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.
C++ creator rebuts White House warning
41–50 of 141 posts
Re: C++ creator rebuts White House warning
#42Really 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.
Re: C++ creator rebuts White House warning
#43So 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.
Re: C++ creator rebuts White House warning
#44Yeah. 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.
Yeah the logging bug was bad. That’s one bad bug. C++ has bugs that bad that are found and weaponized daily. So, Java is much safer probably by 2-3 orders of magnitude. Also - the log4j thing shows just how dangerous class loading is. It’s an eval like mechanism. Probably future languages designed with safety in mind should avoid eval-like mechanisms as well as avoiding type system escape hatches.
FWIW, class loading isn't necessary for log4j to be bad - unchecked Java deserialization is sufficient for pretty bad pwnage. So we really should add "no unchecked deserialization" to the list of things that a safe language should have.
Java's biggest mistake here, IMHO, was to have a serialization setup that was based solely on a generic interface rather than having the caller declare up front what class it expects to see. In the latter case, so long as you aren't storing naked Object/Serializable fields, type limits strongly restrict the set of naughty objects that can show up in your deserialized object graph. Rust Serde gets this right.
Re: C++ creator rebuts White House warning
#45The 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…
[deleted]
Re: C++ creator rebuts White House warning
#46Stroustrup 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.
I think the funny thing is you no longer even get peak performance from C++. In many ways Java is running rings around C++ performance. Partly, it's because you get state-of-the-art peak optimizations for free from Java, and you'll need a team of 20 full-time build engineers to get a peak C++ artifact with PGO, LTO, and post-link optimizations. Partly it's because the speed of C++ is illusory, with the superficial su…
I acknowledge C++'s safety concerns, but no, Java is definitely NOT running rings around C++ perf. Not a single AI/ML model is implemented in Java. The core of AI/ML runs on C++ only. You may see a lot of Python, but the core engine that Python is wrapping is written in C++. Sorry to break it to you but Java cannot even come close here.
Re: C++ creator rebuts White House warning
#47I 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.
I've long held that belief. But doing so is very technical and political, and not fun.
Turns out what is more fun is to create a new language and rewrite the whole ecosystem. So a lot of the energy is going there instead.
Programming is part fashion...
Re: C++ creator rebuts White House warning
#48There'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…
I'd say it's actually the other way around. C++ in the abstract is full of half-baked, ill conceived ideas that later had to be deprecated or walked back entirely: std::auto_ptr and memory leaks; std::shared_ptr::unique() not being threadsafe; taking the time to implement bounds checking in std::vector, but the default access operator isn't checked; corner cases with std::initializer_list leading to unexpected behavior.
In practice, most C++ shops seem to limit themselves to a small subdialect of C++ that's reasonably safe. The C++ Core Guidelines are essentially an effort at canonicalizing some of these best practices and building them into the tooling.
I think it's fair to say that Rust or managed code should at least be considered for any greenfield project, maybe even a hard requirement for certain domains like cryptography, networking, financial applications, etc. But I don't believe that every application needs to be security hardened to that level, and the C++ library ecosystem is still much more robust than Rust's is. Crates.io feels like a graveyard of experimental libraries that reached 40% the functionality of their C++ cousins before the commit activity dropped to zero.
Re: C++ creator rebuts White House warning
#49There'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…
> 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.
My impression is this is not effectively true. It's not easy to follow all the rules of safe C++. I could be wrong but things like forgetting to use std::move in the right place or forgetting to use unique_ptr where you should. Putting member initializers in the wrong order. Forgetting a copy constructor or forgetting to hide the default, etc...
I'm also not sure of mapping structures to binary data (maybe this isn't enforced in any language but ...). Let's say you want to read a BMP file. You declare a struct that matches the header. If you declare every byte it might work but if you declare it as 16bit values and 32bit values then IIUC, padding rules extra make your code non-portable. What rule enforces that you don't write non-portable code? Also, what rule enforces no undefined behavior, like say int overflow?
The point isn't that it's possible. The point is it has to be enforced by the compiler. Does that option exist `--safe-cpp-only` or something like that the enforces 100% safe usage only? (and obviously, just like rust, you could break out when you need to?)
Re: C++ creator rebuts White House warning
#50There'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…
C++ codebases are substantially about vintage. C++03 with this and that vendor-specific thing is still in the wild and those codebases are just tough to fix: it’s clearly possible, Google has a bunch of C++ from that era deep in the heart of things and they’ve managed to keep it not only running but to all evidence performant and secure. There are some financial shops that seem to have walked a similar line. But the typical C++ codebase from the early/mid 2000s isn’t something you’d sign up to own. It’s a pretty elite C++ shop that has managed to walk stuff from 98 or 03 to the present day without a real pile of grief.
And it’s eminently understandable that Mozilla was looking at a codebase from that era and said: “it’s time to consider drastic measures”.
But C++11 eventually got codified and adopted, clang-tidy and the sanitizers came on the scene, the screws got tightened yet further with 14, and 17, and 20 which is now substantially supported.
It’s just not black and white anymore: C++ has real interop/FFI and a largely “opt-in” mentality around the extreme low defect approach, Rust has a much more opinionated posture that’s trivially better at getting extreme low defect outcomes at shops more diverse in experience and rigor than old-school FAANG or Microsoft but botches some key stuff, there is not a one-size-fits all answer here.
Or rather there is if you don’t over constrain the solution space: if extreme low defect is the call you want a real type system. At the less mainstream end that’s probably Haskell or OCaml or something of that lineage.
But ultimately the Quality Inequality (good fast cheap pick two) remains binding: and TypeScript is just trivially where you find a lot of people who grew up with advanced dependent typing and don’t cost a million bucks a year each. It’s faster than most would guess, and the type system is up there with Idris or something like that in terms of the scope for machine checked rigor: these are MSR people, would anyone expect less?
The conversation is over-rotated on Rust vs. C++ which is a complicated question to which few need an answer.