7 ms·

Rust Safety Is Not Superior to C++, Bjarne Stroustrup Says – Slashdot

54 points by isaacfrond 4y ago

viraptor 4y ago
Oooff... I expected better from him. That's a lot of defensiveness and "in my use cases, for a limited subset, tools could easily, ...". C++ has been improving and some things are better. I'd rather read about those.
- arp242 4y ago
  In his defence: he's been working on C++ for 44 years now. Or to put it different: he's been working on it from the age of 28 to 72 today. It's a huge part of his professional career, and his life in general. People are emotional creatures; I'm sure Bjarne is no exception. I find it hard to fault them too much it, especially as I'm not so confident I'd do any better in similar circumstances, and I've seen others do a lot worse under similar circumstances. C++ isn't going to vanish any time soon no matter what, so it's good people keep working on it – a few misguided comments here or there? Meh.
spoiler 4y ago
I can't help but feel like he's missing the point a bit. Sure, you can get a few Rust features in C++ if you (1) stick to specific syntax forms or else tools can't detect stuff or report false positives (2) use a collection of third party tools that work together by accident more than by design, so they end up being glued together differently in each project, and (3) they're not part of the language. I've not worked with Visual C++ much (used it once and thought the CLI pointers were a cool feature, though), so maybe that's better. However, my experience on Linux has always been… Uncomfortable? I don't know what to call it. Sure, all of these things kinda and almost work. Technically they make things marginally better. So, he's not wrong, but only by the strictest possible definition of "wrong". And Jesus Christ, they always made me feel like I stepped into a time machine and traveled back 30 years (and I'm only turning 30 this year), and induced so much friction into both set up and workflow. Rust on the other hand? I don't have to think about it any of those, and it borrows (no pun intended) great FP type system features to boot. Also, I don't know what went wrong with C++ Concept, but I was excited about them initially, and now I'm just underwhelmed by them. The coroutine stuff is also a bit frustrating. C++ is a language that has jaded me with a thousand small frustrations over the years. I still have a small hope that it'll one day rebound (as I used to write it for a long time), but in the mean time I'll stick to Rust. Also, since he's deliberately chosen to be petty about memory safety in Rust, it probably doesn't warrant addressing, but I'll take the troll-bait this time: nobody EVER said memory safety is the ONLY safety. Ever. I've not seen a single person make that claim, or tout Rust as a "safe" language. Memory safety DOES however eliminate a whole category of bugs (a lot of which can be security or stability bugs in real world environments). That's literally all there is to it. Edit: my experiences predate a having a Cpp LSP that works (idk if that has changed in the last few years)
- pjmlp 4y ago
  He kind of does, in the sense that stuff like span do require opt-in configuration for bounds checking, and both clang-tidy and VC++ Core Guidline checkers still leave too much room for improvements. I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care. Which is also visible in surveys like the ones published by JetBrains, where unit testing and static analsys tooling never get that high.
  - spoiler 4y ago
    > however the production code I get to occasionally look into proves that a large majority just doesn't care. In part, I think the issue you described is that usually with C++, the correct solution is the more obscure one, and usually much longer and sometime even harder to parse (by a human), while the incorrect (or less correct) solution seems idiomatic and obvious. I think this would probably not have been an issue if the language shed baggage as it evolved.
  - simplotek 4y ago
    > I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care. I don't agree, specially considering legacy code. Those of us still have to deal with an awful lot of code written 10 or 20 years ago still have to maintain code that juggles pointers and references around in ways that are hard to track ownership, and migrating this code to C++11 is no simple task. This doesn't mean people don't care. It just means the industry cannot afford getting whole teams to spend a couple of years on sabbatical to refactor legacy code and pay it's legacy debt. This is perhaps the biggest strawman that Rust fanatics use to criticize all things that isn't written in Rust. They pick their small little greenfield modules and boast how safe and perfect it is, and proceed to criticize all legacy production code whose teams can't even spare time to fix long standing bugs, let alone pay off technical debt. And that's somehow something Rust fixes?
temp2022account 4y ago
Modern C++ has many tricks to get memory and thread safety pinned down, but in my experience the new capabilities are entirely subsumed by old code. If Bjarne wants C++ to be a language worth choosing, we need some options to remove all of the footguns from before c++11, and remove the redundancies with partially-well-done new features to yield a single-well-done way of handling memory and multithreading. If Bjarne put something akin to Rust's Editions in C++, and regularly removed poor designs, then yes C++ would be pretty close to Rust for new projects.
- JonChesterfield 4y ago
  No can do. That would break backwards compatibility (thou shalt not do so) or fragment the language (likewise). What we can have is increasingly elaborate syntax and progressively better tooling.
- steveklabnik 4y ago
  Editions were proposed in 2017, but were postponed. I haven’t heard of any forward movement on it lately.
  - pjmlp 4y ago
    They were taken down, because they cannot cover all scenarios of language evolution, in grammar, language semantics, across compilers, binary libraries and ABI, as such failed to gain wide support.
    - steveklabnik 4y ago
      This was not the reasons cited in the actual votes to postpone https://github.com/cplusplus/papers/issues/631#issuecomment-585231742 https://github.com/cplusplus/papers/issues/631#issuecomment-... Not that that means you're strictly wrong, mind you, just that only textual inclusion issues and template issues were voted on as being blocking at that time.
ivan_gammel 4y ago
Off topic, but I’m surprised Slashdot is still alive. Have not heard of it for a few years.
- arp242 4y ago
  The banner it gave me made me laugh: "Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 30 million monthly users. It takes less than a minute. Get new users downloading your project releases today!" SourceForge: from de-facto standard open source tooling to "please allow us to mirror your GitHub".
  - IYasha 4y ago
    That's what happens when you make questionable moves and have M$ as a competitor.
    - arp242 4y ago
      GitHub ate SourceForge's pie long before Microsoft bought it. The questionable moves also came long after the pie had been eaten.
xorvoid 4y ago
Well, he’s wrong, objectively so. And its easy to prove. But I can’t blame him for feeling attacked and wanting to defend the work he’s poured his entire life into. (For the record: I’m a lifelong C/C++ programmer who has written large systems in it)
snorkel 4y ago
Cpp offers thread safety but rust insists on it.
- Jweb_Guru 4y ago
  It "offers" thread safety in the sense that it's theoretically possible to write a thread safe program in C++. It certainly makes it about as difficult as humanly possible to do so, however, especially when they include stuff like the consume ordering that isn't even well-defined.
sfpotter 4y ago
For what it's worth, the word "Rust" doesn't actually appear in the "A call to action: ..." document. It does appear in the original NSA document, but not in the part of the text that Stroustrup quoted. Not sure if this was intentional or not, but if read carefully the Slashdot post does appear to be misquoting him.
- JeremyBanks 4y ago
  [dead]
- steveklabnik 4y ago
  Rust certainly appears in at least one version of the paper; they even call it “RUST” through most of it.
  - sfpotter 4y ago
    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... If you ctrl-f "rust" in this PDF, there are zero hits.
    - steveklabnik 4y ago
      Ohh, you know what? There's two, similar papers. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2759r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... This is the one that had a ton of discussion over the last few days. The one you linked from the /. article is much, much shorter, and has only Bjarne as the author, unlike the other, which has co-authors.
      - arp242 4y ago
        This is highly confusing; people are talking past each other because the document you're talking about and linked isn't linked in the /. article at all; it's not even linked in the PDF That /. links to. I never liked these crummy /. mini-writeups that may or may not be accurate.
justinsaccount 4y ago
> make it possible to write better, safer, and more efficient C++ Right, but is it still possible to write bad, unsafe, inefficient C++ that looks indistinguishable from the safe kind?
JeremyBanks 4y ago
[dead]
dzonga 4y ago
can modern c++ be safe ? yes !! is modern c++ so complex, big with a huge surface area to shoot yourself, yes. that's the problem with C++ it's such a huge language that knowing to do the right thing is difficult.
witheld 4y ago
Sure Bjarne, you’re right, if you follow best practices- use static analyzer- special compiler time options. If we research and develop, we can make a safe C++. But if you wanna write safe code, from scratch, because you don’t want to recycle your dangerous old C++ codebase; then why would you write that new code in C++ when rust is ready and here to do it?
- imtringued 4y ago
  Ok but the static analysis tools that are equivalent to what Rust does involve bolting a borrow checker on to C++ at which point you might question what you are trying to achieve because you can't reuse any of the existing C++ code in this configuration as all the other C++ developers failed to use your specific static code analysis setup.
  - Ar-Curunir 4y ago
    And also, unlike Rust, C++ was not designed to support the borrow checker, so any code that you’re writing might not even be analysable properly by the C++ borrow checker
    - pjmlp 4y ago
      See here for the current status in VC++ as of last December. Plenty of work still to do. https://devblogs.microsoft.com/cppblog/high-confidence-lifetime-checks-in-visual-studio-version-17-5-preview-2/ https://devblogs.microsoft.com/cppblog/high-confidence-lifet...
      - Jweb_Guru 4y ago
        Sure. As was obvious from the beginning for anyone who's tried to do lifetime analysis on mostly-unannotated C++, this is going to become another "bug reporting" tool that doesn't accomplish anything close to what Rust does. Most likely, all it will do is catch a few of the more obvious bugs so they pass various tutorial examples people use to show why you need borrow checking, leading C++ programmers will believe the problem is solved when it isn't.
thesuperbigfrog 4y ago
Real world projects using C++ are seeing decreases in security vulnerabilities when migrating to Rust: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1 https://security.googleblog.com/2022/12/memory-safe-language... While C++ with the latest features should be secure enough in theory, in practice practically no one is using all the latest features just right to achieve the needed security. Sorry, the NSA report is correct. Using C or C++ opens your project up to memory safety risks. Use a memory safe language if at all possible.
- gigel82 4y ago
  I'm sure you'd be seeing the same results by rewriting the project in modern C++ instead of Rust.
  - thesuperbigfrog 4y ago
    >> I'm sure you'd be seeing the same results by rewriting the project in modern C++ instead of Rust. I would personally choose Rust over C++. I dislike the number of gotchas that C++ has and I think the language has gotten too big and complex to use safely. In the article I linked above, the Google Android team stated: "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." Their C++ code requires more static analysis tools and fuzzers and does not have a comparable record. If modern C++ were as safe as Rust then why wouldn't they just use modern C++? It would be a lower effort rewrite and would not need new compilers.
    - simplotek 4y ago
      > I would personally choose Rust over C++. I dislike the number of gotchas that C++ has and I think the language has gotten too big and complex to use safely. This take sounds like fomo mixed with cargo cult programming. When you write something in C++, nothing forces you to use all features of C++. There is no bingo card you have to fill to get your project to compile. You just pick the things you feel serves your purposes, and stick with them. I don't really understand this irrational take. It's like claiming they don't want to speak in English because the dictionary is too large and some words are too tricky to spell to use in a conversation.
jbirer 4y ago
We were taught C in high school (East Europe ftw). I always longed for a language that had some memory safety and high level abstractions while not being a clusterfuck like C++. I don't think we'll see C++ in the next 10 years that much if they don't fix the ecosystem bloat issue.
- pxmpxm 4y ago
  it's called Java
- JonChesterfield 4y ago
  D might be what you're looking for.
duped 4y ago
First off there's nothing about Rust here. But this quote: > In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains Tells me he doesn't really "get it." People do not follow the core guidelines, and other languages are designed such that there aren't guidelines. There's a type checker (wave hands here) that proves your code and its dependencies are memory safe (within some sane definition). Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong.
- everforward 4y ago
  > Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong. This seems like it's split between compiled and interpreted languages, no? Typescript and Python (I believe) will let you override types in their type system, I assume because doing so has no effect on the underlying code. I'm assuming that compiled languages with integrated type-checkers actually use the type checker for allocations so changing types has runtime implications. E.g. Typescript doesn't care if you use `as` to force the type of a variable because it has no impact on the runtime. Javascript will create objects and allocate memory the same regardless of what Typescript thinks the type is. That's not true of something like Go, where changing the type of a variable would require different allocations and changing a struct to a string would break low-level features like GC.
  - duped 4y ago
    It's not interpreted vs dynamic, it's static vs dynamic typing. Python and Typescript are dynamically typed languages with optional AOT type checking, meaning it is valid to write code that would fail typechecking or is impossible to typecheck at parse-time (in other words, types are only guaranteed to be checked when the code is executed, but types are always checked!). There's also a sliding scale of "weak" to "strong" typing (I don't want to attempt to define it). C is the canonical example of a "weakly" typed languages, but imo C++ fits that as well - unless you follow the idioms of "type safe" programming, which makes it difficult for a programmer to write code that is not type checked. The difference between a weak-but-statically typed language and dynamically typed language is that it's possible for a programmer to write code that is never type checked, leading to potentially undefined behavior. C++ needs a notion of "type safe" programming because it is possible for a programmer to write such code. Contrast to a language like Rust or Haskell, where it's close to impossible to write type-unsafe code (without explicitly saying you want to). My point is that implying "safe" programming also implies type safety misunderstands that such safety is close to meaningless in safe programming languages. It's just so much harder to write type-unsafe code it's kind of pointless to bring it up, unless you're writing C and C++.
