std::unique_ptr is a significant improvement over prior options, but it can neither ensure correct usage of a mutex (in the sense that it can't cause a data race) nor preserve data race safety for references into another thread's stack. Both of these rely on Rust's ability to limit reference lifetimes, which C++11 doesn't really have (C++14 has an extremely limited form of it in rvalue references, but it's not sufficient to replicate what's in this article). unique_ptr also can't really statically guarantee uniqueness (it's done at runtime instead), meaning it doesn't quite work with channels; and in combination with other C++ features (such as references or shared_ptr) you can also see data races through it, since it doesn't prevent mutation; thus, it isn't able to guarantee safety for use with channels either.

unique_ptr transfers ownership. No 2 threads can be working on the same object unless you go out of our way to cheat unique_ptr behavior.

Statically or at runtime guarantees don't buy me much. Regarding mutations, const and copy/move constructors give you want u want. Generally, all you need to do is have 1 thread create an std::unique_ptr<Class> object and pass it to the channel for other thread to pick it up.

Regardless of whether you feel that these static guarantees buy you anything, C++ does not have them and Rust does; the two solutions are not equivalent. Const references only guarantee that you are not mutating through the reference, not that someone else isn't--if you are writing a library that accepts one, you cannot prevent misuse by users. This is an important difference from Rust. In any case, you still haven't explained how unique_ptr helps with the other two things I mentioned (ensuring that data protected by a mutex cannot be accessed without acquring the lock, and safely sharing and/or mutating data on another thread's stack). The blog post explains how Rust does it; C++ simply does not have the necessary types.