You can compare them, but the comparison won't show that they're equal :p

C++'s smart pointers have direct analogues in Rust, though there are some differences. (unique_ptr<T> and Box<T>, shared_ptr<T> and Rc<T>/Arc<T>)

The borrow checker is something else completely. The closest analogue in C++ is the https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines, which offer some similar kinds of checks to Rust, but don't attempt to go nearly as far as Rust does.

There is nothing similar between Rust's borrow checker and anything in C++.

In modern C++ you get compile-time correctness by construction: you do things that reduce to correct code. All of the low-level mistakes remain possible, but are not tempting. Low-level, C-like operations are like writing "unsafe" in Rust; you can if you want to, or need to, but they are uglier, and anyway almost always not needed. Just as when coding a Rust "unsafe" block: if it ever is, you use extra care.

In a very real sense, C++ libraries perform in the role of the Rust compiler by insulating you from operations that are risky. The operations a good library exposes are safe. A Rust compiler bug could expose you to a memory fault, in the same way that a C++ library bug could; but the Rust compiler is well exercised and tested, much as is is a mature library. You need libraries anyway.

Genuine question, is iterator invalidation still a problem that people can hit with modern C++ constructs? A quick search seems to answer "yes"[1], but I'm not involved in writing C++ to evaluate what the common mitigations are.

For what is worth, I believe that 99% of what you can express in one language you can in the other. If you're hitting walls with the borrow checker when writing Rust you always have the options of either using the equivalents of unique_ptr<T> and shared_ptr<T>, or of cloning memory.

> A Rust compiler bug could expose you to a memory fault, in the same way that a C++ library bug could; but the compiler is well exercised and tested, much as is is a mature library.

I'm not sure what this sentence was expressing, but it seems you're implying here that rustc isn't well exercised and tested?

[1]: https://medium.com/@lightcone/iterator-invalidation-in-moder...

Iterator invalidation, like pointer invalidation, remains a thing. Iterators and pointers are normally treated as ephemeral, except where guarantees are provided.

It is hard for me to imagine how "the compiler is well exercised and tested" could be perceived to mean the opposite. Explain?

> It is hard for me to imagine how "the compiler is well exercised and tested" could be perceived to mean the opposite. Explain?

I misread it as talking about modern c++ compilers and libraries being well exercised and tested, and contrasting that with rustc.

Thats fine until "that guy" grabs the raw pointer out of a smart pointer and deletes it, or c style casts an interface to his version of the interface because he wanted it to return an int instead of a double. Then either pushes straight to dev or rounds up similarly evil individuals to approve the merge. I have debugged those errors. You can talk about accountability but even if you manage to get rid of one such dev there always seem to be more. And modern C++ doesn't really have great tools for thread safety. Its easier to get right than in 98, but still not hard to get wrong.

I think you're fundamentally misunderstanding the objections people have to "modern C++" when compared to Rust.

You say that it's not "tempting" to use less-safe constructs in C++ these days, but that's not the point. You are assuming a perfect C++ developer who never makes mistakes and always knows to use the proper, modern constructs, and will properly document any time that they absolutely must use a less-safe construct, and that documentation will never drift or go out of date.

That developer does not exist in any meaningful or useful way. Developers make mistakes. Developers don't always have completely up-to-date knowledge or understanding of what the correct, "modern C++" way is to do literally everything. A developer who genuinely does need to do something less safe may or may not document it, and anyone who comes by later and changes the code may not update the documentation accordingly.

The Rust compiler will not allow you to do unsafe things (absent bugs in rustc); attempting to do so is a compiler error. If you really must do unsafe things, you must surround that code in an unsafe block, which serves as documentation that must be kept up to date, or the code will not compile. Others can inspect your code and very easily decide if they want to use it based on how much unsafe code they are willing to accept.

I don't want a compiler that will only ensure certain kinds of correctness if I already know how to write things in the "correct way" (which has traditionally been a moving target in the C++ world). I want a compiler that will ensure those types of correctness always, and reject programs where it can't give me that guarantee. The C++ compiler will not do that, but the Rust compiler will.

> In modern C++ you get compile-time correctness by construction

No you don't! You only get this if you've written your code correctly! The entire point of "correct by construction, verified by the compiler" is that you cannot write the code in an incorrect way that the compiler will accept. And the C++ compiler absolutely will accept "old-school C++" that could be incorrect. Put another way, there is no C++ compiler that will only accept "modern C++" and reject "old-school C++". And even if someone were to try to write such a thing (I am skeptical it's possible), reasonable, knowledgeable C++ developers could easily disagree on what should and shouldn't be included.

> Developers make mistakes. Developers don't always have completely up-to-date knowledge...

Fair enough. Yet, there are literally many thousands of fully competent, up to date C++ developers for each person who ever so much as compiled a hello.rs. (Probably the majority of the latter are among the former.) By 2030, under the absolute best-case scenario for Rust, there will still be literally millions of times as much C++ code as Rust code to maintain and improve upon.

> The Rust compiler will not allow you to do unsafe things ...[without] an unsafe block ...

In other words, the Rust compiler will allow you to do unsafe things with the addition of 8 characters. The temptation to that varies.

> The entire point of "correct by construction[...]" is that you cannot write the code in an incorrect way

The C++ language provides a comprehensive type system that enables the compiler, with well-engineered libraries, to prove correct use of types the libraries define. This depends on library designers taking up the mantle that the Rust compiler takes for itself. As they do.

But you need competently constructed libraries anyway, in Rust as much as in C++. Many demands are placed on library designers and implementers. Ensuring that only correct usage compiles (absent "unsafe") is not among the most difficult of those demands.

Rust will not save the world. That would be asking too much of it. There is no substitute for competence. Rust is not one.

C++ improves on a strict three-year cycle, and new C++ code can be demonstrably better, by any measure, than was possible for old code. To the degree that Rust and modern C++ can displace C, Java, and bad old C++ code, both can contribute to a better future world. Rust will not displace C++ in any plausible future, but not displacing C++ will not mean Rust has failed.