51–60 of 141 posts
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.
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.
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…
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/watc…
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).
> 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.) Ma…
> If only people were perfect, then things would be perfect. That argument doesn't hold up too well, considering that people are involved either way.
The flipside, of course, is that language or tool problems have a much, much, larger blsst radius.
Still, you can twist yourself into knots to try to claim otherwise, but the track records of these tools speak for themselves.
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.
But language and tooling can protect you from error classes, and when the error class (“memory safety”) factors in up to 70% of security vulnerabilities (by some estimates,) it makes sense to pay attention to tools which can protect you from those errors, rather than lament the lack of protection for the other 30% or errors, which, by the way, could have just as easily happened in a language without strong memory saf…
You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf
Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.
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.
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...
Hasn’t stopped me from trying though. :-)
And the CHERI folks are trying, too.
So it’s really more of a political problem than a technical one. The excuse extravaganza that we’re seeing from Stroustrup and Sutter doesn’t help at all.
Earlier quoted context omitted.
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…
I think unchecked serialization is bad because it leads to that “given a string you get an instance of the class named by it” problem.