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.
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.
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)
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.
> 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.
> 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?
> Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.
See, this is yet another instance of the strawman argument I pointed out.
This is not a "enough time" problem. It's a resource allocation problem. Time is irrelevant if no resources are allocated to a task. Rust does not add manpower to rewrite things.
Rust fanatics just perpetuate survivorship biases because the project they did with the express purpose of fixing a specific issue ended up fixing the specific issue, and proceed to somehow go the cargo cult way and praise the framework instead of the rewrite effort. It's disingenuous and a gross misrepresentation of reality, and one which will inevitably come around to bite Rust in the ass. We already see backpedalling with regards to some of these claims once Rust started showing up in SVEs.
Sure, the language hasn't been around for that long, but that doesn't invalidate the fact that there are large codebases written in it, and that maintained projects in Rust regularly keep up to date with language advancements, though.
Another benefit of Rust is that you can largely avoid the same category of monster codebases common in C++, because there's much less (virtually none) friction in splitting up your codebase into crates.
Like SURE... You CAN do this in C++, but it's usually just simply not worth the bother, because you gain next to nothing
Maybe this already exists, but having ways of enforcing that only subsets of languages would be useful for their evolution. All languages have baggage and complexity starts to increase as there can be many different ways to do the same thing. The response is to create new ones as a kind of pruning effort.
If is were possible to use a language subset (C++ indigo or something like that) that only allowed a certain subset it (along with toolchain support) would help since at least new projects and libraries could strictly conform to that. Similarly old code bases could be migrated over time.
> 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.
I think this is the real value. As an analogy, I once updated a large legacy codebase from Java 1.x (pre-generics) to Java 1.5+ adding generic annotations everywhere. It took many months of incremental, interspersed work. In the end, there was exactly 1 bug uncovered where a drop-down list would rarely show `ObjectType@addr` instead of the proper rendering which was otherwise harmless.
This is to say that the added type information wasn't mainly needed to reduce bugs as it's raison d'etre, but that it meant that developers had reduced cognitive load of types while working.
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.
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.
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.
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.
"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".
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)
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.
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.
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.
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?
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.
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
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.
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.
>> 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.
> 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.
>> 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.
It's not irrational to want to avoid trouble.
Why would I want to use C++ with its plethora of gotchas, traps, caveats, pitfalls and footguns when I can use something safer and just as performant?
The Android study had a control: they compared to memory safety vulnerabilities in other greenfield projects written in modern C++. There was no significant improvement for the greenfield projects, even though they also benefited from improvements to static analysis. The improvements were reserved for Android, which had a large share of its new sensitive code written in Rust.
You are correct that it is possible to have a rewrite go badly in any language. Rewriting a project in Rust can go badly depending on the circumstances.
However, there are some patterns that Rust does not allow that other languages do allow which may help to avoid problems.
For example, creating cyclic dependencies and relationships is more difficult in Rust due to the way that ownership rules are enforced. Rust also helps to avoid data races and memory unsafety issues so that whole classes of errors and bugs can be avoided.
You're confusing things. Google's example focused on rewriting specific components with a specific goal in mind: fix/avoid unsafe memory access. The examples in that blog post consist of major rewrites of huge software projects like browsers, whose goal was to be feature complete.
Yes. I conflated the project rewrites with component rewrites.
The statement, "Almost every project sees fewer issues with a rewrite, no matter which languages are involved.", was too broad and I wanted to show how I disagreed with it when the article I cited was concerned with component rewrites.
I did not intend to conflate the two since the scopes are quite different.
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.
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.
> 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.
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++.
Many compiled languages with strict type checking still have various sorts of "unsafe" type coercions for when you think you know better than the compiler (things like structs that have the same layout but are still nominally different types). In many of those languages the goal is that you need to opt in to the unsafe type coercion sometimes literally with a language keyword even named something like "unsafe" and know that you are doing something dangerous up front, in direct contrast to a language like C/C++ asking you to opt in to type safety and not doing anything about it up front unless you ask.
> 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.
I don't think this is true at all. There are already a few popular static code analyzers and lingers around which integrate quite nicely with your run of the mill build system.
The purpose of these static code analyzers and linters is none other than enforce the adoption of stuff like the C++ core guidelines in a workflow a kin to unit testing.
How do you explain that, based on your personal assertion that no one bothers with those? I mean, even popular C++ IDEs support those out-of-the-box.
I really do not understand this absurd idea that those who care about safety drop everything they're doing to mindlessly migrate all things under the sun to a programming language, and the only ones not doing that are the poor incompetent fools who foolishly don't succumb to this cargo cult nonsense.
> 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.
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.
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.
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.
83 comments
[ 3.1 ms ] story [ 80.4 ms ] threadPeople 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.
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)
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.
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.
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?
I also preach against "C with C++ compiler" since around 1994.
Plenty of time for people to adapt on how to write proper, safer C++ code than using C idioms.
See, this is yet another instance of the strawman argument I pointed out.
This is not a "enough time" problem. It's a resource allocation problem. Time is irrelevant if no resources are allocated to a task. Rust does not add manpower to rewrite things.
Rust fanatics just perpetuate survivorship biases because the project they did with the express purpose of fixing a specific issue ended up fixing the specific issue, and proceed to somehow go the cargo cult way and praise the framework instead of the rewrite effort. It's disingenuous and a gross misrepresentation of reality, and one which will inevitably come around to bite Rust in the ass. We already see backpedalling with regards to some of these claims once Rust started showing up in SVEs.
Of course there are exploits in safer systems languages, memory corruption issues and arithmetic exploits only represent 70% of root causes.
We still need to consider the remaining 30%.
Another benefit of Rust is that you can largely avoid the same category of monster codebases common in C++, because there's much less (virtually none) friction in splitting up your codebase into crates.
Like SURE... You CAN do this in C++, but it's usually just simply not worth the bother, because you gain next to nothing
If is were possible to use a language subset (C++ indigo or something like that) that only allowed a certain subset it (along with toolchain support) would help since at least new projects and libraries could strictly conform to that. Similarly old code bases could be migrated over time.
I think this is the real value. As an analogy, I once updated a large legacy codebase from Java 1.x (pre-generics) to Java 1.5+ adding generic annotations everywhere. It took many months of incremental, interspersed work. In the end, there was exactly 1 bug uncovered where a drop-down list would rarely show `ObjectType@addr` instead of the proper rendering which was otherwise harmless.
This is to say that the added type information wasn't mainly needed to reduce bugs as it's raison d'etre, but that it meant that developers had reduced cognitive load of types while working.
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.
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.
"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".
(For the record: I’m a lifelong C/C++ programmer who has written large systems in it)
If you ctrl-f "rust" in this PDF, there are zero hits.
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.
I never liked these crummy /. mini-writeups that may or may not be accurate.
https://twitter.com/m_ou_se/status/1615736570400890883?s=20&...
Right, but is it still possible to write bad, unsafe, inefficient C++ that looks indistinguishable from the safe kind?
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.
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?
https://devblogs.microsoft.com/cppblog/high-confidence-lifet...
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.
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.
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.
It's not irrational to want to avoid trouble.
Why would I want to use C++ with its plethora of gotchas, traps, caveats, pitfalls and footguns when I can use something safer and just as performant?
That is provably false:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
There are numerous developers on this forum who could provide eyewitness accounts of project rewrite horror stories.
The same thing would happen if you rewrote in rust.
However, there are some patterns that Rust does not allow that other languages do allow which may help to avoid problems.
For example, creating cyclic dependencies and relationships is more difficult in Rust due to the way that ownership rules are enforced. Rust also helps to avoid data races and memory unsafety issues so that whole classes of errors and bugs can be avoided.
You're confusing things. Google's example focused on rewriting specific components with a specific goal in mind: fix/avoid unsafe memory access. The examples in that blog post consist of major rewrites of huge software projects like browsers, whose goal was to be feature complete.
Those are quite different things.
The statement, "Almost every project sees fewer issues with a rewrite, no matter which languages are involved.", was too broad and I wanted to show how I disagreed with it when the article I cited was concerned with component rewrites.
I did not intend to conflate the two since the scopes are quite different.
Why stop at smart pointers?
I would rather use a smarter compiler / smarter language with fewer gotchas, traps, caveats, pitfalls and footguns.
> 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.
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.
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++.
https://twitter.com/m_ou_se/status/1615736570400890883?s=20&...
At least some people screenshot the original.
I don't think this is true at all. There are already a few popular static code analyzers and lingers around which integrate quite nicely with your run of the mill build system.
The purpose of these static code analyzers and linters is none other than enforce the adoption of stuff like the C++ core guidelines in a workflow a kin to unit testing.
How do you explain that, based on your personal assertion that no one bothers with those? I mean, even popular C++ IDEs support those out-of-the-box.
I really do not understand this absurd idea that those who care about safety drop everything they're doing to mindlessly migrate all things under the sun to a programming language, and the only ones not doing that are the poor incompetent fools who foolishly don't succumb to this cargo cult nonsense.
Linting exists for C since 1979.
> 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.
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.
https://github.com/austral/austral
http://www.erights.org/
Deno does something along these lines too. WASM does, too, if you squint hard at it.
It would be nice to see some version of this in Rust too
It would be nice to see some version of this in Rust too
> 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.
But I remember having off-by-one errors doing just that in basic for-loops in C++.