这是我目前对 Rust 想法的一个小总结。我不知道我是否会在五年后回顾，看看我的观点是否发生了变化
好的看法
Rust 的宏非常好。它们的作用类似于 Lisp 的宏，与 Haskell 的不同。
Rust 具有类型类（“traits”）和和类型（“enums”）和模式匹配这一事实非常有吸引力。使实例在包范围孤立而不是模块范围是一个非常好的决定。
我也喜欢它对记录的处理。
它的标准库在一些方面做得很好，比如将字符串处理为 UTF-8。
区分可变性有其优点，很容易看出一个函数是“道德上”纯的——如果不是实际上纯的——这有利于阅读。
糖好吗？
Rust 使用了神奇的糖结构，编译器会自动为你插入解引用、复制、克隆和删除，它具有最初吸引人的“底层很简单”的品质，但在实践中这会导致错误的编译错误：编译错误是编译器一种它为你生成的东西的抱怨，而不是直接抱怨写的东西。
这可以与 Haskell 使用提供语法糖的 monad 进行比较。你引入的魔法越多，新手就越难学习和谈论。
对高效内存表示的迷恋
人们试图理解为什么他们完全合理的代码不适合 Rust 严格的内存限制？
不是技术不好用，而是你用错了。
在实践中，人们只是希望能够编写一个树状类型，而不必与编译器下棋。我预测垃圾收集器最终会在 Rust 中流行起来。
这既是 Rust 的主要目标——像 C 一样，但安全——也是它的主要缺点。人们将时间浪费在永远不会产生效果的琐事上。
unsafe
unsafe 的使用有点令人不安，因为每个库都有它。但这与使用 FFI 没有太大区别。我不认为这是一个很大的缺点。
重写谬误
重写谬误
我看到很多“我们用 Rust 重写 X 并且它变得更快”的帖子。我认为，如果您在考虑性能的情况下从头开始重写任何内容，您将看到显着的性能改进。我怀疑 Rust 本身的需要程度，与具有某些性能洁癖的开发人员相比，哪个更主要？
“友好”社区
所有新的语言社区都很好。当事情无关紧要时，人们没有理由生气。
一旦人们对某事持有利害关系，那就是事情升温和发脾气的时候。您可以通过在其中编写大量代码或在其上建立业务来获得编程语言的股份。当您对一门语言的工作方式感兴趣时，您对可能使您做的工作超出需要或限制您的目标的变化非常敏感。
我已经看到了 Haskell 的情况。2007 年左右，当我开始使用 Haskell 时，社区对任何事物都很友好，福音派的，开放的。人们为此称赞它。每个人都感到很幸运能够使用这种令人兴奋的语言。今天，它更像任何其他社区。发生了什么？人们开始真正使用 Haskell，仅此而已。
Rust 正在经历同样的事情，而且速度要快得多。这是避免 Rust 的理由吗？不会。但是“友好”的社区也不是加入即将到来的语言的理由。
异步问题很大
异步引入了长时间的、激烈的讨论。
Rust 的问题是它的用户想要一个运行时，但想要一个没有运行时的选项。结果一团糟。
总的来说，我认为 Go、Erlang 和 Haskell 在这里做出了更好的选择。垃圾收集器和绿色线程使程序员的工作效率更高。
作为通用语言
我觉得 Rust 被定义为一种“系统”语言，但它被用来编写 Web 应用程序和命令行工具以及各种东西。
这有点令人失望，但也是可以预见的：你的语言越成功，就会有越多的人将你的语言用于它不适合的事情。