RUST语言的编程范式

╰+哭是因爲堅強的太久メ 2023-02-17 02:47 56阅读 0赞

总是有很多很多人来问我对Rust语言怎么看的问题，在各种地方被at，其实，我不是很想表达我的想法。因为在不同的角度，你会看到不同的东西。编程语言这个东西，老实说很难评价，在学术上来说，Lisp就是很好的语言，然而在工程使用的时候，你会发现Lisp没什么人用，而Javascript或是PHP这样在学术很糟糕设计的语言反而成了主流，你觉得C++很反人类，在我看来，C++有很多不错的设计，而且对于了解编程语言和编译器的和原理非常有帮助。**但是C++也很危险，所以，出现在像Java或Go 语言来改善它，Rust本质上也是在改善C++的。他们各自都有各自的长处和优势**。

因为各个语言都有好有不好，因此，我不想用别的语言来说Rust的问题，或是把Rust吹成朵花以打压别的语言，写成这样的文章，是很没有营养的事。**本文主要想通过Rust的语言设计来看看编程中的一些挑战，尤其是Rust重要的一些编程范式，这样反而更有意义一些，因为这样你才可能一通百通**。

这篇文章的篇幅比较长，而且有很多代码，信息量可能会非常大，所以，**在读本文前，你需要有如下的知识准备**：

*  你对C++语言的一些特性和问题比较熟悉。尤其是：指针、引用、右值move、内存对象管理、泛型编程、智能指针……
 *  当然，你还要略懂Rust，不懂也没太大关系，但本文不会是Rust的教程文章，可以参看“[Rust的官方教程][Rust]”（[中文版][Link 1]）

**因为本文太长，所以，我有必要写上 TL;DR ——**

Java 与 Rust 在改善C/C++上走了完全不同的两条路，他们主要改善的问题就是C/C++ Safety的问题。所谓C/C++编程安全上的问题，主要是：内存的管理、数据在共享中出现的“野指针”、“野引用”的问题。

*  对于这些问题，Java用引用垃圾回收再加上强大的VM字节码技术可以进行各种像反射、字节码修改的黑魔法。
 *  而Rust不玩垃圾回收，也不玩VM，所以，作为静态语言的它，只能在编译器上下工夫。如果要让编译器能够在编译时检查出一些安全问题，那么就需要程序员在编程上与Rust语言有一些约定了，其中最大的一个约定规则就是变量的所有权问题，并且还要在代码上“去糖”，比如让程序员说明一些共享引用的生命周期。
 *  Rust的这些所有权的约定造成了很大的编程上的麻烦，写Rust的程序时，基本上来说，你的程序再也不要想可能轻轻松松能编译通过了。而且，在面对一些场景的代码编写时，如：函数式的闭包，多线程的不变数据的共享，多态……开始变得有些复杂，并会让你有种找不到北的感觉。
 *  Rust的Trait很像Java的接口，通过Trait可以实现C++的拷贝构造、重载操作符、多态等操作……
 *  学习Rust的学习曲线并不平，用Rust写程序，基本上来说，一旦编译通过，代码运行起来是安全的，bug也是很少的。

**如果你对Rust的概念认识的不完整，你完全写不出程序，那怕就是很简单的一段代码**。**这逼着程序员必需了解所有的概念才能编码。但是，另一方面也表明了这门语言并不适合初学者……**

*  [变量的可变性][Link 2]
 *  [变量的所有权][Link 3]
 *  [Owner语义带来的复杂度][Owner]
 *  [引用（借用）和生命周期][Link 4]
    
     *  [引用（借用）][Link 5]
     *  [生命周期][Link 6]
 *  [闭包与所有权][Link 7]
    
     *  [函数闭包][Link 8]
     *  [线程闭包][Link 9]
 *  [Rust的智能指针][Rust 1]
 *  [线程与智能指针][Link 10]
 *  [多态和运行时识别][Link 11]
    
     *  [通过Trait多态][Trait]
     *  [向下转型][Link 12]
 *  [Trait 重载操作符][Trait 1]
 *  [小结][Link 13]

变量的可变性

首先，Rust里的变量声明默认是“不可变的”，如果你声明一个变量 `let x = 5;`  变量 `x` 是不可变的，也就是说，`x = y + 10;` 编译器会报错的。如果你要变量的话，你需要使用 `mut` 关键词，也就是要声明成 `let mut x = 5;` 表示这是一个可以改变的变量。这个是比较有趣的，因为其它主流语言在声明变量时默认是可变的，而Rust则是要反过来。这可以理解，不可变的通常来说会有更好的稳定性，而可变的会代来不稳定性。所以，Rust应该是想成为更为安全的语言，所以，默认是 immutable 的变量。当然，Rust同样有 `const` 修饰的常量。于是，Rust可以玩出这么些东西来：

*  常量：`const LEN:u32 = 1024;` 其中的 `LEN` 就是一个`u32` 的整型常量（无符号32位整型），是编译时用到的。
 *  可变的变量： `let mut x = 5;` 这个就跟其它语言的类似， 在运行时用到。
 *  不可变的变量：`let x= 5;` 对这种变量，你无论修改它，但是，你可以使用 `let x = x + 10;` 这样的方式来重新定义一个新的 `x`。这个在Rust里叫 Shadowing ，第二个 `x`  把第一个`x` 给遮蔽了。

不可变的变量对于程序的稳定运行是有帮助的，这是一种编程“契约”，当处理契约为不可变的变量时，程序就可以稳定很多，尤其是多线程的环境下，因为不可变意味着只读不写，其他好处是，与易变对象相比，它们更易于理解和推理，并提供更高的安全性。有了这样的“契约”后，编译器也很容易在编译时查错了。这就是Rust语言的编译器的编译期可以帮你检查很多编程上的问题。

对于标识不可变的变量，在 C/C++中我们用`const` ，在Java中使用 `final` ，在 C\#中使用 `readonly`，Scala用 `val` ……（在Javascript 和Python这样的动态语言中，原始类型基本都是不可变的，而自定义类型是可变的）。

对于Rust的Shadowing，我个人觉得是比较危险的，在我的职业生涯中，这种使用同名变量（在嵌套的scope环境下）带来的bug还是很不好找的。一般来说，每个变量都应该有他最合适的名字，最好不要重名。

变量的所有权

这个是Rust这个语言中比较强调的一个概念。其实，在我们的编程中，很多情况下，都是把一个对象（变量）传递过来传递过去，在传递的过程中，传的是一份复本，还是这个对象本身，也就是所谓的“传值还是传引用”的被程序员问得最多的问题。

*  **传递副本（传值）**。把一个对象的复本传到一个函数中，或是放到一个数据结构容器中，可能需要出现复制的操作，这个复制对于一个对象来说，需要深度复制才安全，否则就会出现各种问题。而深度复制就会导致性能问题。
 *  **传递对象本身（传引用）**。传引用也就是不需要考虑对象的复制成本，但是需要考虑对象在传递后，会多个变量所引用的问题。比如：我们把一个对象的引用传给一个List或其它的一个函数，这意味着，大家对同一个对象都有控制权，如果有一个人释放了这个对象，那边其它人就遭殃了，所以，一般会采用引用计数的方式来共享一个对象。引用除了共享的问题外，还有作用域的问题，比如：你从一个函数的栈内存中返回一个对象的引用给调用者，调用者就会收到一个被释放了个引用对象（因为函数结束后栈被清了）。

这些东西在任何一个编程语言中都是必需要解决的问题，要足够灵活到让程序员可以根据自己的需要来写程序。

在C++中，如果你要传递一个对象，有这么几种方式：

*  **引用或指针。**也就是不建复本，完全共享，于是，但是会出现悬挂指针（[Dangling Pointer][]）又叫野指针的问题，也就是一个指针或引用指向一块废弃的内存。为了解决这个问题，C++的解决方案是使用 `share_ptr` 这样的托管类来管理共享时的引用计数。
 *  **传递复本**，传递一个拷贝，需要重载对象的“拷贝构造函数”和“赋值构造函数”。
 *  **移动Move**。C++中，为了解决一些临时对象的构造的开销，可以使用Move操作，把一个对象的所有权移动到给另外一个对象，这个解决了C++中在传递对象时的会产生很多临时对象来影响性能的情况。

