Rust语言恰巧是一门解决了Go语言所有问题的语言

从整体的角度来看go，很难理解他是怎么取得这么大的成功的。
 
从理论的角度上来说go是一门非常糟糕的语言，就算是和C++或者Ada之类旧语言相比也是这样。

它缺乏大量的编译时的检查和编译时的逻辑，它缺乏销毁逻辑导致许多样板文件和运行时错误。它的界面不是很有表现力。它具有一等公民数据结构(slices和maps)，不能使用语言本身作为库进行复制。在许多不需要易变性的情况下，它强制用户进行易变性。它附带了一个伪依赖管理器，它缺乏独立项目的独立版本控制。与大多数其他流行的系统编程语言(即C、C++、Ada、Fortran和Rust)相比，它的速度非常慢。

这就是我现在能想到的，很容易就能给你们展示的东西。一旦你深入研究go，你会发现它会做出一些固有的错误设计选择，它是为1980年而不是2020年设计的语言。
尽管如此，就像任何曾经使用过go的人都能告诉你的那样，这是一种非常好的语言。如果我被困在一个只有三种编程语言的岛上，我想go会成为其中之一。
尽管存在所有的缺陷，但它允许您编写性能良好的相对无错误的代码。向Go程序添加依赖项通常比向C++程序添加依赖项要顺利得多。为什么 Go 是棒的
这让我处于一个非常奇怪的位置。 一方面，我可以谈谈 Go 有多可怕。 另一方面， Go 显然是一种非常好的语言。
为了弄清楚为什么是这样的，我们依然需要回到程序员解决问题的角度，把语言作为工具来看。
很多现代世界的问题看起来都是围绕着有效网络通信，围绕安全地利用所有硬件线程以及更容易的开发和部署展开的。
最后，渐渐有了一个稳定的趋势，良好的开源库渗透到我们的生活中，其中大多数是简洁和简单，适合单一目的。大多数 Node 或 Python 项目都有数百个这样的依赖项，而大多数 C 和 C ++ 代码库都有十几个。 C 和 C ++ 缺乏任何标准化的包管理，因此库往往是无所不包的整体（参见 QT 和 Boost ），而它们添加新的依赖项非常耗时。
开源库是现代开发人员生涯中的重要组成部分，但所有流行的系统编程语言都缺乏包管理。

从这个角度来看，Go有一些中心特征，这些特征非常让人惊叹，以至于它们把所有不好的一面都掩盖了。

1. Go 的实用程序允许您轻松下载和使用包。
2. 静态编译使得在不同环境之间移植代码，并且可以很容易地建立开发环境。
3. 本地异步 I/O 机制允许您可以轻松编写高性能的网络代码。
4. 内置通道允许在 [g|c]oroutines 之间轻松实现和相对安全的数据传输。
5. 标准库和包生态系统包含了开发人员能够需要的大多数库。
6. 对于几乎所有的使用案例来说，它“足够快”。似乎在如 Python 和 Node 这些易于使用的单线程语言，甚至是像 C++ 和 C 这样的古老而又快速的庞然大物之间找到了一个最佳位置。或者，说白了， Go 是一种专为开源库，大规模并行和网络计算而设计的语言。其他流行语言则缺少这三个类别中的一个。

 Go的所有剩余问题源于三种设计选择：
 

1. 垃圾收集，而不是为其所有资源定义编译时间的生命周期。 这会损害性能，删除有用的概念（如移动语义和析构函数），并削弱编译时错误检查功能。
2. 缺乏不可变性,除了少数（本机）类型之外。
3. 缺乏泛型

若解决这些问题，Go无疑会成为未来的语言。 但是，由于各种问题，有些与先前的设计决策有关，有些又与设计师的意见有关，其中大部分都未解决。

例如，泛型可能会在2.0上实现，但是当前的实现与其他特征（比如接口）重叠，同时使用起来又烦恼并且缺少特征（比如，不能用作返回类型）。

或许我们可以找到一种“检查”所有正确语法的语言，又不用忍受那些糟糕的设计决策。
 
