6 ms·

C++ creator rebuts White House warning

55 points by ben_s 3y ago

favorited 3y ago
On a recent CppCon panel[0], after much discussion of ecosystem-wide safety and how "safe" programming languages don't automatically create "safe" systems (which has merit), he basically had to shrug his shoulders when someone asked about thread safety. [0]https://www.youtube.com/watch?v=R10pXWHpPn4 https://www.youtube.com/watch?v=R10pXWHpPn4
pornel 3y ago
> I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees No, Bjarne needs to realize that RAII and smart pointers are an old concept now, and they have shown to be insufficient, for decades now. The bar for safety has been raised, and the Modern C++ is so behind, they don't even understand the issue, and still talk like it's about the C sins, or programmers not using it properly, or "but what about other bugs?". The contemporary C++ is still a safety-third design where safety always loses to performance and backwards compatibility. The std::span has been standardized without .at(), and they're just getting around to adding it. Bounds checking by default on `operator[]` is one thing where C++ could be on par with Rust right now, but that is going to be relegated to an optional profile.
- deleted 3y ago
  [deleted]
- b20000 3y ago
  not all applications need safety it is wrong to force safety onto the programmer especially if there is a cost to be paid to obtain it
  - coldbrewed 3y ago
    That's an easy statement to make but in practice it's no longer acceptable; the Internet has become far too hostile and code that's "never going to be connected to the Internet" constantly does.
    - logicchains 3y ago
      [flagged]
    - b20000 3y ago
      not all devices are connected to the internet and writing software in c++ does not imply the software is unsafe
- junon 3y ago
  Anecdotally, I feel like I wrote safer C code because at least I fully understood the behavior of the few standard library functions I used - both the good and the bad. C++ always had that question mark of if you were fully understanding all of the invariants the library placed on you to uphold. That being said, I've fallen in love with Rust and have no intention of ever going back to C or C++.
  - PartiallyTyped 3y ago
    I have a big gripe with rust and other modern languages like zig, and it’s difficult to reconcile it. The gripe is that after using them for a while, anything else like java, python, c++ or C is underwhelming, boring and tedious, an exercise in how long you can uphold standards until you fall back to language defaults.
    - pjmlp 3y ago
      What these languages show, is something anyone used to compiled BASIC, Pascal dialects like Object Pascal, Modula-2 and such, already knew back in the day. We had languages that were a pleasure to use for high level programming abstractions, while at the same time, provided the necessary features to go all the way down, even inline Assembly if it must be. Without the culture that tooling much be hard, rather developers are users as well. Thankfully a new generation of developers is bringing this culture back.
      - PartiallyTyped 3y ago
        > Without the culture that tooling much be hard, rather developers are users as well. I don't follow this. Could you elaborate? I think the current culture is that tooling must be smart, accessible, and very well written, e.g rust (cargo, rustc, clippy, rust-analyzer), go coming with everything, same for gleam. Even zig is a better build system for C programs than most buildsystems for C.
        pjmlp 3y ago
        I am talking about the C tooling culture, specially when comparing how compilers, linkers and makefiles are exposed, versus the Xerox PARC programming model that was largely adopted by other ecosystems. Think TP, Delphi, VB, .NET, Smalltalk, Common Lisp, Clipper, Eiffel, MacOS AppToolbox, Java,...
- pjmlp 3y ago
  The problem is that he is shouting to windmills, because the community at large doesn't care about all the features and tooling he keeps mentioning. Also some of that tooling is still quite buggy, e.g. VC++ and clang lifetime checkers. Same applies to Herb Sutter's efforts, as of his recent blog post. It doesn't matter how much tooling there has been available on the C and C++ ecosystem, a large majority will keep programming as they always did unless forced by external factors to change their ways. Lint was created in 1979, and to this day many developers refuse to adopt static analysis on their C and C++ projects, let alone more modern tooling. Technology cannot change community culture.
orf 3y ago
> Of the billions of lines of C++, few completely follow modern guidelines AKA, we’ve created a messy monster that’s out of our control, please don’t blame us.
- 72deluxe 3y ago
  But it seems like blaming the inventor of knives for using them dangerously? Knives are really useful for cutting things. The same goes for cars. Thousands of people have died in car accidents yet nobody is proposing that we replace cars because if you use them correctly they really are quite useful. The same goes for C++. I see a lot of C++-bashing on this thread (it seems very popular on HN?) but it is a useful language. I have worked with plenty of people who used it wrong but to throw the entire thing into the bin is blaming the wrong thing. People can be dangerous drivers even if the car is really good.
  - orf 3y ago
    Sure, but it’s more like someone invented and sold a car then strapped a bunch of knives to it.
