如何看待 Dropbox 从 Go 转向 Rust ?
关注者
480被浏览
35,50913 个回答
知乎用户
golang爱好者
@kyhpudding
谢腰。
根据问题链接中Dropbox开发者的说法，他们主要的后端基础服务都是Go写的，Rust仅用在了一个单机上的底层存储模块。Dropbox 目前有 40 多万行 Go 代码 (去年11月数据：https://www.youtube.com/watch?v=JOx9enktnUM) 而 Rust 是 6 万多行。
这个存储模块有非常苛刻的内存要求 (Wired文定性不定量都是耍流氓，开发者自己的说法是：One of the games in this project is optimizing how little memory and compute you can use to manage 1GB (or 1PB) of data), 到这个程度的需求，传统上就是 C/C++ 的战场了，开发者提到它们要定制数据结构，做 lock-free 的 pool, 精确控制内存分配保证东西尽量在栈上，那么标准 C++ STL 容器也不能满足要求，需要更底层的作业了。
至于为什么要用 Rust 而不是 C++, 他们的解释是：
不过…… 他们有 Haskell guys 嘛，Rust 肯定比 C++ 更对口味，再加上，我们都有尝鲜的心态，有新玩具，谁会不想玩？
说回 Go, 他们在考虑替代 Python 的后端语言时，选项有 C++, Java 和 Go, C++ 第一个出局，原因就是上面说的，他们没有 C++ 生态系统的积累。要把 C++ 大规模应用到后端架构，你必须维护一整套基础库和服务框架（拿开源的凑通常行不通，不是质量不行，是各个项目都有各自的一套 源于不同历史背景的 C++ 方言，放一起经常打架），要定义代码规范和推行相应的流程，要提供一大堆开发支持工具…… 而回头看 Go, 在 Dropbox 关于 Go 的分享中 (https://www.youtube.com/watch?v=JOx9enktnUM) 他们对 Go 最满意的地方就是质量极高的基础库和运行时环境（他们线上居然还跑着 1.3...... 不过说是从来没有 crash 过），还有就是人们常常提的部署方便和工具支持，这些在 C++ 中要多年积累的东西，Go 全部自带了。
在问题的链接中，他们提到了，以后有可能会将性能攸关（内存，或是高度延迟敏感）的模块转向 Rust. 对于前者，就像前面说的，Rust 并没有提供比 C/C++ 更大的优势；对于后者，Go 1.6 的 GC 延迟的峰值已经下降到 3-5ms 的级别，在这个级别下，影响延迟的瓶颈已经不大可能是 GC 了，他们可能得重新评估；Go 1.7 会有 SSA 运算性能又会有显著提高。而更重要的是，如果 Rust 要扩大应用范围，它一样要解决运用 C++ 的问题：Rust 的标准库质量和丰富程度还是比 Go 差一截，更别说稳定性，工具方面还差很多，再加上没法跟 Go 比的编译速度，可能比 C++ 好点的就是没有历史包袱，这些都会成为大规模运用的阻碍。综上，我预计是未来 Dropbox 会有很少数底层模块用 C/C++/Rust 编写，Go 继续挑大梁，并且有更多的 Python 服务改写成 Go.
根据问题链接中Dropbox开发者的说法，他们主要的后端基础服务都是Go写的，Rust仅用在了一个单机上的底层存储模块。Dropbox 目前有 40 多万行 Go 代码 (去年11月数据：https://www.youtube.com/watch?v=JOx9enktnUM) 而 Rust 是 6 万多行。
这个存储模块有非常苛刻的内存要求 (Wired文定性不定量都是耍流氓，开发者自己的说法是：One of the games in this project is optimizing how little memory and compute you can use to manage 1GB (or 1PB) of data), 到这个程度的需求，传统上就是 C/C++ 的战场了，开发者提到它们要定制数据结构，做 lock-free 的 pool, 精确控制内存分配保证东西尽量在栈上，那么标准 C++ STL 容器也不能满足要求，需要更底层的作业了。
至于为什么要用 Rust 而不是 C++, 他们的解释是：
Well, we basically needed C++, but:但我认为对这个特定的项目，Rust 能提供的相比没有生态系统加持的 C++ 的优势依然是很小的：安全的内存和并发管理，在现代 C++ 里，用对了智能指针和 RAII 这基本不是问题 ；更好的高层次抽象能力，更好的 generic. 这在底层模块里并没有什么作用，就像开发者自己说的，他们专注点在底层的细致控制和优化，不是抽象。他们还要应对 Rust 语言方面的不稳定（他们在 Reddit 的帖子里说了），这个对力求稳定，编译环境升级一次回归测试做死人的底层服务，是非常不利的，这点，就真是不知道他们怎么想的了。So realistically, if we had been at a place with an awesome preexisting set of C++ libraries, practices, etc, we probably never would have used Rust.
- Dropbox doesn't have a strong C++ ecosystem on the backend, and it takes a lot of work to build one.
- Given (1), we had basically a blank slate, and our team is C++ and Haskell type folks, we decided to use Rust so we could get C++ with better type safety and fewer sharp corners.
不过…… 他们有 Haskell guys 嘛，Rust 肯定比 C++ 更对口味，再加上，我们都有尝鲜的心态，有新玩具，谁会不想玩？
说回 Go, 他们在考虑替代 Python 的后端语言时，选项有 C++, Java 和 Go, C++ 第一个出局，原因就是上面说的，他们没有 C++ 生态系统的积累。要把 C++ 大规模应用到后端架构，你必须维护一整套基础库和服务框架（拿开源的凑通常行不通，不是质量不行，是各个项目都有各自的一套 源于不同历史背景的 C++ 方言，放一起经常打架），要定义代码规范和推行相应的流程，要提供一大堆开发支持工具…… 而回头看 Go, 在 Dropbox 关于 Go 的分享中 (https://www.youtube.com/watch?v=JOx9enktnUM) 他们对 Go 最满意的地方就是质量极高的基础库和运行时环境（他们线上居然还跑着 1.3...... 不过说是从来没有 crash 过），还有就是人们常常提的部署方便和工具支持，这些在 C++ 中要多年积累的东西，Go 全部自带了。
在问题的链接中，他们提到了，以后有可能会将性能攸关（内存，或是高度延迟敏感）的模块转向 Rust. 对于前者，就像前面说的，Rust 并没有提供比 C/C++ 更大的优势；对于后者，Go 1.6 的 GC 延迟的峰值已经下降到 3-5ms 的级别，在这个级别下，影响延迟的瓶颈已经不大可能是 GC 了，他们可能得重新评估；Go 1.7 会有 SSA 运算性能又会有显著提高。而更重要的是，如果 Rust 要扩大应用范围，它一样要解决运用 C++ 的问题：Rust 的标准库质量和丰富程度还是比 Go 差一截，更别说稳定性，工具方面还差很多，再加上没法跟 Go 比的编译速度，可能比 C++ 好点的就是没有历史包袱，这些都会成为大规模运用的阻碍。综上，我预计是未来 Dropbox 会有很少数底层模块用 C/C++/Rust 编写，Go 继续挑大梁，并且有更多的 Python 服务改写成 Go.