再来看看 Rust 语言

Rust 恰巧是一门解决了Go 所有问题的语言。

基于它的隐式移动语义和借用检查功能，使它在资源管理领域最终成为了最安全，最快速并且也最容易使用(这里是相对来说。比如目前借用检查比较难用，用过的都知道)的语言。它在编译期间就可以捕获大多数错误。

模板和特性(traits)组合给了它接近于C++的编译时编程能力，甚至某些方面更胜一筹。

最后，Cargo 也是最好的包管理系统之一，它可以让你更容易地使用各种实用的公共库，并且有内建版本号和项目隔离特性
。
换句话说，Rust的极大成功就是基于它更好地解决了Go存在的问题。

但是，Go 做得无比正确的事又有哪些呢？

1. go get 和 go mod与Cargo非常匹配
2. cargo build 默认使用静态编译路由，这一点和 go build 基本一致
3. 重点来了，Rust 目前还没有原生异步 i/o 机制。但是据说这个机制马上就有了。这个机制与 goroutine 所提供的功能差别很大，而是更像我们所熟知的 Node 和 Python中所使用的语法。
4. Rust 不仅提供了线程之间的原生管道(channel)支持，它提供了一套健壮的编译时线程安全检查机制。这意味着无论你使用何种数据共享机制都不存在并发错误的风险。
5. 尽管 Rust 是一门年轻得多的语言， Rust 的标准库和 go 的差不多一样丰富，当然除了（再次除了）一些没有的异步网络功能之外。当前 Rust 的包(package)生态系统和 Go 的一些方面很像。
6. 最后是效率方面。在大部分的场景下， Rust 只比 C 和 C++ 稍慢那么一丢丢。但是对于它的设计方向来讲这只是一个“临时性的”折扣。Go 将永远受累于缺乏编译时逻辑和基于 GC 的设计。因此，Go 和 Rust 之间现有的巨大效率差只会越拉越大。

 Go 的影响

一旦 async/await 特性被合并到Rust的稳定版中，我认为Rust就完全超越Go了，确切地说，在任何方面！(译者注：借用检查仍旧是导致Rust难用的一个原因，最好是有更多的隐式借用或更好的方案)

我认为直到将Rust真正应用于产品中，人们才会认识到Rust在测试，调试和程序崩溃等方面为你节省了多少时间。
Rust和Rust相关的概念进入编程世界越多，人们就会越熟悉它的语法和概念，因此进入的门槛也就越低。

我认为Rust已经走过了它生命中最危险的时期，它已经逐渐地被接受并作为主要开发语言。更进一步讲，当与其它语言在各方面比较时，它几乎是完胜其它语言(编者：各种语言特性方面确实是，但易用性上还差些)。简单讲，在大多数情况下，Rust应该是更好的选择。

但是人的惰性是不可忽视的一个问题，Rust很难被大家广泛采用的阻力，来自于如何说服开发者转换到它上面。
这里，我认为Go突然爆发的原因，也可以同样应用于Rust身上。Rust现在越来越接近全面爆发了(译者注：随着生态成熟，也快到引爆点了)。

一些希望有“现代编程范式”的C&C++开发者，也会喜欢上Rust。

同时，对于一些希望从脚本语言转到系统编程语言上的那些人来说，这也是最好的选择，你不但拥有了安全和性能，你还仍旧可以使用包管理工具和熟悉的语法。

无论如何，这是我的预测，一旦 async&await 加入到语言中，我们将有大量的网络应用程序开发人员涌入Rust。
网络依赖的高性能开源软件，如内存缓存，数据库和反向代理，将开始逐步走向成熟。 很多这样的项目已经在 go 的生态系统中出现了。

一旦这些开发人员在网络和并发性方面嗅到了 Go 的简易性，再加上 C++ 的速度，抽象能力和资源管理，以及顶级的编译时安全性……

随后，Web 开发人员和企业团队将跟随宣传。

一切就犹如打开了防洪闸门，不可阻挡。