之前的 Rust 文章增加了一些段落。作为一个地道的程序语言专家，我对 Rust 的内存管理设计的看法是：不必要的复杂。这导致它比 C

期盼美好

之前的 Rust 文章增加了一些段落。作为一个地道的程序语言专家，我对 Rust 的内存管理设计的看法是：不必要的复杂。这导致它比 C++ 还复杂还难用。


Rust 的设计者看起来不是一个正规训练过的编程语言专家，不知道是什么背景。年纪太轻，经验和洞察力不足，没有独立的思维，只是跟风盲目崇拜“函数式语言”。从 Rust 最早的版本是用 OCaml 写的（并且为此自豪和显摆），我就能看出这一点。我绝对不会使用 OCaml 或者 Haskell 那样（基于 Hindley-Milner 类型系统）的语言来实现一个工业级的编程语言。

Rust 的设计者和编译器团队里，看起来缺乏资深的语言专家（比如 Tony Hoare 那样的）。其它成员也是一些不怎么合格的人，比如我之前的几个同学，能力很低，写扯淡论文勉强毕业，之后就自诩为“Rust 编译器专家”。

我不明白像 Rust 和 Go 语言这样全世界推广普及的语言，为什么总是没有经过资深专家的参与和顾问。每次出现这类语言，都是一些从未听说过名字的人，或者像 Rob Pike 那种半壶水响叮当，自以为是的“名人”，根本就不是编程语言专家。这似乎是故意设计的圈套。如果有资深人士参与顾问工作，很多不合理的设计看一眼就能发现，然而它们却进入了最后的实现。

为什么现在每出现一个新的语言，总是有那么一个人的名字，作为这个语言的“发明者”？像 Go，Rust，Swift 这样的语言，显然大部分特性都是抄来的，只有很少数算是“发明”，所以其实不应该用“发明”这个词。

这些语言显然应该是一个团队(委员会)来设计，经过大量的讨论研究，甚至投票，而不能是一个人的工作。像 Go，Rust，Swift 这样的语言，从一开头就是有公司赞助开发的，甚至以公司的名字命名（比如 Go），所以显然不是一个人做的。然而你会发现“Rust 的发明者”是一个人，“Go 语言的发明者”也是一个人，“Swift 语言的发明者”也是一个人。都是很具体的一个人的名字。一个人显然不可能把所有方面都做对的，所以把“发明权”归到这么一个人头上，不是很奇怪吗？感觉这是在进行某种“造神运动”。

当然我不是说有学术界研究者的参与就会好一些。很有意思的是，你会发现每次出现这类红极一时的语言，都是已经做出了设计和实现，学术界才开始出现论文，用非常复杂看不懂的符号公式，声称证明了“Rust 的内存管理的正确性”之类的。我很惊讶，这种学术证明总是在语言已经实现完毕，很多人都开始用之后才出现，而不是在最开头设计时就进行分析，经过大家推敲没问题之后才实现和推广。这种做法是非常不科学，不可靠的。

Rust 具体的设计错误和不合理方面的细节，我会在以后的正式学术论文里详述（等我先把网球技术研究透）。

=== 文章修改部分 ===

使用 Rust 的时候为此付出的脑力代价如此之大，以至于在计算机科学基础班第五期的时候，同学们学过了 Rust（并用它写了解释器）之后，再学 C++（并用 C++ 写解释器），都发现“C++ 原来那么容易！” C++ 并不容易，但经过折腾 Rust 内存管理，伤透了脑筋之后，相对而言 C++ 居然显得容易了。

Rust 写出来的解释器，比起 JavaScript，Scheme，Python，Java 写的，都要复杂很多，很难读懂，过一阵就忘了某个地方为什么要那样写。原因就是 Rust 的内存管理其实是手动的，所以很多代码的写法必须针对内存管理进行，无法清晰直接地表示实际需要的逻辑。C++写的解释器也比较复杂，但比起 Rust 还是清晰了很多。

Rust 为了这些静态检查做的设计，其实是不必要的繁琐，有一些无原则的设计和多余的限制。因为这样代码太繁琐，又加入一些自作聪明的 inference（推导），ellision 什么的来减轻负担，结果弄得更加莫名其妙，经常自作主张，悄悄地改变原来的代码含义，导致编译不过也搞不明白是怎么回事。实现同样的静态检查，其实可以有更清晰简单的设计，但 Rust 的设计者显然缺少这种简单的思维。