[ransom1538]

Dumb question: Do we need to use C++ anymore? Can we just leave it to die with video games? How many more years of this crap do we need before we stop using that language. Yes I know, C++ gurus are smart, but, you are GOING to mess up memory management. You are GOING to inject security issues with c/c++.

[rocqua]

If im going to be making code that needs to run fast, works on a bit level, and isn't exposed to the world, then I am picking up C++

It's more convenient than C. It's easier to use (at the cost of safety) compared to Rust.

Perhaps this will change if I know rust better. But for now C++ is where it's at for me for this niche.

[bluGill]

If you drop the parts of C++ that are that way because of C it is a much safer language. Weird and inconsistent, but someone who is writing C++ wouldn't make the error in the code in question any more than they would in rust. In C++ we never is unbounded arrays, just vectors and other bounded data structures.

I often see students asking a C++ question and when I tell then that is wrong they respond that their professor has banned vector. We have a real problem with bad teachers in C++, too many people learn to write C that builds with a C++ compiler and once in a while has a class.

[alfalfasprout]

C/C++ is great for AI/ML/Scientific computing because at the end of the day, you have tons of extremely optimized libraries for "doing X". But the thing is, in those use cases your data is "trusted" and not publicly accessible.

Similarly in trading, C/C++ abounds since you really do have such fine manual control. But again, you're talking about usage within internal networks rather than publicly accessible services.

For web applications, communications, etc.? I expect we'll see things slowly switch to something like Rust. The issue is getting the inertia to have Rust available to various embedded platforms, etc.

[josephg]

I'm a big proponent of rust, but I doubt rust will displace nodejs & python for web applications.

Web applications generally care much more about developer onboarding and productivity than performance. And for good reason - nodejs behind nginx is fast enough for the bottom 99% of websites. Rust is much harder to learn, and even once you've learned it, its more difficult to implement the same program in rust than it is in javascript. Especially if that program relies heavily on callbacks or async/await. For all the hype, I don't see rust taking off amongst application developers.

Its a great language for infrastructure & libraries though. This bug almost certainly wouldn't have existed in rust.

[scoutt]

Please....

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

I read "double free", "denial of service", "out-of bounds read", "NULL pointer dereference", etc...

And that's a list of vulnerabilities found for a language that is barely used compared to C/C++ (in the real world).

It won't change. C/C++ dominates and will dominate for a very long time.

[pornel]

You need to read the list more carefully.

• The list is not for Rust itself, but every program ever written in Rust. By itself it doesn't mean much, unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs. Rust doesn't promise to be bug-free, but merely catch certain classes of bugs in programs that don't opt out of that. And it delivers: see how memory unsafety is rare compared to assertions and uncaught exceptions: https://github.com/rust-fuzz/trophy-case

• Many of the memory-unsafety issues are on the C FFI boundary, which is unsafe due to C lacking expressiveness about memory ownership of its APIs (i.e. it shows how dangerous is to program where you don't have the Rust borrow checker checking your code).

• Many bugs about missing Send/Sync or evil trait implementations are about type-system loopholes that prevented compiler from catching code that was already buggy. C doesn't have these guarantees in the first place, so in C you have these weaknesses all the time by design, rather than in exceptional situations.

[scoutt]

> The list is not for Rust itself, but every program ever written in Rust.

This is, I think, obvious unless you are talking about C/C++ compiler bugs (which I am not).

But if you think it that way, the same happens with C/C++! Besides compiler bugs, the published CVEs for C/C++ "are not for C/C++ itself, but every program ever written in C/C++".

Still, potential severe vulnerabilities in Rust stdlib can happen too (https://www.cvedetails.com/cve/CVE-2021-31162/ or https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3631...), so there is a blurry limit between "a bug is in Rust" or not.

> unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs.

I don't know but you mention an interesting PoV. Do you propose to compare the ratio of total quantity of code EVER written in C/C++ and the numbers of "issues" found? Compared to the quantity of "issues" per code EVER written in Rust?

I guess nobody can figure out those numbers, but if I have to guess, then the ratio of total "Quantity of code"/"issues" will be in favor of C/C++.

I don't want to discuss the cause/reason of those Rust vulnerabilities, but the message I read is: "unaware programmers can still introduce potential UAF, double-free, read uninitialized memory, dereference NULL pointers, etc. Just like with C/C++ but just in smaller quantities".

[pornel]

Mitre doesn't tag every program written in C with the C tag.

A few bugs in std happened, but they're also mostly in edge-case situations that in C/C++ would be either straight-up UB or "you're bad for even trying this", like integer overflow, throwing an exception from a destructor, or implementing operator overloading that gives randomized results.

[scoutt]

It's not a tag but a keyword search. I don't know projects entirely written in Rust (other than single crates) to look for (by name). So probably there are more Rust-based vulnerabilities around than the ones from the Mitre query from the link.

And yes, edge-cases are the worst. The only concern is that these vulnerabilities were introduced by people who know the language more than anyone (I'd like to think that patches mainlined into std are written, revised and maintained by the best Rust developers). I'm afraid to imagine what kind of vulnerabilities could a person like me introduce in my own Rust programs.

[pornel]

That's the point of splitting Rust into safe and unsafe. If you're not trusting yourself with C-like danger, then stick to writing safe Rust. When you need to do something risky, then it will require unsafe{} blocks, which are a signal to be extra careful, and stand out in code reviews.

Also keep in mind that std is in unusual position, because it provides the unsafe foundation for safe programs. For example, you as a Rust user can't cause any memory unsafety when using the String type, but std had to define it for you from unsafe primitives. This concept of building safe abstraction from unsafe primitives is similar to Python: CPython is written in an unsafe language, but this unsafety is hidden from Python programs.

[FpUser]

>"Dumb question..."

Yep

[unobatbayar]

C++ is awesome and fast, don't blame it for human error.

[kobebrookskC3]

when "human error" happens at a much higher rate than the alternatives, it's fair to blame it.