biomcgary 3y ago
Maybe they need to fork a version of C++ that doesn't have all the dangerous features and forces developers to write only safe C++. It could be called C++--.
- ttfkam 3y ago
  …or called Carbon. https://en.wikipedia.org/wiki/Carbon_(programming_language) https://en.wikipedia.org/wiki/Carbon_(programming_language)
  - pjmlp 3y ago
    Carbon is still a research project, the authors are the first to state to use Rust if one doesn't need to migrate existing C++ code.
    - ttfkam 3y ago
      The overarching point is to avoid new C++ code whenever possible. Carbon isn't intended to compete with or replace Rust. It's for more easily and seamlessly migrating away from C++ and its worst foot cannons.
- pjmlp 3y ago
  See Circle.
Scubabear68 3y ago
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.
- zenbowman 3y ago
  I would argue that it made sense for performance-sensitive code until the maturation of Rust, so it made sense even in 2015. But not today.
  - b20000 3y ago
    you pay a performance penalty and i don’t want to learn another language and package management system
- b20000 3y ago
  makes sense to me
- dvngnt_ 3y ago
  are there any game engines for AAA development in rust?
- pjmlp 3y ago
  Versus C, it definitly made lots of sense. For me it was the only language I could see myself using after getting used to Object Pascal quality of life, in tooling, type safety, and language features. C felt jurassic already in 1993, and there wasn't any other portable alternative I could reach for. However that copy-paste compatibility with C is what definitly has made it unsuitable for writing safe code nowadays, specially with the C culture that is now left. Those of us that like C++, but also are on the safety side, have already embraced other programming languages, relegating C++ for the absolute must use cases.