amluto 4y ago
In very partial defense of this idea: > There is not just one definition of "safety", and we can achieve a variety of kinds of safety I agree, but C++ and Rust both fail at what I could consider a major form of safety not too far below memory safety. It might be called “capability safety” or “effect safety”: a function call should not be able to have side effects or read data outside that explicitly permitted by the caller (or importer or program manifest or whatever). I would consider a form of “unsafe”-like escape hatch acceptable so long as using that escape hatch is itself treated as a capability. Rust and C++ don’t do this at all, although I could imagine it being retrofitted into Rust or a similar language. Java sort of tried, and it was a near complete failure on many counts. Several experimental languages have this as an explicit goal. Some container and VM systems attempt this sort of security. Sandstorm was a notable example.
- spoiler 4y ago
  I guess you want something like the IO monad in Haskell and similar languages. I'm not sure how that would or could slot in Rust. I guess all IO could return something like an IOResult (although, I guess Result<T, E: IOError> could do that too that, but it's not "enforceable" in the same way it is in Haskell). I like the idea in theory, but depending on how it's implemented at the language level, it could end up being a bit hit or miss.
  - amluto 4y ago
    The IO monad is sort of on the right track, but it’s far too coarse grained. Here are some efforts in the right direction: https://github.com/austral/austral https://github.com/austral/austral http://www.erights.org/ http://www.erights.org/ Deno does something along these lines too. WASM does, too, if you squint hard at it.
    - spoiler 4y ago
      Ah, I like this idea. I've played with Deno a bit, and loved the permissions feature. It would be nice to see some version of this in Rust too
    - 4y ago
