The Binder Linux driver is being rewritten in Rust

Second, the nirvana fallacy is comparing actual things to unrealistic, idealized alternatives. You're comparing actual (seat belts) to an idealized alterative (something that prevents all car crashes, no matter the cause).

Third, it's a less generalized example. Stuff seatbelts don't protect and might even lessen chances of survival - rockets, gunfire, rhinoceros, trains, meteors, nuclear blasts, black holes, multiversal collapse.

In Rust, an enum can also carry data along with the tag, and the type of the data can be different for each value of the tag. A Rust enum is more like a "tagged union" (a struct containing both an enum as the tag and a union for the extra data) in C.

Perhaps the most practical example of this is the Option type, where you can say an Optional value is either `Some(value)` or `Nothing`.

With this, you don't have do deal with null pointers; a `null` pointer would instead be `Nothing`, and a non-null value would be `Some(value)`, and the compiler can enforce you're sticking to this.

Most C libraries and system calls return integers not enums. Often the meaning of those integers is hard coded in a header somewhere. There's no guarantee that the number returned will be one of the values in the header.

When a library does return enums, there's no guarantee the value returned is actually in the enum. It could be anything.

When you pattern match an enum in C, you have no checks to make sure you catch all the cases, or don't drop a break;.

All of the above means that in C, you're relying on the programmer to cross check they haven't made a mistake. Rust does it all for you - if you match against an enum type, you have to handle all the cases. You can't return anything other than the type you said you would. It basically does all the work that the programmer has to do in C. And most importantly, it does it every time you recompile. Even if the first person to call a function in C is meticulous, the members in the enum might change later.

Almost all C++ code interacts with bare pointers at some point. And that’s just one of the places where you get into issues with safety.

You can also run into problems with iterators being invalidated: your iterator into a std::vector is no longer valid after a call to push_back().

Anything that stores a reference and can exist after the lifetime of the object, really. Lambdas are a problem here. But so are instances with reference members.

C++ is littered with these things.

An easy way to trigger undefined behavior in C++ is by using a pointer after the thing it's pointing to has been freed. Doing this in a process that takes any user input can easily create a vulnerability that allows an attacker to inject code into the process. There are many ways to accidentally do this while thinking you're safe. A pointer to an item inside a data structure like a vector or hash table is dangerous if you use it after some items may have been inserted into the data structure, because inserts can cause the data structure to reallocate and expand its backing memory. This mistake can easily go unnoticed for a long time because only a small fraction of inserts will cause that. This mistake isn't possible to make in safe Rust.

I would argue one (Rust) is, but not C++. Rust is more "batteries included" and doesn't require specific compiler flags or complicated tooling, it just works and gives you guarantees out of the box. C++ seems to allow escape hatches by default while Rust requires you to call that out via `unsafe`.

Unless what he disliked was the inheritance/OOP stuff in C++, which isn't an issue in Rust.

How would C++ features like RTTI, exceptions, and the std template library be used? What about the insane ideas of classes and inheritance which induce mind numbing impossible to comprehend code?

Rust is actually pretty readable and reviewable. C++ tends to be mind numbingly hard to review.

You mean time to rot?

    "Experience shows that this [memory safety] cannot be done without static analysis and run-time support. Furthermore, for fundamental reasons this cannot done even with such support if arbitrary legal language constructs are accepted while conventional good performance must be maintained."