文| 局長
出品 | OSC開源社區(ID:oschina2013)
事件起因是 AWS 前幾天發布的一篇博客:《Sustainability with Rust》。博客原文:https://aws.amazon.com/cn/blogs/opensource/sustainability-with-rust/在這篇文章里,AWS 舉例的時候將 Rust 和 Go 進行了對比。文章提到了早期 Discord 的一項關鍵 Go 服務存在問題,原本這是一個非常簡單的服務,但它的尾部延遲 (Tail Latency) 非常慢。AWS 認為原因在於 Go 是一種垃圾回收 (GC) 語言,因此當對象被創建和釋放時,垃圾回收器每隔一段時間就需要停止程序的執行並運行一次垃圾回收。當垃圾回收器運行時,會導致進程無法響應請求。為了解決此問題,Discord 決定嘗試用 Rust 重寫這個服務。測試結果顯示,使用 Rust 重寫後的速度提升超 10 倍,最慢的尾部延遲時間也降低至為原來的約 1%。下圖是運行過程中 CPU 和響應時間的峰值,左邊為 Go 實現的版本,右邊為 Rust 實現的版本。Go 開發團隊 leader Russ Cox (rsc)認為 AWS 在這裡的比較對 Go 存在嚴重的誤導。他認為,AWS 的文章將兩者進行對比時,將 Go 版本的數據與在使用新的數據結構和更多內存後的 Rust 版本數據放在了一起,還特意圈出「ms」和「µs」時間刻度。rsc 表示,這要麼是 AWS 對 Discord 的原貼存在誤解,要麼就是公然地說謊。因為在 Discord 的原文中,他們展示 Go 服務器和同級別 Rust 服務器的對比時,圖表數據來源既有原始的版本,也包括重寫數據結構和提供額外內存後的情況。AWS 的文章卻對此進行了故意的歪曲。而且 AWS 引用的 Discord 數據當時使用的 Go 版本還是 Go 1.10,但現在 1.18 版本很快就推出了。在這 8 個重要版本的迭代過程中,Go 團隊改進了許多功能,對因 GC 而引起的中斷也提供了極大的改善(這正是當時 Discord 面臨的問題)。除了這個,rsc 認為 AWS 引用的一份「非常有趣」的研究的真實性也十分可疑。rsc 表示,AWS 的文章對 Rust 的描述公正客觀,但對 Go 卻存在誤導性的描述。他認為 Rust 和 Go 不是零和的博弈關係。Rust 十分優秀,所以他更願意關注 Go 和 Rust 相互補充並進行良好合作的方式。比如這個案例:https://thenewstack.io/rust-vs-go-why-theyre-better-together/馬斯克:我是Rust粉絲,但為了性能會選擇C16K Star,「程序員做飯指南」衝上熱榜被侮辱、被架空,Swift之父退出核心團隊
覺得不錯,請點個在看呀