programmer_dude 4y ago
LOL.
JustLurking2022 4y ago
Sure, you can write safe C++ code but it's up to you to know all the patterns/syntax to do so. Other languages give you compile time errors when you try to do something unsafe.
- gigel82 4y ago
  I prefer taking the training wheels off the bike after I learn how to bike...
  - lilyball 4y ago
    I prefer taking my seatbelt off after I learn how to drive...
    - MathMonkeyMan 4y ago
      I prefer to stay inside...
none_to_remain 4y ago
I'm so old I remember when we were all supposed to be writing Haskell for everything by now. The immutability would finally make us safe
_trackno5 4y ago
While I agree with Stroustrup that there's a rush to get memory safety bolted onto C++, it's pretty obvious he doesn't understand what good design actually is: > I envision compiler options and code annotations for requesting rules to be enforced. The most obvious would be to request guaranteed full type-and-resource safety. You'd think someone that worked on a compiler for decades would come to the realisation that opt-in safety is just dumb. You want everything to be safe by default, despite the performance implications, and then allow programmers to peel back safety features explicitly where they are not needed. You don't buy a gun and the safety lock as an add-on. Borrowing from Donald Norman and his Design of Everyday Things book, safe programming in C and C++ relies too much on "knowledge in the head" instead of "knowledge in the world" in order to do it correctly. You don't need the big borrow-checker hammer from Rust to be a lot better. Most CVEs (memory safety related) are about out-of-bounds writes/reads. You could mitigate a huge chunk of those problems by just doing something as sensible as having a well defined concept of slices with bounds checking turned on by default. But this seems to elude the C and the C++ committee for some weird reason.
gxt 4y ago
I've never had an unsafe-free rust program crash by segmentation fault, or crash at all. But I remember having off-by-one errors doing just that in basic for-loops in C++.
IYasha 4y ago
Old man is right. <3

