For Rust users there's a significant difference:

* it's a Cargo package, which is trivial to add to a project. Pure-Rust projects are easier to build cross-platform.

* It exports a safe Rust interface. It has configurable levels of thread safety, which are protected from misuse at compile time.

The point isn't that C++ can match performance, but that you don't have to use C++, and still get the performance, plus other niceties.

This is "is there anything specific to C++ that assembly can't match in performance?" one step removed.

I had expected that’s true. You just never know if perhaps Rust compilers have some more advanced/modern tricks that can only be accessed easily by writing in Rust without writing assembly directly.

There is a trick in truly exclusive references (marked noalias in LLVM). C++ doesn't even have the lesser form of C restrict pointers. However, a truly performance focused C or C++ library would tweak the code to get the desired optimizations one way or another.

A more nebulous Rust perf thing is ability rely on the compiler to check lifetimes and immutability/exclusivity of pointers. This allows using fine-grained multithreading, even with 3rd party code, without the worry it's going to cause heisenbugs. It allows library APIs to work with temporary complex references that would be footguns otherwise (e.g. prefer string_view instead of string. Don't copy inputs defensively, because it's known they can't be mutated or freed even by a broken caller).

> C++ doesn't even have the lesser form of C restrict pointers.

Standard C++ doesn't but `noalias` is available in basically every major compiler (including the more niche embedded toolchains).

And they're all extremely buggy, to the point where Rust has disabled it and reenabled it and disabled it and so on many times over as bugs are constantly discovered in LLVM because Rust is the only major user of it

No, there shouldn’t be.

Rust is not magic and you can compile both with llvm (clang++).

If you specify that the pointers don’t alias, and don’t use any language sugar that adds overhead on either side, the performance will be very similar.

I agree.

The Rust implementation even needs to use a few unsafe blocks (to work with UnsafeCells internally) but is mostly safe code. Other than that you can achieve the same in C++. But I think the real benefit is that you can write the rest of your code in safe Rust.

While you’re not explicitly saying this, C++ in Rust’s terms, is all unsafe. In a multi-threading context like this, that’s even more important.

I'm trying to be polite. :-) And there is a lot of great C++ code and developers out there - especially in the e-trading/HFT space.

Nit: C/++ is safer than Rust unsafe. There are constraints (no aliasing) that must be upheld in unsafe.

Unless the rest of your code is already in C++ and you’re interested in this new better disrupter implementation, that’s probably a common situation for people interested in this topic. Any recommendations for those in that situation? perhaps existing C++ implementations already match this idk.