Shawnecy 3y ago
About a year ago, Stroustrup wrote a similar response[0] to a similar statement from the NSA[1]. I wasn't really convinced and am more in agreement with this response to Stroustrup[2] from an embedded Linux developer. To quote from near the end of their response to Stroustrup: > In the meantime, it is unfair for Dr. Stroustrup to call safe programming languages novelties or to pretend that C++ isn’t already far behind the times on this. This was already an important criticism of C++ decades ago, when Java first came out in the 90’s and was referred to as a “managed programming language.” I'm not really buying that C++ is really all that commonly safe when we have stats like these[3]: > A recent study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues. Google estimated that 90% of Android vulnerabilities are memory safety issues. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues 1. > The Slammer worm from 2003 was a buffer overflow (out-of-bounds write). So was WannaCry (out-of-bounds write). The Trident exploit against iPhones used three different memory safety vulnerabilities (two use-after-frees and an out-of-bounds read). HeartBleed was a memory safety problem (out-of-bounds read). Stagefright on Android too (out-of-bounds writes). The Ghost vulnerability in glibc? You betcha (out-of-bounds write). [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... [1]: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... [2]: https://www.thecodedmessage.com/posts/stroustrup-response/ https://www.thecodedmessage.com/posts/stroustrup-response/ [3]: https://www.memorysafety.org/docs/memory-safety/ https://www.memorysafety.org/docs/memory-safety/
- alphabeta567 3y ago
  > I'm not really buying that C++ is really all that commonly safe when we have states like these[3]: It's not. At this point, I cannot in good faith say that he is not lying, either to us or himself.
  - kstrauser 3y ago
    I don't think he's lying to us. I think he genuinely believes that everyone is using it wrong. Although that's not much of a defense when he was the one who invented the wrong ways to use it.
gigel82 3y ago
I agree; you can write perfectly safe and noncompromisingly performant code in C++ much better than any language today. It's genuinely difficult to understand why Rust gets rammed down everyone's throats lately; do they really think developers coming out of universities today are too stupid to grasp memory management? If that's the case, why not have everyone code in Scratch? That memo reads like "to avoid wet pants, everyone should now pee sitting down"; some of us can aim...
- alphabeta567 3y ago
  Right, tell me you've never made an off by one error. Or had a dangling reference in your program.
- kstrauser 3y ago
  > It's genuinely difficult to understand why Rust gets rammed down everyone's throats lately; do they really think developers coming out of universities today are too stupid to grasp memory management? Yes. Experimentally, that is absolutely correct. New programmers are bad at memory management. So are old ones. So are experts, unless you seriously want to argue that the OpenBSD gang are a bunch of amateurs. The best C/C++ programmers in the world still write code with memory flaws today. At some point you have to say, you know, maybe it's not the programmers that are the problem.
- pornel 3y ago
  We've been trying the "just don't write bugs" strategy for over 40 years now, and it's not working. Framing this as a problem with people being too stupid is a completely unproductive mix of hubris and elitism. In the disciplines where real safety is required (like engineering, aviation, medicine), it's accepted that people will make mistakes. When a system can fail catastrophically due to a simple human error, it's the system that is broken, and needs to be made more robust.
  - gigel82 3y ago
    I didn't say people are too stupid. On the contrary, we onboard fresh grads onto our large C++ code base every once in a while and they all seem to grasp the concepts just fine. I'm wondering if most folks throwing shade at C++ had used pre-C++11 toolsets and just have bad memories of the experience. FWIW, I find modern C++ genuinely great to read / easy to parse by humans (same for similar languages like C#, Java, JavaScript/Typescript) whereas reading Rust (in particular function definitions) is painful.
zenbowman 3y ago
I understand wanting to defend your baby, and I think C++ was VASTLY better than most other languages for performance sensitive code until maybe 5 years ago - but the combination of memory safety and thread safety that Rust offers means that there are very few situations where C++ is the appropriate choice for a new project now. I have written professionally in C++ for 20 years now, and I would pick Rust for a _new_ project/fresh codebase in a heartbeat. tokio alone is so vastly superior to anything you can do in async C++ that it makes zero sense to select C++ for a _new_ project (obviously if you have an existing codebase the price of interop may not be worth it). Bjarne is being deliberately obtuse here.
GoblinSlayer 3y ago
>Improving safety has been an aim of C++ from day one and throughout its evolution. Wut, pretty sure the first aim was compatibility with C, the second aim was flexibility and overengineering, the third aim was performance. Safety was never on the list.

55 points by ben_s 3y ago

On a recent CppCon panel[0], after much discussion of ecosystem-wide safety and how "safe" programming languages don't automatically create "safe" systems (which has merit), he basically had to shrug his shoulders when someone asked about thread safety. [0]https://www.youtube.com/watch?v=R10pXWHpPn4 https://www.youtube.com/watch?v=R10pXWHpPn4

pornel 3y ago

> I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees No, Bjarne needs to realize that RAII and smart pointers are an old concept now, and they have shown to be insufficient, for decades now. The bar for safety has been raised, and the Modern C++ is so behind, they don't even understand the issue, and still talk like it's about the C sins, or programmers not using it properly, or "but what about other bugs?". The contemporary C++ is still a safety-third design where safety always loses to performance and backwards compatibility. The std::span has been standardized without .at(), and they're just getting around to adding it. Bounds checking by default on `operator[]` is one thing where C++ could be on par with Rust right now, but that is going to be relegated to an optional profile.

deleted 3y ago
[deleted]
b20000 3y ago
not all applications need safety it is wrong to force safety onto the programmer especially if there is a cost to be paid to obtain it
- coldbrewed 3y ago
  That's an easy statement to make but in practice it's no longer acceptable; the Internet has become far too hostile and code that's "never going to be connected to the Internet" constantly does.
  - logicchains 3y ago
    [flagged]
  - b20000 3y ago
    not all devices are connected to the internet and writing software in c++ does not imply the software is unsafe
junon 3y ago
Anecdotally, I feel like I wrote safer C code because at least I fully understood the behavior of the few standard library functions I used - both the good and the bad. C++ always had that question mark of if you were fully understanding all of the invariants the library placed on you to uphold. That being said, I've fallen in love with Rust and have no intention of ever going back to C or C++.
- PartiallyTyped 3y ago
  I have a big gripe with rust and other modern languages like zig, and it’s difficult to reconcile it. The gripe is that after using them for a while, anything else like java, python, c++ or C is underwhelming, boring and tedious, an exercise in how long you can uphold standards until you fall back to language defaults.
  - pjmlp 3y ago
    What these languages show, is something anyone used to compiled BASIC, Pascal dialects like Object Pascal, Modula-2 and such, already knew back in the day. We had languages that were a pleasure to use for high level programming abstractions, while at the same time, provided the necessary features to go all the way down, even inline Assembly if it must be. Without the culture that tooling much be hard, rather developers are users as well. Thankfully a new generation of developers is bringing this culture back.
    - PartiallyTyped 3y ago
      > Without the culture that tooling much be hard, rather developers are users as well. I don't follow this. Could you elaborate? I think the current culture is that tooling must be smart, accessible, and very well written, e.g rust (cargo, rustc, clippy, rust-analyzer), go coming with everything, same for gleam. Even zig is a better build system for C programs than most buildsystems for C.
      - pjmlp 3y ago
        I am talking about the C tooling culture, specially when comparing how compilers, linkers and makefiles are exposed, versus the Xerox PARC programming model that was largely adopted by other ecosystems. Think TP, Delphi, VB, .NET, Smalltalk, Common Lisp, Clipper, Eiffel, MacOS AppToolbox, Java,...
pjmlp 3y ago
The problem is that he is shouting to windmills, because the community at large doesn't care about all the features and tooling he keeps mentioning. Also some of that tooling is still quite buggy, e.g. VC++ and clang lifetime checkers. Same applies to Herb Sutter's efforts, as of his recent blog post. It doesn't matter how much tooling there has been available on the C and C++ ecosystem, a large majority will keep programming as they always did unless forced by external factors to change their ways. Lint was created in 1979, and to this day many developers refuse to adopt static analysis on their C and C++ projects, let alone more modern tooling. Technology cannot change community culture.

orf 3y ago

> Of the billions of lines of C++, few completely follow modern guidelines AKA, we’ve created a messy monster that’s out of our control, please don’t blame us.

72deluxe 3y ago
But it seems like blaming the inventor of knives for using them dangerously? Knives are really useful for cutting things. The same goes for cars. Thousands of people have died in car accidents yet nobody is proposing that we replace cars because if you use them correctly they really are quite useful. The same goes for C++. I see a lot of C++-bashing on this thread (it seems very popular on HN?) but it is a useful language. I have worked with plenty of people who used it wrong but to throw the entire thing into the bin is blaming the wrong thing. People can be dangerous drivers even if the car is really good.
- orf 3y ago
  Sure, but it’s more like someone invented and sold a car then strapped a bunch of knives to it.

biomcgary 3y ago

Maybe they need to fork a version of C++ that doesn't have all the dangerous features and forces developers to write only safe C++. It could be called C++--.

ttfkam 3y ago
…or called Carbon. https://en.wikipedia.org/wiki/Carbon_(programming_language) https://en.wikipedia.org/wiki/Carbon_(programming_language)
- pjmlp 3y ago
  Carbon is still a research project, the authors are the first to state to use Rust if one doesn't need to migrate existing C++ code.
  - ttfkam 3y ago
    The overarching point is to avoid new C++ code whenever possible. Carbon isn't intended to compete with or replace Rust. It's for more easily and seamlessly migrating away from C++ and its worst foot cannons.
pjmlp 3y ago
See Circle.

Scubabear68 3y ago

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.

zenbowman 3y ago
I would argue that it made sense for performance-sensitive code until the maturation of Rust, so it made sense even in 2015. But not today.
- b20000 3y ago
  you pay a performance penalty and i don’t want to learn another language and package management system
b20000 3y ago
makes sense to me
dvngnt_ 3y ago
are there any game engines for AAA development in rust?
pjmlp 3y ago
Versus C, it definitly made lots of sense. For me it was the only language I could see myself using after getting used to Object Pascal quality of life, in tooling, type safety, and language features. C felt jurassic already in 1993, and there wasn't any other portable alternative I could reach for. However that copy-paste compatibility with C is what definitly has made it unsuitable for writing safe code nowadays, specially with the C culture that is now left. Those of us that like C++, but also are on the safety side, have already embraced other programming languages, relegating C++ for the absolute must use cases.

Shawnecy 3y ago

About a year ago, Stroustrup wrote a similar response[0] to a similar statement from the NSA[1]. I wasn't really convinced and am more in agreement with this response to Stroustrup[2] from an embedded Linux developer. To quote from near the end of their response to Stroustrup: > In the meantime, it is unfair for Dr. Stroustrup to call safe programming languages novelties or to pretend that C++ isn’t already far behind the times on this. This was already an important criticism of C++ decades ago, when Java first came out in the 90’s and was referred to as a “managed programming language.” I'm not really buying that C++ is really all that commonly safe when we have stats like these[3]: > A recent study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues. Google estimated that 90% of Android vulnerabilities are memory safety issues. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues 1. > The Slammer worm from 2003 was a buffer overflow (out-of-bounds write). So was WannaCry (out-of-bounds write). The Trident exploit against iPhones used three different memory safety vulnerabilities (two use-after-frees and an out-of-bounds read). HeartBleed was a memory safety problem (out-of-bounds read). Stagefright on Android too (out-of-bounds writes). The Ghost vulnerability in glibc? You betcha (out-of-bounds write). [0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... [1]: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... [2]: https://www.thecodedmessage.com/posts/stroustrup-response/ https://www.thecodedmessage.com/posts/stroustrup-response/ [3]: https://www.memorysafety.org/docs/memory-safety/ https://www.memorysafety.org/docs/memory-safety/

alphabeta567 3y ago
> I'm not really buying that C++ is really all that commonly safe when we have states like these[3]: It's not. At this point, I cannot in good faith say that he is not lying, either to us or himself.
- kstrauser 3y ago
  I don't think he's lying to us. I think he genuinely believes that everyone is using it wrong. Although that's not much of a defense when he was the one who invented the wrong ways to use it.

gigel82 3y ago

I agree; you can write perfectly safe and noncompromisingly performant code in C++ much better than any language today. It's genuinely difficult to understand why Rust gets rammed down everyone's throats lately; do they really think developers coming out of universities today are too stupid to grasp memory management? If that's the case, why not have everyone code in Scratch? That memo reads like "to avoid wet pants, everyone should now pee sitting down"; some of us can aim...

alphabeta567 3y ago
Right, tell me you've never made an off by one error. Or had a dangling reference in your program.
kstrauser 3y ago
> It's genuinely difficult to understand why Rust gets rammed down everyone's throats lately; do they really think developers coming out of universities today are too stupid to grasp memory management? Yes. Experimentally, that is absolutely correct. New programmers are bad at memory management. So are old ones. So are experts, unless you seriously want to argue that the OpenBSD gang are a bunch of amateurs. The best C/C++ programmers in the world still write code with memory flaws today. At some point you have to say, you know, maybe it's not the programmers that are the problem.
pornel 3y ago
We've been trying the "just don't write bugs" strategy for over 40 years now, and it's not working. Framing this as a problem with people being too stupid is a completely unproductive mix of hubris and elitism. In the disciplines where real safety is required (like engineering, aviation, medicine), it's accepted that people will make mistakes. When a system can fail catastrophically due to a simple human error, it's the system that is broken, and needs to be made more robust.
- gigel82 3y ago
  I didn't say people are too stupid. On the contrary, we onboard fresh grads onto our large C++ code base every once in a while and they all seem to grasp the concepts just fine. I'm wondering if most folks throwing shade at C++ had used pre-C++11 toolsets and just have bad memories of the experience. FWIW, I find modern C++ genuinely great to read / easy to parse by humans (same for similar languages like C#, Java, JavaScript/Typescript) whereas reading Rust (in particular function definitions) is painful.

zenbowman 3y ago

I understand wanting to defend your baby, and I think C++ was VASTLY better than most other languages for performance sensitive code until maybe 5 years ago - but the combination of memory safety and thread safety that Rust offers means that there are very few situations where C++ is the appropriate choice for a new project now. I have written professionally in C++ for 20 years now, and I would pick Rust for a _new_ project/fresh codebase in a heartbeat. tokio alone is so vastly superior to anything you can do in async C++ that it makes zero sense to select C++ for a _new_ project (obviously if you have an existing codebase the price of interop may not be worth it). Bjarne is being deliberately obtuse here.

GoblinSlayer 3y ago

>Improving safety has been an aim of C++ from day one and throughout its evolution. Wut, pretty sure the first aim was compatibility with C, the second aim was flexibility and overengineering, the third aim was performance. Safety was never on the list.