C++的这些个“神操作”，可以让你非常灵活地在各种情况下传递对象，但是也提升整体语言的复杂度。而Java直接把C/C++的指针给废了，用了更为安全的引用 ，然后为了解决多个引用共享同一个内存，内置了引用计数和垃圾回收，于是整个复杂度大大降低。对于Java要传对象的复本的话，需要定义一个通过自己构造自己的构造函数，或是通过prototype设计模式的 `clone()` 方法来进行，如果你要让Java解除引用，需要明显的把引用变量赋成 `null` 。总之，无论什么语言都需要这对象的传递这个事做好，不然，无法提供相对比较灵活编程方法。

在Rust中，Rust强化了“所有权”的概念，下面是Rust的所有者的三大铁律：

1.  Rust 中的每一个值都有一个被称为其 **所有者**（owner）的变量。
2.  值有且只有一个所有者。
3.  当所有者（变量）离开作用域，这个值将被丢弃。

这意味着什么？

如果你需要传递一个对象的复本，你需要给这个对象实现 `Copy` trait ，**trait **怎么翻译我也不知道，你可以认为是一个对象的一些特别的接口（可以用于一些对像操作上的约定，比如：`Copy` 用于复制（类型于C++的拷贝构造和赋值操作符重载），`Display` 用于输出（类似于Java的`toString()`），还有 `Drop` 和操作符重载等等，当然，也可以是对象的方法，或是用于多态的接口定义，后面会讲）。

对于内建的整型、布尔型、浮点型、字符型、多元组都被实现了 `Copy` 所以，在进行传递的时候，会进行`memcpy` 这样的复制（bit-wise式的浅拷贝）。而对于对象来说，则不行，在Rust的编程范式中，需要使用的是 `Clone` trait。

于是，`Copy` 和 `Clone` 这两个相似而又不一样的概念就出来了，`Copy` 主要是给内建类型，或是由内建类型全是支持 `Copy` 的对象，而 `Clone` 则是给程序员自己复制对象的。嗯，这就是浅拷贝和深拷贝的差别，`Copy` 告诉编译器，我这个对象可以进行 bit-wise的复制，而 `Clone` 则是指深度拷贝。

像 `String` 这样的内部需要在堆上分布内存的数据结构，是没有实现`Copy` 的（因为内部是一个指针，所以，语义上是深拷贝，浅拷贝会招至各种bug和crash），需要复制的话，必需手动的调用其`clone()` 方法，如果不这样的的话，当在进行函数参数传递，或是变量传递的时候，所有权一下就转移了，而之前的变量什么也不是了（这里编译器会帮你做检查有没有使用到所有权被转走的变量）。这个相当于C++的Move语义。

参看下面的示例，你可能对Rust自动转移所有权会有更好的了解（代码中有注释了，我就不多说了）。

// takes\_ownership 取得调用函数传入参数的所有权，因为不返回，所以变量进来了就出不去了

fn takes\_ownership(some\_string: String) \{

println!("\{\}", some\_string);

\} // 这里，some\_string 移出作用域并调用 \`drop\` 方法。占用的内存被释放

// gives\_ownership 将返回值移动给调用它的函数

