Whatever % of people that “fail” this test, is much higher than the 0% of people that would do so using rusts’ compiler.

Of course, programs that don’t pass the borrow checker can be totally memory safe, but that would need to be analyzed on a case by case basis.

Programs that do pass the borrow checker aren’t guaranteed to be totally memory safe, so the number isn’t actually 0% for Rust either: https://github.com/Speykious/cve-rs

Rust forces you to do this until you have to use unsafe, after which it doesn’t. That is not so different from C++ guaranteeing your safety until you start using raw pointers.

It is not the compiler’s job to stop the programmer from shooting themselves in the foot if they want to. It’s the compiler’s job to make it clear to the programmer when they disable the safety, put their finger on the trigger and aim the gun at their foot. Modern C++ does this, and if you still inadvertedly shoot yourself in the foot in spite of the warnings, you brought it on yourself.

Regular old C, on the other hand, gives you a 9mm when you’re in grade 7, safety: always off.

If you follow modern C++ best practices, memory unsafety will not happen by accident. The dodgy stuff in modern, idiomatic C++ is immediately obvious.

It’s not a joke. What was described above is pretty much C++'s RAII pattern, which Rust evangelists love to present as a revolutionary Rust invention. Used with smart pointers, it will help avoid use-after-frees. What it doesn’t avoid is null pointer exceptions (you can std::move a unique_ptr and still access it, it’ll just be nullptr), but those will typically “just” be a crash rather than a gaping security hole.

That is not to say Rust doesn’t have its own innovations on top of that (notably that the compiler stringently enforces this pattern), and C++ does give you many more ways to break the rules and shoot yourself in the foot than Rust does.

They will probably have a version newer than 5.15.149.

It looks to be on 6.1.153 currently which is much newer than 6.1.76.

With the uname -a command

This only affects positively ancient kernels:

From (including) 3.15 Up to (excluding) 5.15.149 From (including) 6.1 Up to (excluding) 6.1.76 From (including) 6.2 Up to (excluding) 6.6.15 From (including) 6.7 Up to (excluding) 6.7.3

C++ would also solve this for the same reason!!

The Radeon 500 series has great support in Mesa so there should be absolutely nothing unusual in terms of compatibility with that GPU.

That subtitle isn’t real