如何看待 Dropbox 從 Go 轉向 Rust ?

01-03

The Epic Story of Dropbox』s Exodus From the Amazon Cloud Empire
關於 Rust 的討論：
Hi HN! A couple of us from the Magic Pocket software team are around to answer ...
The Epic Story of Dropboxa€?s Exodus From the Amazon Cloud Empire (feat. Rust) : rust

有GC, 用golang;

無GC, 用Rust;

TiDB(golang, 分散式DB)和TiKV(Rust, 存儲引擎)是很好的例子;

謝腰。

根據問題鏈接中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:

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.

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.

但我認為對這個特定的項目，Rust 能提供的相比沒有生態系統加持的 C++ 的優勢依然是很小的：安全的內存和並發管理，在現代 C++ 里，用對了智能指針和 RAII 這基本不是問題；更好的高層次抽象能力，更好的 generic. 這在底層模塊里並沒有什麼作用，就像開發者自己說的，他們專註點在底層的細緻控制和優化，不是抽象。他們還要應對 Rust 語言方面的不穩定（他們在 Reddit 的帖子里說了），這個對力求穩定，編譯環境升級一次回歸測試做死人的底層服務，是非常不利的，這點，就真是不知道他們怎麼想的了。

不過…… 他們有 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.

我不覺得一個公司針對他們某一個項目的特點選擇了一種語言有什麼特別值得看待的地方。

Rust是一個系統語言，一方面它提供強大的高層抽象和安全性，另一方面提供底層的完全控制與所謂的零開銷抽象。Rust的語言特性正好對上了Dropbox這個項目對內存的要求。

Golang是一個伺服器端語言，它講究快速快發以及高並發性。在Dropbox這個項目上，它的語言特性優勢並沒有能夠發揮。

Rust的應用領域與Go並不完全重合。Dropbox肯定有很多項目更適合用Golang而不是Rust。在恰當的項目上使用合適的語言比當某種語言的粉絲就無條件使用這種語言更有意義。

這個轉向過程說明，Rust語言已經進入了像Dropbox這種大公司的視野，並且通過了相應的技術選型評估，得到了認可（從Go和C++中脫穎而出），進入了應用階段，初步形成了生產力。這有助於推動Rust向更廣泛的應用階段邁進，畢竟世界上還有很多團隊缺乏獨立自主的技術評估能力，習慣於看別人成功案例的。這個轉向動作，對Go語言而言，是很小的損失（已經被不少答主輕描淡寫了），而對Rust而言，可能是好的開端。我持謹慎的樂觀態度吧。

相比Go，Rust沒有GC等運行時開銷，性能更好，對CPU和內存的使用更自由。相比C++，Rust性能不差，控制性也不差，還能保障內存安全。既在乎性能又在乎內存安全的項目，Rust是很好的選擇。Dropbox選中Rust還是有眼光和魄力的。

這類問題，真心沒法看待。互聯網公司喜歡折騰、嘗鮮，

有從RUBY轉JAVA的；

有從PYTHON轉JAVA的；

有從C++轉GO的；

有從GO轉RUST的；

有從JAVA轉PYTHON的；

有從JAVA轉C++的；

有從JAVA轉ROR的；

有從.NET轉GO的；

有從.NET轉JAVA的；

有從JAVA轉PHP的；

還有各種混合的......

無一例外，它們在轉的時候都要發一個牛逼的聲明，證明被轉的語言/平台多麼有問題，現在的業務發展多麼迅猛，要轉的語言/平台多麼符合自己要求，自己的技術決策多麼英明偉大。

Python他爹的怨恨吧

老子開開心心去Google搞Python，結果你弄出一個親兒子Go。

現在到了Dropbox了你們丫的還敢跟我面前寫Go？！

Hacker News 里有 Magic Pocket 的員工來說了

，主要原因是：他們為了處理大量數據，用了很多自定義的緩存友好的數據結構，在棧上維護大量數據以及做了一些內存管理方面的事。這些用c++/rust 會更方便。另外就是節省CPU資源和通過FFi方便地與去年 C Lib 以及 Kernel 交互。GC 倒不是主要原因。

jamwt1 day ago

Good questions, let me try to tackle them one by one.

&> The article makes a brief mention of Go causing issues with RAM usage. Was this due to large heap usage, or was it a problem of GC pressure/throughput/latency? If the former, what were some of the core problems that could not be further optimized in Go?

The reasons for using rust were many, but memory was one of them.

Primarily, for this particular project, the heap size is the issue. One of the games in this project is optimizing how little memory and compute you can use to manage 1GB (or 1PB) of data. We utilize lots of tricks like perfect hash tables, extensive bit-packing, etc. Lots of odd, custom, inline and cache-friendly data structures. We also keeps lots of things on the stack when we can to take pressure off the VM system. We do some lockfree object pooling stuff for big byte vectors, which are common allocations in a block storage system.

It"s much easier to do these particular kinds of optimizations using C++ or Rust.

In addition to basic memory reasons, saving a bit of CPU was a useful secondary goal, and that goal has been achieved. The project also has a fair amount of FFI work with various C libraries, and a kernel component. Rust makes it very easy and zero-cost to work closely with those libraries/environments.

For this project, pause times were not an issue. This isn"t a particularly latency-sensitive service. We do have some other services where latency does matter, though, and we"re considering Rust for those in the future.

&> Could you comment more generally on what advantages Rust offered and where your team would like to see improvement?

...

原文說了原因：

But Go』s 「memory footprint」—the amount of computer memory it demands while running Magic Pocket—was too high for the massive storage systems the company was trying to build. Dropbox needed a language that would take up less space in memory, because so much memory would be filled with all those files streaming onto the machine. So, in the middle of this two-and-half-year project, they switched to Rust on the Diskotech machines. And that』s what Dropbox is now pushing into its data centers.

Go 是有垃圾回收的，而 Rust 會立刻釋放不用的資源。這導致 Go 的內存佔用比較大，對於 Dropbox 這種大量存儲的系統而言，這個內存佔用量顯得過大了。

其實我覺得主要是 Dropbox 的工程師閑得沒事幹，工資的開銷肯定夠買足夠的內存了…

其實我一直沒明白在服務端有java為什麼還要用golang。而rust則定位取代c++會非常吸引人。

因為工作量不飽和，只能通過換語言來顯得自己有事干

我特別想問，為什麼總有人問Dropbox從什麼轉到什麼

go適合高並發分散式處理，存儲引擎需要c/c++這類強控制的語言。dropbox服務端中主要有三個服務，一個是notify server, 用於通知變化，一個是metadata server, 用於非數據流處理, 一個是data server, 用於分片數據處理, 這個服務的底層go不合適

Dropbox寫了那麼多廢話，還不如說一句不想讓公司的主要業務綁定在Google創造的語言上。可見的將來Go的機會更大，可是Google的陰影仍然存在，和Google有競爭關係的公司都不會等著Google把自己的開發工具完善的。