54 points by isaacfrond 4y ago

Oooff... I expected better from him. That's a lot of defensiveness and "in my use cases, for a limited subset, tools could easily, ...". C++ has been improving and some things are better. I'd rather read about those.

arp242 4y ago
In his defence: he's been working on C++ for 44 years now. Or to put it different: he's been working on it from the age of 28 to 72 today. It's a huge part of his professional career, and his life in general. People are emotional creatures; I'm sure Bjarne is no exception. I find it hard to fault them too much it, especially as I'm not so confident I'd do any better in similar circumstances, and I've seen others do a lot worse under similar circumstances. C++ isn't going to vanish any time soon no matter what, so it's good people keep working on it – a few misguided comments here or there? Meh.

spoiler 4y ago

I can't help but feel like he's missing the point a bit. Sure, you can get a few Rust features in C++ if you (1) stick to specific syntax forms or else tools can't detect stuff or report false positives (2) use a collection of third party tools that work together by accident more than by design, so they end up being glued together differently in each project, and (3) they're not part of the language. I've not worked with Visual C++ much (used it once and thought the CLI pointers were a cool feature, though), so maybe that's better. However, my experience on Linux has always been… Uncomfortable? I don't know what to call it. Sure, all of these things kinda and almost work. Technically they make things marginally better. So, he's not wrong, but only by the strictest possible definition of "wrong". And Jesus Christ, they always made me feel like I stepped into a time machine and traveled back 30 years (and I'm only turning 30 this year), and induced so much friction into both set up and workflow. Rust on the other hand? I don't have to think about it any of those, and it borrows (no pun intended) great FP type system features to boot. Also, I don't know what went wrong with C++ Concept, but I was excited about them initially, and now I'm just underwhelmed by them. The coroutine stuff is also a bit frustrating. C++ is a language that has jaded me with a thousand small frustrations over the years. I still have a small hope that it'll one day rebound (as I used to write it for a long time), but in the mean time I'll stick to Rust. Also, since he's deliberately chosen to be petty about memory safety in Rust, it probably doesn't warrant addressing, but I'll take the troll-bait this time: nobody EVER said memory safety is the ONLY safety. Ever. I've not seen a single person make that claim, or tout Rust as a "safe" language. Memory safety DOES however eliminate a whole category of bugs (a lot of which can be security or stability bugs in real world environments). That's literally all there is to it. Edit: my experiences predate a having a Cpp LSP that works (idk if that has changed in the last few years)

pjmlp 4y ago
He kind of does, in the sense that stuff like span do require opt-in configuration for bounds checking, and both clang-tidy and VC++ Core Guidline checkers still leave too much room for improvements. I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care. Which is also visible in surveys like the ones published by JetBrains, where unit testing and static analsys tooling never get that high.
- spoiler 4y ago
  > however the production code I get to occasionally look into proves that a large majority just doesn't care. In part, I think the issue you described is that usually with C++, the correct solution is the more obscure one, and usually much longer and sometime even harder to parse (by a human), while the incorrect (or less correct) solution seems idiomatic and obvious. I think this would probably not have been an issue if the language shed baggage as it evolved.
- simplotek 4y ago
  > I love his talks, and how he tries to push the C++ community to write better code and less "C with C++ compiler" code style, however the production code I get to occasionally look into proves that a large majority just doesn't care. I don't agree, specially considering legacy code. Those of us still have to deal with an awful lot of code written 10 or 20 years ago still have to maintain code that juggles pointers and references around in ways that are hard to track ownership, and migrating this code to C++11 is no simple task. This doesn't mean people don't care. It just means the industry cannot afford getting whole teams to spend a couple of years on sabbatical to refactor legacy code and pay it's legacy debt. This is perhaps the biggest strawman that Rust fanatics use to criticize all things that isn't written in Rust. They pick their small little greenfield modules and boast how safe and perfect it is, and proceed to criticize all legacy production code whose teams can't even spare time to fix long standing bugs, let alone pay off technical debt. And that's somehow something Rust fixes?

temp2022account 4y ago

Modern C++ has many tricks to get memory and thread safety pinned down, but in my experience the new capabilities are entirely subsumed by old code. If Bjarne wants C++ to be a language worth choosing, we need some options to remove all of the footguns from before c++11, and remove the redundancies with partially-well-done new features to yield a single-well-done way of handling memory and multithreading. If Bjarne put something akin to Rust's Editions in C++, and regularly removed poor designs, then yes C++ would be pretty close to Rust for new projects.

JonChesterfield 4y ago
No can do. That would break backwards compatibility (thou shalt not do so) or fragment the language (likewise). What we can have is increasingly elaborate syntax and progressively better tooling.
steveklabnik 4y ago
Editions were proposed in 2017, but were postponed. I haven’t heard of any forward movement on it lately.
- pjmlp 4y ago
  They were taken down, because they cannot cover all scenarios of language evolution, in grammar, language semantics, across compilers, binary libraries and ABI, as such failed to gain wide support.
  - steveklabnik 4y ago
    This was not the reasons cited in the actual votes to postpone https://github.com/cplusplus/papers/issues/631#issuecomment-585231742 https://github.com/cplusplus/papers/issues/631#issuecomment-... Not that that means you're strictly wrong, mind you, just that only textual inclusion issues and template issues were voted on as being blocking at that time.

ivan_gammel 4y ago

Off topic, but I’m surprised Slashdot is still alive. Have not heard of it for a few years.

arp242 4y ago
The banner it gave me made me laugh: "Do you develop on GitHub? You can keep using GitHub but automatically sync your GitHub releases to SourceForge quickly and easily with this tool so your projects have a backup location, and get your project in front of SourceForge's nearly 30 million monthly users. It takes less than a minute. Get new users downloading your project releases today!" SourceForge: from de-facto standard open source tooling to "please allow us to mirror your GitHub".
- IYasha 4y ago
  That's what happens when you make questionable moves and have M$ as a competitor.
  - arp242 4y ago
    GitHub ate SourceForge's pie long before Microsoft bought it. The questionable moves also came long after the pie had been eaten.

xorvoid 4y ago

Well, he’s wrong, objectively so. And its easy to prove. But I can’t blame him for feeling attacked and wanting to defend the work he’s poured his entire life into. (For the record: I’m a lifelong C/C++ programmer who has written large systems in it)

snorkel 4y ago

Cpp offers thread safety but rust insists on it.

Jweb_Guru 4y ago
It "offers" thread safety in the sense that it's theoretically possible to write a thread safe program in C++. It certainly makes it about as difficult as humanly possible to do so, however, especially when they include stuff like the consume ordering that isn't even well-defined.

sfpotter 4y ago

For what it's worth, the word "Rust" doesn't actually appear in the "A call to action: ..." document. It does appear in the original NSA document, but not in the part of the text that Stroustrup quoted. Not sure if this was intentional or not, but if read carefully the Slashdot post does appear to be misquoting him.

JeremyBanks 4y ago
[dead]
steveklabnik 4y ago
Rust certainly appears in at least one version of the paper; they even call it “RUST” through most of it.
- sfpotter 4y ago
  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... If you ctrl-f "rust" in this PDF, there are zero hits.
  - steveklabnik 4y ago
    Ohh, you know what? There's two, similar papers. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2759r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27... This is the one that had a ton of discussion over the last few days. The one you linked from the /. article is much, much shorter, and has only Bjarne as the author, unlike the other, which has co-authors.
    - arp242 4y ago
      This is highly confusing; people are talking past each other because the document you're talking about and linked isn't linked in the /. article at all; it's not even linked in the PDF That /. links to. I never liked these crummy /. mini-writeups that may or may not be accurate.

justinsaccount 4y ago

> make it possible to write better, safer, and more efficient C++ Right, but is it still possible to write bad, unsafe, inefficient C++ that looks indistinguishable from the safe kind?

JeremyBanks 4y ago

[dead]

dzonga 4y ago

can modern c++ be safe ? yes !! is modern c++ so complex, big with a huge surface area to shoot yourself, yes. that's the problem with C++ it's such a huge language that knowing to do the right thing is difficult.

witheld 4y ago

Sure Bjarne, you’re right, if you follow best practices- use static analyzer- special compiler time options. If we research and develop, we can make a safe C++. But if you wanna write safe code, from scratch, because you don’t want to recycle your dangerous old C++ codebase; then why would you write that new code in C++ when rust is ready and here to do it?

imtringued 4y ago
Ok but the static analysis tools that are equivalent to what Rust does involve bolting a borrow checker on to C++ at which point you might question what you are trying to achieve because you can't reuse any of the existing C++ code in this configuration as all the other C++ developers failed to use your specific static code analysis setup.
- Ar-Curunir 4y ago
  And also, unlike Rust, C++ was not designed to support the borrow checker, so any code that you’re writing might not even be analysable properly by the C++ borrow checker
  - pjmlp 4y ago
    See here for the current status in VC++ as of last December. Plenty of work still to do. https://devblogs.microsoft.com/cppblog/high-confidence-lifetime-checks-in-visual-studio-version-17-5-preview-2/ https://devblogs.microsoft.com/cppblog/high-confidence-lifet...
    - Jweb_Guru 4y ago
      Sure. As was obvious from the beginning for anyone who's tried to do lifetime analysis on mostly-unannotated C++, this is going to become another "bug reporting" tool that doesn't accomplish anything close to what Rust does. Most likely, all it will do is catch a few of the more obvious bugs so they pass various tutorial examples people use to show why you need borrow checking, leading C++ programmers will believe the problem is solved when it isn't.

thesuperbigfrog 4y ago

Real world projects using C++ are seeing decreases in security vulnerabilities when migrating to Rust: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1 https://security.googleblog.com/2022/12/memory-safe-language... While C++ with the latest features should be secure enough in theory, in practice practically no one is using all the latest features just right to achieve the needed security. Sorry, the NSA report is correct. Using C or C++ opens your project up to memory safety risks. Use a memory safe language if at all possible.

gigel82 4y ago
I'm sure you'd be seeing the same results by rewriting the project in modern C++ instead of Rust.
- thesuperbigfrog 4y ago
  >> I'm sure you'd be seeing the same results by rewriting the project in modern C++ instead of Rust. I would personally choose Rust over C++. I dislike the number of gotchas that C++ has and I think the language has gotten too big and complex to use safely. In the article I linked above, the Google Android team stated: "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." Their C++ code requires more static analysis tools and fuzzers and does not have a comparable record. If modern C++ were as safe as Rust then why wouldn't they just use modern C++? It would be a lower effort rewrite and would not need new compilers.
  - simplotek 4y ago
    > I would personally choose Rust over C++. I dislike the number of gotchas that C++ has and I think the language has gotten too big and complex to use safely. This take sounds like fomo mixed with cargo cult programming. When you write something in C++, nothing forces you to use all features of C++. There is no bingo card you have to fill to get your project to compile. You just pick the things you feel serves your purposes, and stick with them. I don't really understand this irrational take. It's like claiming they don't want to speak in English because the dictionary is too large and some words are too tricky to spell to use in a conversation.

jbirer 4y ago

We were taught C in high school (East Europe ftw). I always longed for a language that had some memory safety and high level abstractions while not being a clusterfuck like C++. I don't think we'll see C++ in the next 10 years that much if they don't fix the ecosystem bloat issue.

pxmpxm 4y ago
it's called Java
JonChesterfield 4y ago
D might be what you're looking for.

duped 4y ago

First off there's nothing about Rust here. But this quote: > In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains Tells me he doesn't really "get it." People do not follow the core guidelines, and other languages are designed such that there aren't guidelines. There's a type checker (wave hands here) that proves your code and its dependencies are memory safe (within some sane definition). Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong.

everforward 4y ago
> Another thing worth mentioning is that "type safety" isn't something other languages need to worry about since it's generally not possible to tell a type checker that it's wrong. This seems like it's split between compiled and interpreted languages, no? Typescript and Python (I believe) will let you override types in their type system, I assume because doing so has no effect on the underlying code. I'm assuming that compiled languages with integrated type-checkers actually use the type checker for allocations so changing types has runtime implications. E.g. Typescript doesn't care if you use `as` to force the type of a variable because it has no impact on the runtime. Javascript will create objects and allocate memory the same regardless of what Typescript thinks the type is. That's not true of something like Go, where changing the type of a variable would require different allocations and changing a struct to a string would break low-level features like GC.
- duped 4y ago
  It's not interpreted vs dynamic, it's static vs dynamic typing. Python and Typescript are dynamically typed languages with optional AOT type checking, meaning it is valid to write code that would fail typechecking or is impossible to typecheck at parse-time (in other words, types are only guaranteed to be checked when the code is executed, but types are always checked!). There's also a sliding scale of "weak" to "strong" typing (I don't want to attempt to define it). C is the canonical example of a "weakly" typed languages, but imo C++ fits that as well - unless you follow the idioms of "type safe" programming, which makes it difficult for a programmer to write code that is not type checked. The difference between a weak-but-statically typed language and dynamically typed language is that it's possible for a programmer to write code that is never type checked, leading to potentially undefined behavior. C++ needs a notion of "type safe" programming because it is possible for a programmer to write such code. Contrast to a language like Rust or Haskell, where it's close to impossible to write type-unsafe code (without explicitly saying you want to). My point is that implying "safe" programming also implies type safety misunderstands that such safety is close to meaningless in safe programming languages. It's just so much harder to write type-unsafe code it's kind of pointless to bring it up, unless you're writing C and C++.

