That’s true in C as well, though. This is what people mean when they say things like “undefined behavior can result in time travel”.

The difference is twofold:

• Rust’s rules for valid unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.
• Because safe Rust is so strict about what it permits, the compiler is able to make more aggressive optimizations; in theory, this could indeed cause undefined behavior to be “worse” at runtime than a comparable situation in a globally-unsafe language. I’m unaware of any actual examples of that phenomenon, though.

Yes Rust is harder to write than C, that’s basically by design as it’s due to the statically guaranteed memory safety. That’s pretty magical. C doesn’t have that and neither does C++ even with smart pointers and such. Rusts unsafe keyword is poorly named, what it actually does is tell the compiler that you the programmer guarantee Rusts rules are upheld within the unsafe block.

For example

Access or modify a mutable static variable

That is a global, that’s incredibly hard to impossible to statically prove it’s safely done, so you have to do it in an unsafe block. So you violating Rusts rules within an unsafe block is actually using the unsafe block wrong. That’s not what it’s for

That depends a lot on how you define “correct C”.

It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.

The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.

What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using std::unique_ptr. In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block

I would still like to take a moment to answer your specific questions more directly:

And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.

Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

I think that’s only half of the issue, with the other half indeed being use after free. After all, using a reference isn’t much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there’s a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.

Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Thread safe code is also the issue. The reason people don’t have to run from Java is because data races there don’t escalate to memory unsafety; they’re just caught as “ordinary” exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

It is indeed a dangerous subset, but as I mentioned elsewhere, Rust’s borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you’re on your own when it comes to safety.

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

They indeed avoid some of the issues, but notably don’t protect against use after free at all. And take std::vector as an example:

std::vector v;
v[2]; // out-of-bounds access

vs.

unsafe {
    let v = Vec::new();
    v[2]; // panic
}

Even wrapped in unsafe, the Rust equivalents are still safer.

deleted by creator

Lol okay. Here are some concrete examples I don’t have:

Templates as basic generics

• Templates still show bizarre error messages far too deep into instantiation, despite at least three major features which provided opportunities to fix the problem (static_assert, type_traits, and then concepts)

Templates for metaprogramming

• 33 years after the introduction of templates, there are still many common cases in which the only good way to abstract a pattern is by using a macro, and many cases that neither macros or templates can solve
• There is finally an accepted proposal to fix part of the problem, which will be introduced in C++26, and probably not usable in real code until 2030 at the earliest
• In 2035, people will still be reluctantly using string macros and external code generation to solve basic problems in C++

Safe union types

• C++17, std::variant was introduced to provide a safe inline union type
• The main API for accessing it is inexplicably slow, unlike in every competing language
• The fast alternative is an eyesore that can’t integrate with switch statements except via weird, unmaintainable hacks
• Everyone keeps using custom struct/union/enum combos instead
• CVEs everywhere

Error handling

• C++ uses exceptions as the primary error handling mechanism
• Exceptions are so slow and so riddled with problems that some companies ban them, and almost all consider them bad practice for representing common failure paths (e.g. failing to parse something)
• std::expected eventually approved, similar to Rust’s Result type, but with no equivalent to the ‘?’ operator to make the code readable
• Now there is a proposal to introduce “value type exceptions” instead, which is gathering momentum before std::expected has even stabilised, but will probably not be available for 10 years

Subtype polymorphism deprecated

• Now that virtual methods and inheritance are widely considered tools of last resort, they obstruct the introduction of better alternatives
• Instead we have widespread use of specialised template structs and CRTP to replace instance inheritance with a kind of static inheritance designed for templates
• It’s all a hack, and as a result it’s full of edge cases that don’t work very well, and poor tool support

References

• Good C++ programmers use references where possible, because pointers can be null
• Good C++ programmers avoid unnecessary copies and allocations
• Good C++ programmers avoid patterns that can permit unintended coercions with no error
• Oh no, I accidentally assigned a reference to an auto variable in a template, and instead of giving a helpful type error it implicitly coerced a new copy of my vast memory buffer into existence
• Okay fine I’ll pass pointers to avoid this, and just trust they won’t be null
• Oh no, C++ has standardised the idea that raw pointers represent nullability even in all their newest standard library types (thanks again, std::variant)

I think if you consider anything post C++03 (so C++11 or newer) to be “modern C++” then Concepts must be the top example, doesn’t it?

Counting from C++0x that’s almost a decade of waiting.

I’d’ve thought Ada would play a larger role in aerospace, because of these issues, among others.

Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

the CVE list would disagree with you.

Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

This statement is kinda ironic after you just said it’s “easier” to just ban the entire STL and dynamic memory allocation as a whole. You already left the domain of what most consider “easy” quite a while ago.

https://en.wikipedia.org/wiki/The_Power_of_10%3A_Rules_for_Developing_Safety-Critical_Code

and their 40 page coding standard document. https://ntrs.nasa.gov/api/citations/20080039927/downloads/20080039927.pdf https://ntrs.nasa.gov/citations/20080039927

and their software safety handbook. https://standards.nasa.gov/standard/nasa/nasa-gb-871913

all 389 pages of it https://standards.nasa.gov/sites/default/files/standards/NASA/Baseline/0/nasa-gb-871913.pdf

I don’t have the data, but I don’t think it’s wild to assume that most rust programs have 0-1 unsafe blocks, in total. Except for special cases like ffi.

Even if your rust project has 1000s of unsafe blocks, it is still safer than C++, which is 100% an unsafe block. You only have to carefully review the parts marked “unsafe”, in C++ you have to carefully review the whole code.

Also, because unsafe blocks are explicitly declared, you know which parts of the code require extra carefulness, and if you encounter a memory bug, doing Ctrl+F “unsafe” will soon show the root cause.

I use C, C++ and Rust in my dayjob.

I don’t like C++, but I disagree with your statement.

C++ has:

• a string type, which sidesteps error prone buffer juggling.
• smart pointers for scope based deallocation.
• generic data types. No more hand rolling list and mapping types with void *.

It’s obviously still not a fully memory safe language, but it has some perks over C. I’d still much rather be using rust (most of the time).

Condemning apples for having seeds doesn’t make a reasonable case for choosing other fruit, which also have seeds.

Go is totally different from Rust. It has garbage collection and built-in lightweight threads with message passing, but a fairly simple type system comparable to C’s.

Rust and post-2011 C++ have fancier type systems influenced by e.g. Haskell. If you haven’t used such languages before, there may be a learning curve, but that temporary confusion you’ll feel is the sensation of your brain getting bigger, so it’s a good effort to make.

Rust and C++.afaict are mostly designed for systems programming where you want to control resources and memory manually. If you can stand a larger footprint, you might be more productive in a GC’d language. That said, I haven’t used Rust yet. Lots of Haskellers like it though.

For Haskell, try learnyouahaskell.com .

For Ada, try http://cowlark.com/2014-04-27-ada/index.html and then “Ada Distilled” (online book, use web search).