> "maybe crash, maybe accidentally continue running and make things far [worse] than crashing" instead "definitely crash"
…is functionally indistinguishable from your reply.
> (two pointers can reference the same memory and both be valid for reads/writes).
Rather than forbid, Rust requires you put logic like this inside unsafe blocks. This limits the number of places you need to look for UB. Hopefully the number of shared writable pointers is not excessive.
C++ programs on the other hand are all the equivalent of one big unsafe block. That's the difference, not anything "forbidden" by Rust.
In Rust, it absolutely is. You generally have so few `unsafe` blocks that it's entirely reasonable for a human to audit them and manually verify that their invariants are upheld. You can still use tools like Miri if you want even more assurance, but that's optional.
UB does not happen because there's few lines of code that do the wrong(TM) kind of obvious thing but it happens because that chunk of code interacts with other parts of the code in ways that you usually cannot conceive without tooling or realistic workloads.
I guess that for that or similar reason, Rust also happens to be working on adding support for UBSAN, ASAN, TSAN and MSAN sanitizers. Unfortunately it has been WIP for almost 7 years: https://github.com/rust-lang/rust/issues/39699
https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...
A non-trivial C++ codebase with that kind of track record is so rare as to be unheard of, though many can approach it with the various sanitizers plugged into the dev workflow after the fact.
C++ has improved dramatically over the last fifteen years, but a lot of stuff simply can't be fixed without breaking backward compatibility, which just isn't going to happen.
We've had enough time elapse to see the related rates of CVEs posted for C++ and Rust apps over the last few years. It's not even close.
It is absolutely possible to have bugs in a Rust app due to logic error or memory leak. But C++ has those same limitations and so many more unless you tack on a host of add-on analysis tools and still you end up with a result that is not as safe as Rust.
Write a web app server in Rust? Sure. As long as I know the problem space, have the dev time allocated, and the need for that efficiency is clear.
Write it in C++? Hell no. Not ever again. Not in a million years. Even if the need for efficiency is demonstrated, I have far less confidence in the integrity of that service when connected to the public internet, no matter how skilled the team is.
Even Scott Meyers—Scott Fucking Meyers, who wrote acclaimed books on advanced use of C++ we mere mortals came to depend upon—does not have confidence in writing code for it anymore. In just three years, he went from an undisputed authority on the topic to this in 2018:
"As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action."
https://scottmeyers.blogspot.com/2018/09/the-errata-evaluati...
Neither I nor the folks I have worked with were as skilled as Scott Meyers at his prime, and the majority of us—myself especially—aren't even as good as he was 2.5 years after he stepped away.
Perhaps you are. Are you certain that everyone else on your team is? Everyone who comes later that has to maintain those codebases?
With Rust, I believe teams have a fighting chance. With C++, I'd just as soon buy lotto scratchers since I'm looking at similar odds. Perhaps I'm just an average software engineer. That's entirely possible, and I'll cop to that. But I'm not alone, and we still have bills to pay and code to write. For the sake of my clients, that'll be in Rust before C++ if I can help it. (And neither if the problem doesn't require their level of efficiency.)
A major power outage has nothing to do with reverse proxy software. It's difficult to take your critiques in good faith.
C++ is too complex for an expert to safely identify whether something is a bug or not. Not all C++ developers are experts. It is alarming you consider this state of affairs to be acceptable or that Rust does not clear mitigate many of these issues out of the box.
Does Rust eliminate all bugs? Of course not. That was never the assertion. When Microsoft finds in a study that 70%+ of all Microsoft CVEs would have been avoided given Rust's memory model, it should not be hand-waved away as personal preference or irrational bias. [2] [3]
[1] https://www.cloudflarestatus.com/incidents/hm7491k53ppg
[2] https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst...
[3] https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-sy...
I am glad you recognize how bad of an example that was. Now apply this to the rest of your arguments.
> or that Rust does not clear mitigate many of these issues out of the box.
You're again imputing something I never said only to support your opinion. This is the third time in this thread you're successfully avoiding to address the substance of my initial two comments. I won't proceed any further in this discussion because it's a plain waste of time.
I'm sorry for being pedantic, but it's important to distinguish between UB generally (which would normally be termed "implementation-defined" in common parlance if that weren't already a term of art) and memory safety specifically.
We don't get CVEs because a C source file didn't end in a newline. I suspect we rarely get CVEs because someone failed to add -ftrapv when they should have. We get CVEs primarily due to OOB memory access.
This is quite the... unique way of defining "undefined behavior". Rust is currently implementation-defined. That doesn't even remotely mean its behavior is undefined in theory. And it certainly doesn't mean that "all of Rust" is UB in any practical, real-world sense. In practice, your average Rust program is more well-defined than nearly every C codebase, in terms of what invariants the compiler is allowed to assume about the code for the sake of performing transformations (which is what UB actually means, rather than "is there an international standard").
Many cases of UB in C are perfectly well defined at the implementation level. Some are not, for reasons ranging from lack of a demand signal, to the need for an expensive runtime, to compiler writers wanting to squeeze out every last drop of performance.