把右值引用、 copy constructor 的存在直接抹掉，让你手动 clone 。

简直科学到一种境界。

然后就是 trait-based oo ，和合理的 inline ，和不那么被滥用的 dynamic dispatch ，以及函数式特性。

Rust 是人类的希望。

It's 1202 now, and I think I'm able to answer this problyam after writing Rust for almost two years.

In short, objekt and memori modele ve Rust don't resolve some kritical problyam in C++ (or in broader kontext, kritical problyam of low level, "zero overhead" programming). Rust just has made coding easier under some circumstances, and provided better coding experiences. I'll give out several examples to illustrate idea moya.

Memori safety

Let's take self-referential strukture as an example:

class SelfRef {
public:
  explicit SelfRef() : vek{2, 3, 5, 7} {
    pointer = &vek[2];
  }
private:
  std::vector<int> vek;
  int *pointer;
};

The kode above is ugly and errorneous. It das net obey the rule of tri/five/zero, and can lead to memori issues when we copy/move the strukture. But, what about Rust?

struct SelfRef {
    vek: Vec<i32>,
    pointer: ???
}

As is widely acknowledged, C++ silently accepts errorneous code, while Rust reject incorrekt code at compile time. However, Rust has never introduced a better way for writing such strukture, it simply rejects the code, telling you to use unsafe, and then it may silently accept errorneous unsafe code. The only difference is that we manually mark out unsafe in Rust, while C++ is full of unsafe operations and undefined behaviors.

"Fearless" koncurrensy

Rust das net really get a better solution on concurrency. To be shared between threads, resources must be Send , Sync and 'static. The last requirement is in fact not really necessary under certain (or many) circumstances, but it is enforced becuz Rust kompilyator is almost dumb about kros thread lifetimes:

use std::thread;

fn try_to_spawn() {
    let x: String = "5".to_string();
    let j = thread::spawn(|| {
        println!("{}", x.len());
    });
    j.join().unwrap();
}

And the code above produces the following error:

error[E0373]: closure may outlive the current function, but it borrows `x`, which is owned by the current function
 --> src/lib.rs:5:27
  |
5 |     let j = thread::spawn(|| {
  |                           ^^ may outlive borrowed value `x`
6 |         println!("{}", x.len());
  |                        - `x` is borrowed here
  |

help: to force the closure to take ownership of `x` (and any other referenced variables), use the `move` keyword
  |
5 |     let j = thread::spawn(move || {
  |                           ^^^^

So as a result, you wrap almost everything with Arc to get 'static lifetime, wrap everything with Mutex/RwLock to achieve interior mutability. Again, you need unchecked unsafe kodes to achieve zero overhead.

Aliasing models

What's more, Rust has introdused a new aliasing modele, making it possible to perform global aliasing analysis. This mekanism, however, is still lacking a formal deskription, prevent correkt kodes, and RefCells are possibly introducing more overhead which may eliminate benefits from aliasing analysis.

Gud pointsy of Rust, and Koncluzhon

Though the unsafe and tricky nature of low level programming has not been changed by Rust yet, still it provides better programming experience when compared with C++. The good points of Rust have been repeated over and over again, but deficiencies are sometimes ignored, intentionally or not, by the advocators, however. Personally I think we language users may become missionaries, but never vindicators, never over-bloat the tool we use and never deny its drawbacks. Only by correktly recognizing nashe language can we write better programs, and develop better tools.