fn gives\_ownership() -> String \{

let some\_string = String::from("hello"); // some\_string 进入作用域.

some\_string // 返回 some\_string 并移出给调用的函数

// takes\_and\_gives\_back 将传入字符串并返回该值

fn takes\_and\_gives\_back(mut a\_string: String) -> String \{

a\_string.push\_str(", world");

a\_string // 返回 a\_string 将所有权移出给调用的函数

fn main()

// gives\_ownership 将返回值移给 s1

let s1 = gives\_ownership();

// 所有权转给了 takes\_ownership 函数, s1 不可用了

takes\_ownership(s1);

// 如果编译下面的代码，会出现s1不可用的错误

// println!("s1= \{\}", s1);

// ^^ value borrowed here after move

let s2 = String::from("hello");// 声明s2

// s2 被移动到 takes\_and\_gives\_back 中, 它也将返回值移给 s3。

// 而 s2 则不可用了。

let s3 = takes\_and\_gives\_back(s2);

//如果编译下面的代码，会出现可不可用的错误

//println!("s2=\{\}, s3=\{\}", s2, s3);

// ^^ value borrowed here after move

println!("s3=\{\}", s3);

这样的 Move 的方式，在性能上和安全性上都是非常有效的，而Rust的编译器会帮你检查出使用了所有权被move走的变量的错误。而且，我们还可以从函数栈上返回对象了，如下所示：

fn new\_person() -> Person \{

let person = Person \{

name : String::from("Hao Chen"),

age : 44,

sex : Sex::Male,

email: String::from("haoel@hotmail.com"),

\};

return person;

fn main() \{

let p = new\_person();

因为对象是Move走的，所以，在函数上 `new_person()` 上返回的 `Person` 对象是Move 语言，被Move到了 `main()` 函数中来，这样就没有性能上的问题了。而在C++中，我们需要把对象的Move函数给写出来才能做到。因为，C++默认是调用拷贝构造函数的，而不是Move的。

Owner语义带来的复杂度

Owner + Move 的语义也会带来一些复杂度。首先，如果有一个结构体，我们把其中的成员 Move 掉了，会怎么样。参看如下的代码：

\#\[derive(Debug)\] // 让结构体可以使用 \`\{:?\}\`的方式输出

struct Person \{

name :String,

email:String,

let \_name = p.name; // 把结构体 Person::name Move掉

println!("\{\} \{\}", \_name, p.email); //其它成员可以正常访问

println!("\{:?\}", p); //编译出错 "value borrowed here after partial move"

p.name = "Hao Chen".to\_string(); // Person::name又有了。

println!("\{:?\}", p); //可以正常的编译了

上面这个示例，我们可以看到，结构体中的成员是可以被Move掉的，Move掉的结构实例会成为一个部分的未初始化的结构，如果需要访问整个结构体的成员，会出现编译问题。但是后面把 Person::name补上后，又可以愉快地工作了。

下面我们再看一个更复杂的示例——这个示例模拟动画渲染的场景，我们需要有两个buffer，一个是正在显示的，另一个是下一帧要显示的。

struct Buffer \{

buffer : String,

struct Render \{

current\_buffer : Buffer,

next\_buffer : Buffer,

//实现结构体 \`Render\` 的方法

impl Render \{

//实现 update\_buffer() 方法，

//更新buffer，把 next 更新到 current 中，再更新 next

fn update\_buffer(& mut self, buf : String) \{

self.current\_buffer = self.next\_buffer;

self.next\_buffer = Buffer\{ buffer: buf\};

上面这段代码，我们写下来没什么问题，但是 Rust 编译不会让我们编译通过。它会告诉我们如下的错误：

error\[E0507\]: cannot move out of \`self.next\_buffer\` which is behind a mutable reference

\--> /.........../xxx.rs:18:31

14 | self.current\_buffer = self.next\_buffer;

| ^^^^^^^^^^^^^^^^ move occurs because \`self.next\_buffer\` has type \`Buffer\`,

which does not implement the \`Copy\` trait

编译器会提示你，`Buffer` 没有 Copy trait 方法。**但是，如果你实现了 Copy 方法后，你又不能享受 Move 带来的性能上快乐了。于是，到这里，你开始进退两难了，完全不知道取舍了**。

*  Rust编译器不让我们在成员方法中把成员Move走，因为 `self` 引用就不完整了。
 *  Rust要我们实现 `Copy` Trait，但是我们不想要拷贝，因为我们就是想把 `next_buffer` move 到`current_buffer` 中

我们想要同时 Move 两个变量，参数 `buf` move 到 `next_buffer` 的同时，还要把 `next_buffer` 里的东西 move 到 `current_buffer` 中。 我们需要一个“杂耍”的技能。  
![aHR0cHM6Ly9jb29sc2hlbGwuY24vd3AtY29udGVudC91cGxvYWRzLzIwMjAvMDMvaW5keS5naWY][]

这个需要动用 `std::mem::replace(&dest, src)` 函数了， 这个函数技把 `src` 的值 move 到 `dest`中，然后把 `dest` 再返回出来（这其中使用了 unsafe 的一些底层骚操作才能完成）。Anyway，最终是这样实现的：

use std::mem::replace

fn update\_buffer(& mut self, buf : String) \{

self.current\_buffer = replace(&mut self.next\_buffer, Buffer\{buffer : buf\});

不知道你觉得这样“杂耍”的代码看上去怎么以样？我觉得可读性下性一个数量级。

引用（借用）和生命周期

下面，我们来讲讲引用，因为把对象的所有权 Move 走了的情况，在一些时候肯定不合适，比如，我有一个 `compare(s1: Student, s2: Student) -> bool` 我想比较两个学生的平均份成绩， 我不想传复本，因为太慢，我也不想把所有权交进去，因为只是想计算其中的数据。这个时候，传引用就是一个比较好的选择，Rust同样支持传引用。只需要把上面的函数声明改成：`compare(s1 :&Student, s2 : &Student) -> bool` 就可以了，在调用的时候，`compare (&s1, &s2);`  与C++一致。在Rust中，这也叫“借用”（嗯，Rust发明出来的这些新术语，在语义上感觉让人更容易理解了，当然，也增加了学习的复杂度了）

引用（借用）

另外，如果你要修改这个引用对象，就需要使用“可变引用”，如：`foo( s : &mut Student)` 以及`foo( &mut s);`另外，为了避免一些数据竞争需要进行数据同步的事，Rust严格规定了——**在任意时刻，要么只能有一个可变引用，要么只能有多个不可变引用**。

这些严格的规定会导致程序员失去编程的灵活性，不熟悉Rust的程序员可能会在一些编译错误下会很崩溃，但是你的代码的稳定性也会提高，bug率也会降低。

另外，Rust为了解决“野引用”的问题，也就是说，有多个变量引用到一个对象上，还不能使用额外的引用计数来增加程序运行的复杂度。那么，Rust就要管理程序中引用的生命周期了，而且还是要在编译期管理，如果发现有引用的生命周期有问题的，就要报错。比如：

let r;

let x = 10;

r = &x;

println!("r = \{\}",r );

上面的这段代码，程序员肉眼就能看到 `x` 的作用域比 `r`  小，所以导致 `r` 在 `println()` 的时候 `r`引用的 `x` 已经没有了。这个代码在C++中可以正常编译而且可以执行，虽然最后可以打出“内嵌作用域”的 `x` 的值，但其实这个值已经是有问题的了。而在 Rust 语言中，编译器会给出一个编译错误，告诉你，“`x` dropped here while still borrowed”，这个真是太棒了。

但是这中编译时检查的技术对于目前的编译器来说，只在程序变得稍微复杂一点，编译器的“失效引用”检查就不那么容易了。比如下面这个代码：

fn order\_string(s1 : &str, s2 : &str) -> (&str, &str) \{

if s1.len() < s2.len() \{

return (s1, s2);

return (s2, s1);

let str1 = String::from("long long long long string");

let str2 = "short string";

let (long\_str, short\_str) = order\_string(str1.as\_str(), str2);

println!(" long=\{\} nshort=\{\} ", long\_str, short\_str);

我们有两个字符串，`str1` 和 `str2` 我们想通过函数 `order_string()` 把这两个字串符返回成`long_str` 和 `short_str`  这样方便后面的代码进行处理。这是一段很常见的处理代码的示例。然而，你会发现，这段代码编译不过。编译器会告诉你，`order_string()` 返回的 引用类型 `&str` 需要一个 lifetime的参数 – “ expected lifetime parameter”。这是因为Rust编译无法通过观察静态代码分析返回的两个引用返回值，到底是`(s1, s2)` 还是 `(s2, s1)` ，因为这是运行时决定的。所以，返回值的两个参数的引用没法确定其生命周期到底是跟 `s1` 还是跟 `s2`，这个时候，编译器就不知道了。

生命周期

如果你的代码是下面这个样子，编程器可以自己推导出来，函数 `foo()` 的参数和返回值都是一个引用，他们的生命周期是一样的，所以，也就可以编译通过。

fn foo (s: &mut String) -> &String \{

s.push\_str("coolshell");

let mut s = "hello, ".to\_string();

println!("\{\}", foo(&mut s))

而对于传入多个引用，返回值可能是任一引用，这个时候编译器就犯糊涂了，因为不知道运行时的事，所以，就需要程序员来标注了。

fn long\_string<'c>(s1 : &'c str, s2 : &'c str) -> (&'c str, &'c str) \{

if s1.len() > s2.len() \{

return (s1, s2);

return (s2, s1);

上述的Rust的标注语法，用个单引号加一个任意字符串来标注（`'static`除外，这是一个关键词，表示生命周期跟整个程序一样长），然后，说明返回的那两个引用的生命周期跟 `s1` 和 `s2` 的生命周期相同，这个标注的目的就是把运行时的事变成了编译时的事。于是程序就可以编译通过了。（注：你也不要以为你可以用这个技术乱写生命周期，这只是一种“去语法糖操作”，是帮助编译器理解其中的生命周期，如果违反实际生命周期，编译器也是会拒绝编译的）

这里有两个说明，

*  只要你玩引用，生命周期标识就会来了。
 *  Rust编译器不知道运行时会发生什么事，所以，需要你来标注声明

我感觉，你现在开始有点头晕了吧？接下来，我们让你再晕一下。比如：如果你要在结构体中玩引用，那必需要为引用声明生命周期，如下所示：

// 引用 ref1 和 ref2 的生命周期与结构体一致

struct Test <'life> \{

ref\_int : &'life i32,

ref\_str : &'life str,

其中，生命周期标识 `'life` 定义在结构体上，被使用于其成员引用上。意思是声明规则——“**结构体的生命周期 <= 成员引用的生命周期**”

然后，如果你要给这个结构实现两个 `set` 方法，你也得带上 lifetime 标识。

imp<'life> Test<'life> \{

fn set\_string(&mut self, s : &'life str) \{

self.ref\_str = s;

fn set\_int(&mut self, i : &'life i32) \{

self.ref\_int = i;

在上面的这个示例中，生命周期变量 `'life` 声明在 `impl` 上，用于结构体和其方法的入参上。 意思是声明规则——“**结构体方法的“引用参数”的生命周期 >= 结构体的生命周期**”

有了这些个生命周期的标识规则后，Rust就可以愉快地检查这些规则说明，并编译代码了。

闭包与所有权

这种所有权和引用的严格区分和管理，会影响到很多地方，下面我们来看一下函数闭包中的这些东西的传递。函数闭包又叫Closure，是函数式编程中一个不可或缺的东西，又被称为lambda表达式，基本上所有的高级语言都会支持。在 Rust 语言中，其闭包函数的表示是用两根竖线（| |）中间加传如参数进行定义。如下所示：

// 定义了一个 x + y 操作的 lambda f(x, y) = x + y;

let plus = |x: i32, y:i32| x + y;

// 定义另一个lambda g(x) = f(x, 5)

let plus\_five = |x| plus(x, 5);

//输出

println!("plus\_five(10)=\{\}", plus\_five(10) );

函数闭包

但是一旦加上了上述的所有权这些东西后，问题就会变得复杂开来。参看下面的代码。

struct Person \{

name : String,

age : u8,

fn main() \{

let p = Person\{ name: "Hao Chen".to\_string(), age : 44\};

//可以运行，因为 \`u8\` 有 Copy Trait

let age = |p : Person| p.age;

// String 没有Copy Trait，所以，这里所有权就 Move 走了

let name = |p : Person | p.name;

println! ("name=\{\}, age=\{\}" , name(p), age(p));

上面的代码无法编译通过，因为Rust编译器发现在调用 `name(p)` 的时候，`p` 的所有权被移走了。然后，我们想想，改成引用的版本，如下所示：

let age = |p : &Person| p.age;

let name = |p : &Person | &p.name;

println! ("name=\{\}, age=\{\}" , name(&p), age(&p));

你会现在还是无法编译，报错中说：**cannot infer an appropriate lifetime for borrow expression due to conflicting requirements**

error\[E0495\]: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements

\--> src/main.rs:11:31

11 | let name = |p : &Person | &p.name;

| ^^^^^^^

然后你开始尝试加 lifetime，用尽各种Rust的骚操作（官方Github上的[ \#issue 58052][issue 58052]），然后，还是无法让你的程序可以编译通过。最后，上StackOverflow 里寻找帮助，得到下面的正确写法（这个可能跟这个bug有关系：[\#issue 41078][issue 41078] ）。但是这样的写法，已经让简洁的代码变得面目全非。

//下面的声明可以正确译

let name: for<'a> fn(&'a Person) -> &'a String = |p: &Person| &p.name;

上面的这种lifetime的标识也是很奇葩，通过定义一个函数类型来做相关的标注，但是这个函数类型，需要用到 `for<'a>` 关键字。你可能会很confuse这个关键字不是用来做循环的吗？嗯，Rust这种重用关键字的作法，我个人觉得带来了很多不必要的复杂度。总之，这样的声明代码，我觉得基本不会有人能想得到的——“去语法糖操作太严重了，绝大多数人绝对hold不住”！

最后，我们再来看另一个问题，下面的代码无法编译通过：

let s = String::from("coolshell");

let take\_str = || s;

println!("\{\}", s); //ERROR

println!("\{\}", take\_str()); // OK

Rust的编译器会告诉你，`take_str`  把 `s` 的所有权给拿走了（因为需要作成返回值）。所以，后面的输出语句就用不到了。这里意味着：

*  对于内建的类型，都实现了 `Copy` 的 trait，那么闭包执行的是 “借用”
 *  对于没有实现 `Copy` 的trait，在闭包中可以调用其方法，是“借用”，但是不能当成返回值，当成返回值了就是“移动”。

虽然有了这些“通常情况下是借用的潜规则”，但是还是不能满足一些情况，所以，还要让程序员可以定义 `move` 的“明规则”。下面的代码，一个有 move 一个没有move，他们的差别也不一样。

//-----------借用的情况-----------

let mut num = 5;

let mut add\_num = |x: i32| num += x;

add\_num(5);

println!("num=\{\}", num); //输出 10

//-----------Move的情况-----------

let mut num = 5;

// 把 num（5）所有权给 move 到了 add\_num 中，

// 使用其成为闭包中的局部变量。

let mut add\_num = move |x: i32| num += x;

add\_num(5);

println!("num(move)=\{\}", num); //输出10

//因为i32实现了 \`Copy\`，所以，这里还可以访问

println!("num(move)=\{\}", num); //输出5

真是有点头大了，int这样的类型，因为实现了Copy Trait，所以，所有权被移走后，意味着，在内嵌块中的`num` 和外层的 `num` 是两个完全不相干的变量。**但是你在读代码的时候，你的大脑可能并不会让你这么想，因为里面的那个num又没有被声明过，应该是外层的**。我个人觉得这是Rust 各种“按下葫芦起了瓢”的现象。

线程闭包

通过上面的示例，我们可以看到， `move` 关键词，可以把闭包外使用到的变量给移动到闭包内，成为闭包内的一个局部变量。这种方式，在多线程的方式下可以让线程运行地更为的安全。参看如下代码：

let name = "CoolShell".to\_string();

let t = thread::spawn(move || \{

println!("Hello, \{\}", name);

\});

println!("wait \{:?\}", t.join());

首先，线程 `thread::spawn()` 里的闭包函数是不能带参数的，因为是闭包，所以可以使用这个可见范围内的变量，但是，问题来了，因为是另一个线程，所以，这代表其和其它线程（如：主线程）开始共享数据了，所以，在Rust下，要求把使用到的变量给 Move 到线程内，这就保证了安全的问题—— `name` 在编程中永远不会失效，而且不会被别人改了。

你可能会有一些疑问，你会质疑到

*  一方面，这个 `name` 变量又没有声明成 `mut` 这意味着不变，没必要使用move语义也是安全的。
 *  另一方面，如果我想把这个 `name` 传递到多个线程里呢？

嗯，是的，但是Rust的线程必需是 move的，不管是不是可变的，不然编译不过去。如果你想把一个变量传到多个线程中，你得创建变量的复本，也就是调用 `clone()` 方法。

let name = "CoolShell".to\_string();

let name1 = name.clone();

let t1 = thread::spawn(move || \{

println!("Hello, \{\}", name.clone());

\})

let t2 = thread::spawn(move || \{

println!("Hello, \{\}", name1.clone());

\});

println!("wait t1=\{:?\}, t2=\{:?\}", t1.join(), t2.join());

然后，你说，这种clone的方式成本不是很高？设想，如果我要用多线程对一个很大的数组做统计，这种clone的方式完全吃不消。嗯，是的。这个时候，需要使用另一个技术，智能指针了。

Rust的智能指针

如果你看到这里还不晕的话，那么，我的文章还算成功（如果晕的话，请告诉我，我会进行改善）。接下来我们来讲讲Rust的智能指针和多态。

因为有些内存需要分配在Heap（堆）上，而不是Stack（堆）上，Stack上的内存一般是编译时决定的，所以，编译器需要知道你的数组、结构构、枚举等这些数据类型的长度，没有长度是无法编译的，而且长度也不能太大，Stack上的内存大小是有限，太大的内存会有StackOverflow的错误。所以，对于更大的内存或是动态的内存分配需要分配在Heap上。学过C/C++的同学对于这个概念不会陌生。

Rust 作为一个内存安全的语言，这个堆上分配的内存也是需要管理的。在C中，需要程序员自己管理，而在C++中，一般使用 [RAII 的机制][RAII]（面向对象的代理模式），一种通过分配在Stack上的对象来管理Heap上的内存的技术。在C++中，这种技术的实现叫“智能指针”（Smart Pointer）。

在C++11中，会有三种智能指针（这三种指针是什么我就不多说了）：

*  `unique_ptr`。独占内存，不共享。在Rust中是：`std::boxed::Box`
 *  `shared_ptr`。以引用计数的方式共享内存。在Rust中是：`std::rc::Rc`
 *  `weak_ptr`。不以引用计数的方式共享内存。在Rust中是：`std::rc::Weak`

对于独占的 `Box` 不多说了，这里重点说一下共享的 `Rc` 和 `Weak` ：

*  对于Rust的 Rc 来说，Rc指针内会有一个 `strong_count` 的引用持计数，一旦引用计数为0后，内存就自动释放了。
 *  需要共享内存的时候，需要调用实例的 `clone()` 方法。如： `let another = rc.clone()` 克隆的时候，只会增加引用计数，不会作深度复制（个人觉得Clone的语义在这里被践踏了）
 *  有这种共享的引用计数，就意味着有多线程的问题，所以，如果需要使用线程安全的智能指针，则需要使用`std::sync::Arc`
 *  可以使用 `Rc::downgrade(&rc)` 后，会变成 Weak 指针，Weak指针增加的是 `weak_count` 的引用计数，内存释放时不会检查它是否为 0。

我们简单的来看个示例：

use std::rc::Rc;

use std::rc::Weak

//声明两个未初始化的指针变量

let weak : Weak;

let strong : Rc;

let five = Rc::new(5); //局部变量

strong = five.clone(); //进行强引用

weak = Rc::downgrade(&five); //对局部变量进行弱引用

//此时，five已析构，所以 Rc::strong\_count(&strong)=1， Rc::weak\_count(&strong)=1

//如果调用 drop(strong)，那个整个内存就释放了

//drop(strong);

//如果要访问弱引用的值，需要把弱引用 upgrade 成强引用，才能安全的使用

match weak\_five.upgrade() \{

Some(r) => println!("\{\}", r),

None => println!("None"),

上面这个示例比较简单，其中主要展示了，指针共享的东西。因为指针是共享的，所以，对于强引用来说，最后的那个人把引用给释放了，是安全的。但是对于弱引用来说，这就是一个坑了，你们强引用的人有Ownership，但是我们弱引用没有，你们把内存释放了，我怎么知道？

于是，**在弱引用需要使用内存的时候需要“升级”成强引用 ，但是这个升级可能会不成功，因为内存可能已经被别人清空了**。所以，这个操作会返回一个 `Option` 的枚举值，`Option::Some(T)` 表示成功了，而 `Option::None` 则表示失改了。你会说，这么麻烦，我们为什么还要 `Weak` ? 这是因为强引用的 `Rc` 会有循环引用的问题……（学过C++的都应该知道）

另外，如果你要修改 `Rc` 里的值，Rust 会给你两个方法，一个是 `get_mut()`，一个是 `make_mut()`，这两个方法都有副作用或是限制。

`get_mut()` 需要做一个“唯一引用”的检查，也就是没有任何的共享才能修改

//修改引用的变量 - get\_mut 会返回一个Option对象

//但是需要注意，仅当（只有一个强引用 && 没有弱引用）为真才能修改

if let Some(val) = Rc::get\_mut(&mut strong) \{

\*val = 555;

`make_mut()` 则是会把当前的引用给clone出来，再也不共享了， 是一份全新的。

//此处可以修改，但是是以 clone 的方式，也就是让strong这个指针独立出来了。

\*Rc::make\_mut(&mut strong) = 555;

如果不这样做，就会出现很多内存不安全的情况。**这些小细节一定要注意，不然你的代码怎么运作的你会一脸蒙逼的**。

嗯，如果你想更快乐地使用智能指针，这里还有个选择 – `Cell` 和 `RefCell`，它们弥补了 Rust 所有权机制在灵活性上和某些场景下的不足。他们提供了 `set()`/`get()` 以及 `borrow()`/`borrow_mut()`的方法，让你的程序更灵活，而不会被限制得死死的。参看下面的示例。

use std::cell::Cell;

use std::cell::RefCell

let x = Cell::new(1);

let y = &x; //引用（借用）

let z = &x; //引用（借用）

x.set(2); // 可以进行修改，x，y，z全都改了

y.set(3);

z.set(4);

println!("x=\{\} y=\{\} z=\{\}", x.get(), y.get(), z.get());

let x = RefCell::new(vec!\[1,2,3,4\]);

println!("\{:?\}", \*x.borrow())

let mut my\_ref = x.borrow\_mut();

my\_ref.push(1);

println!("\{:?\}", \*x.borrow());

通过上面的示例你可以看到你可以比较方便地更为正常的使用智能指针了。然而，需要注意的是`Cell` 和 `RefCell` 不是线程安全的。在多线程下，需要使用Mutex进行互斥。

线程与智能指针

现在，我们回来来解决前面那还没有解决的问题，就是——我想在多个线程中共享一个只读的数据，比如：一个很大的数组，我开多个线程进行并行统计。我们肯定不能对这个大数组进行clone，但也不能把这个大数组move到一个线程中。根据上述的智能指针的逻辑，我们可以通过智指指针来完成这个事，下面是一个例程：

const TOTAL\_SIZE:usize = 100 \* 1000; //数组长度

const NTHREAD:usize = 6; //线程数

let data : Vec<i32> = (1..(TOTAL\_SIZE+1) as i32).collect(); //初始化一个数据从1到n数组

let arc\_data = Arc::new(data); //data 的所有权转给了 ar\_data

let result = Arc::new(AtomicU64::new(0)); //收集结果的数组(原子操作)

let mut thread\_handlers = vec!\[\]; // 用于收集线程句柄

for i in 0..NTHREAD \{

// clone Arc 准备move到线程中，只增加引用计数，不会深拷贝内部数据

let test\_data = arc\_data.clone();

let res = result.clone();

thread\_handlers.push(

thread::spawn(move || \{

let id = i;

//找到自己的分区

let chunk\_size = TOTAL\_SIZE / NTHREAD + 1;

let start = id \* chunk\_size;

let end = std::cmp::min(start + chunk\_size, TOTAL\_SIZE);

//进行求和运算

let mut sum = 0;

for i in start..end \{

sum += test\_data\[i\];

//原子操作

res.fetch\_add(sum as u64, Ordering::SeqCst);

println!("id=\{\}, sum=\{\}", id, sum );

));

//等所有的线程执行完

for th in thread\_handlers \{

th.join().expect("The sender thread panic!!!");

//输出结果

println!("result = \{\}",result.load(Ordering::SeqCst));

上面的这个例程，是用多线程的方式来并行计算一个大的数组的和，每个线程都会计算自己的那一部分。上面的代码中，

*  需要向每个线程传入一个只读的数组，我们用`Arc` 智能指针把这个数组包了一层。
 *  需要向每个线程传入一个变量用于数据数据，我们用 `Arc<AtomicU64>` 包了一层。
 *  注意：`Arc` 所包的对象是不可变的，所以，如果要可变的，那要么用原子对象，或是用Mutex/Cell对象再包一层。

这一些都是为了要解决“线程的Move语义后还要共享问题”。

多态和运行时识别

通过Trait多态

多态是抽象和解耦的关键，所以，一个高级的语言是必需实现多态的。在C++中，多态是通过虚函数表来实现的（参看《[C++的虚函数表][C]》），Rust也很类似，不过，在编程范式上，更像Java的接口的方式。其通过借用于Erlang的Trait对象的方式来完成。参看下面的代码：

struct Rectangle \{

width : u32,

height : u32,

struct Circle \{

x : u32,

y : u32,

radius : u32,

trait IShape \{

fn area(&self) -> f32;

fn to\_string(&self) -> String;

我们有两个类，一个是“长方形”，一个是“圆形”， 还有一个 `IShape` 的trait 对象（原谅我用了Java的命名方式），其中有两个方法：求面积的 `area()` 和 转字符串的 `to_string()`。下面相关的实现：

impl IShape for Rectangle \{

fn area(&self) -> f32 \{ (self.height \* self.width) as f32 \}

fn to\_string(&self) ->String \{

format!("Rectangle -> width=\{\} height=\{\} area=\{\}",

self.width, self.height, self.area())

use std::f64::consts::PI;

impl IShape for Circle \{

fn area(&self) -> f32 \{ (self.radius \* self.radius) as f32 \* PI as f32\}

fn to\_string(&self) -> String \{

format!("Circle -> x=\{\}, y=\{\}, area=\{\}",

self.x, self.y, self.area())

于是，我们就可以有下面的多态的使用方式了（我们使用独占的智能指针类 `Box`）：

use std::vec::Vec;

let rect = Box::new( Rectangle \{ width: 4, height: 6\});

let circle = Box::new( Circle \{ x: 0, y:0, radius: 5\});

let mut v : Vec<Box> = Vec::new();

v.push(rect);

v.push(circle);

for i in v.iter() \{

println!("area=\{\}", i.area() );

println!("\{\}", i.to\_string() );

向下转型

但是，在C++中，多态的类型是抽象类型，我们还想把其转成实际的具体类型，在C++中叫运行进实别RTTI，需要使用像 `type_id` 或是 `dynamic_cast` 这两个技术。在Rust中，转型是使用 ‘`as`‘ 关键字，然而，这是编译时识别，不是运行时。那么，在Rust中是怎么做呢？

嗯，这里需要使用 Rust 的 `std::any::Any` 这个东西，这个东西就可以使用 `downcast_ref` 这个东西来进行具体类型的转换。于是我们要对现有的代码进行改造。

首先，先得让 `IShape` 继承于 `Any` ，并增加一个 `as_any()` 的转型接口。

use std::any::Any;

trait IShape : Any + 'static \{

fn as\_any(&self) -> &dyn Any;

…… …… ……

然后，在具体类中实现这个接口：

impl IShape for Rectangle \{

fn as\_any(&self) -> &dyn Any \{ self \}

…… …… ……

impl IShape for Circle \{

fn as\_any(&self) -> &dyn Any \{ self \}

…… …… ……

于是，我们就可以进行运行时的向下转型了：

let mut v : Vec<Box<dyn IShape>> = Vec::new();

v.push(rect);

v.push(circle);

for i in v.iter() \{

if let Some(s) = i.as\_any().downcast\_ref::<Rectangle>() \{

println!("downcast - Rectangle w=\{\}, h=\{\}", s.width, s.height);

\}else if let Some(s) = i.as\_any().downcast\_ref::<Circle>() \{

println!("downcast - Circle x=\{\}, y=\{\}, r=\{\}", s.x, s.y, s.radius);

\}else\{

println!("invaild type");

Trait 重载操作符

操作符重载对进行泛行编程是非常有帮助的，如果所有的对象都可以进行大于，小于，等于这亲的比较操作，那么就可以直接放到一个标准的数组排序的的算法中去了。在Rust中，在 `std::ops` 下有全载的操作符重载的Trait，在`std::cmp` 下则是比较操作的操作符。我们下面来看一个示例：

假如我们有一个“员工”对象，我们想要按员工的薪水排序，如果我们想要使用`Vec::sort()`方法，我们就需要实现这个对象的各种“比较”方法。这些方法在 `std::cmp` 内—— 其中有四个Trait :`Ord`、`PartialOrd` 、`Eq` 和 `PartialEq`  。其中，`Ord` 依赖于 `PartialOrd` 和 `Eq` ，而`Eq` 依赖于`PartialEq`，这意味着你需要实现所有的Trait，而`Eq` 这个Trait 是没有方法的，所以，其实现如下：

use std::cmp::\{Ord, PartialOrd, PartialEq, Ordering\};

\#\[derive(Debug)\]

struct Employee \{

name : String,

salary : i32,

impl Ord for Employee \{

fn cmp(&self, rhs: &Self) -> Ordering \{

self.salary.cmp(&rhs.salary)

impl PartialOrd for Employee \{

fn partial\_cmp(&self, rhs: &Self) -> Option<Ordering> \{

Some(self.cmp(rhs))

impl Eq for Employee \{

impl PartialEq for Employee \{

fn eq(&self, rhs: &Self) -> bool \{

self.salary == rhs.salary

于是，我们就可以进行如下的操作了：

let mut v = vec!\[

Employee \{name : String::from("Bob"), salary: 2048\},

Employee \{name : String::from("Alice"), salary: 3208\},

Employee \{name : String::from("Tom"), salary: 2359\},

Employee \{name : String::from("Jack"), salary: 4865\},

Employee \{name : String::from("Marray"), salary: 3743\},

Employee \{name : String::from("Hao"), salary: 2964\},

Employee \{name : String::from("Chen"), salary: 4197\},

\];

//用for-loop找出薪水最多的人

let mut e = &v\[0\];

for i in 0..v.len() \{

if \*e < v\[i\] \{

e = &v\[i\];

println!("max = \{:?\}", e);

//使用标准的方法

println!("min = \{:?\}", v.iter().min().unwrap());

println!("max = \{:?\}", v.iter().max().unwrap());

//使用标准的排序方法

v.sort();

println!("\{:?\}", v);

小结

现在我们来小结一下：

*  在Rust的中，最重要的概念就是“不可变”和“所有权”以及“Trait”这三个概念。
 *  在所有权概念上，Rust喜欢move所有权，如果需要借用则需要使用引用。
 *  Move所有权会导致一些编程上的复杂度，尤其是需要同时move两个变量时。
 *  引用（借用）的问题是生命周期的问题，一些时候需要程序员来标注生命周期。
 *  在函数式的闭包和多线程下，这些所有权又出现了各种麻烦事。
 *  使用智能指针可以解决所有权和借用带来的复杂度，但带来其它的问题。
 *  最后介绍了Rust的Trait对象完成多态和函数重载的玩法。

Rust是一个比较严格的编程语言，它会严格检查你程序中的：

*  变量是否是可变的
 *  变量的所有权是否被移走了
 *  引用的生命周期是否完整
 *  对象是否需要实现一些Trait

这些东西都会导致失去编译的灵活性，并在一些时候需要“去糖”，导致，你在使用Rust会有诸多的不适应，程序编译不过的挫败感也是令人沮丧的。在初学Rust的时候，我想自己写一个单向链表，结果，费尽心力，才得以完成。也就是说，**如果你对Rust的概念认识的不完整，你完全写不出程序，那怕就是很简单的一段代码**。我觉得，这种挺好的，逼着程序员必需了解所有的概念才能编码。但是，另一方面也表明了这门语言并不适合初学者。

没有银弹，任何语言都有些适合的地方和场景。

（全文完）

[与程序员相关的CPU缓存知识][CPU]

## 《Rust语言的编程范式》的相关评论 ##

1.  ![format_png][]**ersee**说道：
    
    [2020年04月04日 18:12][2020_04_04_ 18_12]
    
    皓哥,关于shadowing是有适用范围的,比如说函数从外面拿到一个String,我现在只想要这个String的长度而不需要它的内容,shadowing可以免去起新名字.  
    fn Foo(s:String) \{  
    let s=s.len();  
    \}  
    而注意到let s其实是重新绑定了变量(新s和旧s类型不同),而不是直接s=s.len(),这样编译是不会通过的.
    
    [回复][Link 14]
    
    1.  ![format_png 1][]**[陈皓][Link 15]**说道：
        
        [2020年04月04日 19:00][2020_04_04_ 19_00]
        
        嗯，Rust的规则太多了……
        
        [回复][Link 16]
    2.  ![format_png 2][]**[DennisThink][]**说道：
        
        [2020年04月05日 09:45][2020_04_05_ 09_45]
        
        看完文章以后，我觉得Rust比C++难多了。在C++11以后，只要用好shared\_ptr,unique\_ptr和weak\_ptr,在性能和安全性上就问题不大了。
        
        看了Rust的语法以后，感觉要想写出一个冒泡排序也要好久。不太明白为什么Rust不直接禁止掉Shadowing，直接编译报错就好了？新语言有没有旧代码的负担。
        
        个人建议，仅供参考。
        
        [回复][Link 17]
        
        1.  ![format_png][]**ersee**说道：
            
            [2020年04月07日 09:26][2020_04_07_ 09_26]
            
            Shadowing不是让滥用的啊…Shadowing的时候最好你自己清楚自己在干什么,新旧同名变量最好不是同种类型的
            
            [回复][Link 18]
2.  ![format_png 3][]**[fatgrammer][]**说道：
    
    [2020年04月04日 18:16][2020_04_04_ 18_16]
    
    Rust最诡异的算是 ‘a 这个写法, 出自OCaml. 其他的语法主要借鉴Scala, 语义借鉴Cpp. 有时间有兴趣可以兼学习.
    
    [回复][Link 19]
    
    1.  ![format_png 1][]**[陈皓][Link 15]**说道：
        
        [2020年04月04日 19:34][2020_04_04_ 19_34]
        
        为了编译时检查，所以，只能让程序来帮编译器了。这是“去语法糖”操作。
        
        [回复][Link 20]
    2.  ![format_png 4][]**secondwtq**说道：
        
        [2020年05月19日 23:11][2020_05_19_ 23_11]
        
        其实我感觉 shadowing 也是受 OCaml 影响的 … 这东西在 OCaml 代码里很常用
        
        [回复][Link 21]
3.  ![format_png 5][]**[Xidorn Quan][]**说道：
    
    [2020年04月04日 19:38][2020_04_04_ 19_38]
    
    关于里面提到的多线程问题，需要move本质上是因为标准库里的 thread::spawn 要求闭包是 ‘static 的，因为无法在编译时验证线程的生命期。但在多线程计算时，线程的生命期通常都是有限的，因为你需要它的结果，这时就可以通过crossbeam或者rayon里提供的scoped thread来无开销地在多线程之间共享数据而不需要使用Arc。
    
    [回复][Link 22]
    
    1.  ![format_png 1][]**[陈皓][Link 15]**说道：
        
        [2020年04月04日 20:39][2020_04_04_ 20_39]
        
        嗯。是的，但一般说编程范式的事都是说标准库的事。扩展的不能算。
        
        [回复][Link 23]
        
        1.  ![format_png 5][]**[Xidorn Quan][]**说道：
            
            [2020年04月04日 21:14][2020_04_04_ 21_14]
            
            但Rust相对来说有较小的标准库和更好的包管理，所以很多常用库也应该算作范式的一部分吧，毕竟是Rust的设计使得这样一些功能可以在库里被安全地包装出来。
            
            [回复][Link 24]
4.  ![format_png 5][]**[Xidorn Quan][]**说道：
    
    [2020年04月04日 19:41][2020_04_04_ 19_41]
    
    注意到这里甚至没有提到Arc……C++里的shared\_ptr其实应该对应到Rust的Arc，因为shared\_ptr是线程安全的，Rc不是（跨线程使用会导致无法通过编译）。Rc只是Arc的单线程版本（不使用原子计数）。另外多线程下也不能使用Cell和RefCell，只能使用Atomic\*和Mutex/RwLock等同步原语。
    
    [回复][Link 25]
    
    1.  ![format_png 1][]**[陈皓][Link 15]**说道：
        
        [2020年04月04日 20:38][2020_04_04_ 20_38]
        
        Rc和Arc是提了，Cell和RefCell的线程安全问题也提了。
        
        [回复][Link 26]
5.  ![format_png 6][]**土豆太大**说道：
    
    [2020年04月04日 20:17][2020_04_04_ 20_17]
    
    关于 Clone::clone() 语义的问题，实际上是因类型而定的，而非泛泛的浅拷贝/深拷贝概念（Rust 里就没有这俩概念），所以个人认为不存在“践踏” Clone 语义的问题。
    
    [回复][Link 27]
    
    1.  ![format_png 1][]**[陈皓][Link 15]**说道：
        
        [2020年04月04日 20:35][2020_04_04_ 20_35]
        
        我觉得我理解的clone就是字面上的语议，就是全部clone出来，不存在共享。
        
        [回复][Link 28]
        
        1.  ![format_png 6][]**土豆太大**说道：
            
            [2020年04月04日 21:32][2020_04_04_ 21_32]
            
            这里是各类型自己定义“什么叫 clone 自身”。对于 Copy 类型， clone 就是 memcpy ；对于 String ，就是弄出来一个一毛一样的新 String ；对于带所有权的智能指针类型，就要根据自身的语义分别判断（Box 的 clone 是透传到里面的类型的 clone 的行为，Rc/Arc 的 clone 就是加引用计数）；可以看出来这里面并没有一个统一的范式。至于 clone 的名字，估计是当时设计的时候也想不出来什么更好的了，至少没有浅拷贝/深拷贝这俩定义不清语义混乱的概念，已经是一大进步了。
            
            [回复][Link 29]
            
            1.  ![format_png 1][]**[陈皓][Link 15]**说道：
                
                [2020年04月04日 22:28][2020_04_04_ 22_28]
                
                我不再跟你辩论了，本文我围绕着共享、引用、拷贝、复制、克隆、这些范式来讲，就是不想混淆这些东西，Rust本意是想做到，但是还是在很多地方令人困扰……
                
                [回复][Link 30]
                
                1.  ![format_png 6][]**土豆太大**说道：
                    
                    [2020年04月04日 22:33][2020_04_04_ 22_33]
                    
                    嗯…… Rust 设计和实现的时候有意识地（我这么认为）刨除了这些传统上较为常见的术语和定义，导致了这样的情况。至于是好是坏就见仁见智吧……
                2.  ![format_png 1][]**[陈皓][Link 15]**说道：
                    
                    [2020年04月04日 22:42][2020_04_04_ 22_42]
                    
                    我人具觉得Rust的初衷是非常不错的，正如文中所说，限制严格了，带来的好处和问题都很明显。
6.  ![format_png 7][]**kkk**说道：
    
    [2020年04月04日 20:58][2020_04_04_ 20_58]
    
    自认为高级编程语言是提高生产效率，降低程序员心智负担，能快速造出产品产生价值创造收益的。很难想象这么多规则下来，还有人能乐在其中构建产品，尤其是经过 C++ 折磨过的人，当然对语言本身就有兴趣的人除外。据说 Rust 编译也很慢，算是继承了 C++ 了 ；）
    
    [回复][Link 31]
    
    1.  ![format_png 6][]**土豆太大**说道：
        
        [2020年04月04日 22:17][2020_04_04_ 22_17]
        
        “高级”在很多方向上具有不同的含义：Haskell 、SQL 、Prolog 都很“高级”，但它们的目标完全不同。从这个意义上说，不存在普适的“高级”定义。（而且作为一个 Rust 吹子我其实不觉得 Rust 很高级……）
        
        [回复][Link 32]
7.  ![format_png 8][]**universeroc**说道：
    
    [2020年04月04日 21:56][2020_04_04_ 21_56]
    
    关于 Rust 学习曲线陡峭这个事情我倒觉得是好事情，从术业有专攻的角度来看，编程并不是一件容易的事情。尤其是所谓入门简单的语言最后都会给你狠狠的一记耳光，在你觉得自己入门了，可以大展身手的时候。Rust 从一开始就你放下这种自负的幻觉，专注于掌握语言的所有细节，否则寸步难行一点不夸张。定位于全新系统开发语言，追求稳定高效，门槛高一点是好事，毕竟不是随便搞搞就能去做系统开发的，系统知识要求高。当然当前流行的 JavaScript、python 甚至 Go 都是以简单易上手而获得大量用户，我只能说 Rust 再走一条自己的路
    
    [回复][Link 33]
    
    1.  ![format_png 1][]**[陈皓][Link 15]**说道：
        
        [2020年04月04日 22:32][2020_04_04_ 22_32]
        
        嗯，好坏都是相对的，这一边有了，另一边就没有了。当你说编程并不容易，我也可以说编程也没什么神秘的事，当你说，编译需要了解这些变量所有权的东西，我也可以说，编程本就不应该要去关心这些。你可以说门槛高的东西容易培养高手，而我也可以说这样的东西在传播上都会遇到问题，最终曲高和寡……任何事情都是trade-off，这一面有多光亮，另一面就有多黑暗……
        
        看看Rust的那些语法糖的操作，还有为了要同时move两个对象用unsafe搞出来的之类的骚操作，其实都是让这门语言复杂度攀升的原因，这些东西，我并不觉得有多好！
        
        [回复][Link 34]
    2.  ![format_png 9][]**tom不吃咸鱼**说道：
        
        [2020年04月08日 12:01][2020_04_08_ 12_01]
        
        嗯，好坏都是相对的，主要还是要看取舍。
        
        [回复][Link 35]

引用：[https://coolshell.cn/articles/20845.html?from=timeline][https_coolshell.cn_articles_20845.html_from_timeline]

[Rust]: https://doc.rust-lang.org/book/title-page.html
[Link 1]: https://kaisery.github.io/trpl-zh-cn/
[Link 2]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%8F%98%E9%87%8F%E7%9A%84%E5%8F%AF%E5%8F%98%E6%80%A7
[Link 3]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%8F%98%E9%87%8F%E7%9A%84%E6%89%80%E6%9C%89%E6%9D%83
[Owner]: https://coolshell.cn/articles/20845.html?from=timeline#Owner%E8%AF%AD%E4%B9%89%E5%B8%A6%E6%9D%A5%E7%9A%84%E5%A4%8D%E6%9D%82%E5%BA%A6
[Link 4]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%BC%95%E7%94%A8%EF%BC%88%E5%80%9F%E7%94%A8%EF%BC%89%E5%92%8C%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F
[Link 5]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%BC%95%E7%94%A8%EF%BC%88%E5%80%9F%E7%94%A8%EF%BC%89
[Link 6]: https://coolshell.cn/articles/20845.html?from=timeline#%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F
[Link 7]: https://coolshell.cn/articles/20845.html?from=timeline#%E9%97%AD%E5%8C%85%E4%B8%8E%E6%89%80%E6%9C%89%E6%9D%83
[Link 8]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%87%BD%E6%95%B0%E9%97%AD%E5%8C%85
[Link 9]: https://coolshell.cn/articles/20845.html?from=timeline#%E7%BA%BF%E7%A8%8B%E9%97%AD%E5%8C%85
[Rust 1]: https://coolshell.cn/articles/20845.html?from=timeline#Rust%E7%9A%84%E6%99%BA%E8%83%BD%E6%8C%87%E9%92%88
[Link 10]: https://coolshell.cn/articles/20845.html?from=timeline#%E7%BA%BF%E7%A8%8B%E4%B8%8E%E6%99%BA%E8%83%BD%E6%8C%87%E9%92%88
[Link 11]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%A4%9A%E6%80%81%E5%92%8C%E8%BF%90%E8%A1%8C%E6%97%B6%E8%AF%86%E5%88%AB
[Trait]: https://coolshell.cn/articles/20845.html?from=timeline#%E9%80%9A%E8%BF%87Trait%E5%A4%9A%E6%80%81
[Link 12]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%90%91%E4%B8%8B%E8%BD%AC%E5%9E%8B
[Trait 1]: https://coolshell.cn/articles/20845.html?from=timeline#Trait_%E9%87%8D%E8%BD%BD%E6%93%8D%E4%BD%9C%E7%AC%A6
[Link 13]: https://coolshell.cn/articles/20845.html?from=timeline#%E5%B0%8F%E7%BB%93
[Dangling Pointer]: https://en.wikipedia.org/wiki/Dangling_pointer
[aHR0cHM6Ly9jb29sc2hlbGwuY24vd3AtY29udGVudC91cGxvYWRzLzIwMjAvMDMvaW5keS5naWY]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9jb29sc2hlbGwuY24vd3AtY29udGVudC91cGxvYWRzLzIwMjAvMDMvaW5keS5naWY
[issue 58052]: https://github.com/rust-lang/rust/issues/58052
[issue 41078]: https://github.com/rust-lang/rust/issues/41078
[RAII]: https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization
[C]: https://coolshell.cn/articles/12165.html
[CPU]: https://coolshell.cn/articles/20793.html
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci84MDcyOWU3MjI4OTdjNDZiMzc1M2JhZTkzNjE0NzFiOA?x-oss-process=image/format,png
[2020_04_04_ 18_12]: https://coolshell.cn/articles/20845.html#comment-2085749
[Link 14]: https://coolshell.cn/articles/20845.html?replytocom=2085749#respond
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci9hZjJmYmI3MzcyZGQ1ODI2ZTQ0ZDg3ZTZjZWNjZWE0MA?x-oss-process=image/format,png
[Link 15]: http://coolshell.cn/
[2020_04_04_ 19_00]: https://coolshell.cn/articles/20845.html#comment-2085763
[Link 16]: https://coolshell.cn/articles/20845.html?replytocom=2085763#respond
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci9jNDExZmVhN2ZkNWE4NWQxZmU4ZjZlZWRlNzI5NmU3Nw?x-oss-process=image/format,png
[DennisThink]: https://www.dennisthink.com/
[2020_04_05_ 09_45]: https://coolshell.cn/articles/20845.html#comment-2086103
[Link 17]: https://coolshell.cn/articles/20845.html?replytocom=2086103#respond
[2020_04_07_ 09_26]: https://coolshell.cn/articles/20845.html#comment-2087122
[Link 18]: https://coolshell.cn/articles/20845.html?replytocom=2087122#respond
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci8yMWExZGY2MzM5Y2U4M2E5ZTZjN2NlMzIwMzMzMWY2Mg?x-oss-process=image/format,png
[fatgrammer]: http://fatgrammer.com/
[2020_04_04_ 18_16]: https://coolshell.cn/articles/20845.html#comment-2085751
[Link 19]: https://coolshell.cn/articles/20845.html?replytocom=2085751#respond
[2020_04_04_ 19_34]: https://coolshell.cn/articles/20845.html#comment-2085778
[Link 20]: https://coolshell.cn/articles/20845.html?replytocom=2085778#respond
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci8yNDQyODhhMjhiN2RmYTIzYTI4ZGI3NTU1NjBjNjYyZg?x-oss-process=image/format,png
[2020_05_19_ 23_11]: https://coolshell.cn/articles/20845.html#comment-2107270
[Link 21]: https://coolshell.cn/articles/20845.html?replytocom=2107270#respond
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci80YmQ4ZmNmYTc4YzJiNzFlZTdiNzUyNGRhY2Y5Mjg1OA?x-oss-process=image/format,png
[Xidorn Quan]: https://www.upsuper.org/
[2020_04_04_ 19_38]: https://coolshell.cn/articles/20845.html#comment-2085782
[Link 22]: https://coolshell.cn/articles/20845.html?replytocom=2085782#respond
[2020_04_04_ 20_39]: https://coolshell.cn/articles/20845.html#comment-2085807
[Link 23]: https://coolshell.cn/articles/20845.html?replytocom=2085807#respond
[2020_04_04_ 21_14]: https://coolshell.cn/articles/20845.html#comment-2085824
[Link 24]: https://coolshell.cn/articles/20845.html?replytocom=2085824#respond
[2020_04_04_ 19_41]: https://coolshell.cn/articles/20845.html#comment-2085785
[Link 25]: https://coolshell.cn/articles/20845.html?replytocom=2085785#respond
[2020_04_04_ 20_38]: https://coolshell.cn/articles/20845.html#comment-2085806
[Link 26]: https://coolshell.cn/articles/20845.html?replytocom=2085806#respond
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci80ODUwYjBmNGExOTBjM2JiMDgyYWU2YzI1ZmJjMjI4NA?x-oss-process=image/format,png
[2020_04_04_ 20_17]: https://coolshell.cn/articles/20845.html#comment-2085795
[Link 27]: https://coolshell.cn/articles/20845.html?replytocom=2085795#respond
[2020_04_04_ 20_35]: https://coolshell.cn/articles/20845.html#comment-2085805
[Link 28]: https://coolshell.cn/articles/20845.html?replytocom=2085805#respond
[2020_04_04_ 21_32]: https://coolshell.cn/articles/20845.html#comment-2085831
[Link 29]: https://coolshell.cn/articles/20845.html?replytocom=2085831#respond
[2020_04_04_ 22_28]: https://coolshell.cn/articles/20845.html#comment-2085849
[Link 30]: https://coolshell.cn/articles/20845.html?replytocom=2085849#respond
[2020_04_04_ 22_33]: https://coolshell.cn/articles/20845.html#comment-2085855
[2020_04_04_ 22_42]: https://coolshell.cn/articles/20845.html#comment-2085860
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci82MWRjM2M0NWM2OWRmMzY4ZjFhNDQ1MmIzYzQ4NDNiYg?x-oss-process=image/format,png
[2020_04_04_ 20_58]: https://coolshell.cn/articles/20845.html#comment-2085816
[Link 31]: https://coolshell.cn/articles/20845.html?replytocom=2085816#respond
[2020_04_04_ 22_17]: https://coolshell.cn/articles/20845.html#comment-2085846
[Link 32]: https://coolshell.cn/articles/20845.html?replytocom=2085846#respond
[format_png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci80NGYwYjc5ZTllZjQ0ZjMzNzZmMjRjYjhmYmM5Mzg4ZQ?x-oss-process=image/format,png
[2020_04_04_ 21_56]: https://coolshell.cn/articles/20845.html#comment-2085838
[Link 33]: https://coolshell.cn/articles/20845.html?replytocom=2085838#respond
[2020_04_04_ 22_32]: https://coolshell.cn/articles/20845.html#comment-2085854
[Link 34]: https://coolshell.cn/articles/20845.html?replytocom=2085854#respond
[format_png 9]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9zZWN1cmUuZ3JhdmF0YXIuY29tL2F2YXRhci9hNDA2MDY3Y2ExMGQ2NTMxNWMzNDIxYjQzYmUzNWY1Mg?x-oss-process=image/format,png
[2020_04_08_ 12_01]: https://coolshell.cn/articles/20845.html#comment-2087683
[Link 35]: https://coolshell.cn/articles/20845.html?replytocom=2087683#respond
[https_coolshell.cn_articles_20845.html_from_timeline]: https://coolshell.cn/articles/20845.html?from=timeline