amluto 4y ago

In very partial defense of this idea: > There is not just one definition of "safety", and we can achieve a variety of kinds of safety I agree, but C++ and Rust both fail at what I could consider a major form of safety not too far below memory safety. It might be called “capability safety” or “effect safety”: a function call should not be able to have side effects or read data outside that explicitly permitted by the caller (or importer or program manifest or whatever). I would consider a form of “unsafe”-like escape hatch acceptable so long as using that escape hatch is itself treated as a capability. Rust and C++ don’t do this at all, although I could imagine it being retrofitted into Rust or a similar language. Java sort of tried, and it was a near complete failure on many counts. Several experimental languages have this as an explicit goal. Some container and VM systems attempt this sort of security. Sandstorm was a notable example.

spoiler 4y ago
I guess you want something like the IO monad in Haskell and similar languages. I'm not sure how that would or could slot in Rust. I guess all IO could return something like an IOResult (although, I guess Result<T, E: IOError> could do that too that, but it's not "enforceable" in the same way it is in Haskell). I like the idea in theory, but depending on how it's implemented at the language level, it could end up being a bit hit or miss.
- amluto 4y ago
  The IO monad is sort of on the right track, but it’s far too coarse grained. Here are some efforts in the right direction: https://github.com/austral/austral https://github.com/austral/austral http://www.erights.org/ http://www.erights.org/ Deno does something along these lines too. WASM does, too, if you squint hard at it.
  - spoiler 4y ago
    Ah, I like this idea. I've played with Deno a bit, and loved the permissions feature. It would be nice to see some version of this in Rust too
  - 4y ago

programmer_dude 4y ago

LOL.

JustLurking2022 4y ago

Sure, you can write safe C++ code but it's up to you to know all the patterns/syntax to do so. Other languages give you compile time errors when you try to do something unsafe.

gigel82 4y ago
I prefer taking the training wheels off the bike after I learn how to bike...
- lilyball 4y ago
  I prefer taking my seatbelt off after I learn how to drive...
  - MathMonkeyMan 4y ago
    I prefer to stay inside...

none_to_remain 4y ago

I'm so old I remember when we were all supposed to be writing Haskell for everything by now. The immutability would finally make us safe

_trackno5 4y ago

While I agree with Stroustrup that there's a rush to get memory safety bolted onto C++, it's pretty obvious he doesn't understand what good design actually is: > I envision compiler options and code annotations for requesting rules to be enforced. The most obvious would be to request guaranteed full type-and-resource safety. You'd think someone that worked on a compiler for decades would come to the realisation that opt-in safety is just dumb. You want everything to be safe by default, despite the performance implications, and then allow programmers to peel back safety features explicitly where they are not needed. You don't buy a gun and the safety lock as an add-on. Borrowing from Donald Norman and his Design of Everyday Things book, safe programming in C and C++ relies too much on "knowledge in the head" instead of "knowledge in the world" in order to do it correctly. You don't need the big borrow-checker hammer from Rust to be a lot better. Most CVEs (memory safety related) are about out-of-bounds writes/reads. You could mitigate a huge chunk of those problems by just doing something as sensible as having a well defined concept of slices with bounds checking turned on by default. But this seems to elude the C and the C++ committee for some weird reason.

gxt 4y ago

I've never had an unsafe-free rust program crash by segmentation fault, or crash at all. But I remember having off-by-one errors doing just that in basic for-loops in C++.

IYasha 4y ago

Old man is right. <3