Rust 和 C++ 有哪些優劣？

12-31

關於單線程下的內存安全性：

C++ 和 Rust 當然都能寫出安全的單線程代碼，區別在於怎樣達到這個目的。Rust 的做法是 borrow checker，C++ 的做法是通過慣用法。

這就有個問題。我們說 C++ 可能寫出不安全的代碼並不是說新手會因為不懂慣用法寫出不安全的代碼，而更多的是說老手也可能會因為疲勞或者怠工寫出不安全的代碼。Niko 去年有個幻燈片用 C++ 的 std::map 舉例，兩處代碼分別引用了 map 上的不同部分，最後導致訪問錯誤。

Rust 怎麼防止老手寫出不安全的代碼？borrow checker。這個是 Rust 的核心，其他內容都要為這一點服務。

那你可能會說，對新手那部分，新人完全可以寫壞了攪黃項目啊？很高興你這麼說，這裡也涉及到 Rust 的一個優點就是它的模塊化。Rust 有良好的模塊系統。你設計好模塊之間的介面，那新手也只能訪問公共介面，想訪問非公開的內容，沒門。把庫之間的可見性從鏈接階段移到語言中去，這也是顯而易見的優點。

補充一下多線程下的內存安全：

很高興 C++ 標準庫也有了線程、future、promise。

C++ 還是那個老問題：慣用法。析構函數、拷貝構造函數。寫對了沒有。單線程下是對的，也許多線程就錯了。要知道你可能從前寫好了基礎庫，沒有完整測試它在高並發下的表現，繼續用可能就出錯了（數據錯誤、內存訪問錯誤）。Rust 呢？Rust 有一套基礎設施（borrow checker），從語義上檢查了跨線程共享。

可能你會說，你丫這不是扯淡么，說了半天不就是說 C++ 可能寫錯，要比當然比對的代碼。其實這就是差異所在：

對 Rust 來說，編譯器保證指出你的錯誤，
對 C++ 來說，編譯器沒有這種保證，它也無法保證。

當然，以上都是在說 Rust 中沒有 unsafe 塊的情況。

所以總結來說：

Rust 和 C++ 都可以選擇安全或不安全，
對 Rust 來說，安全和不安全的邊界（unsafe 塊）是清晰的，想保證安全只需退到安全線以後，
對 C++ 來說，如果你想選擇安全，你無法保證已經安全了。

多線程下除了內存安全，當然還有競爭、死鎖這樣的問題。這方面我就不胡說了。

其他的安全，比如許可權控制、隱私、保密、身份鑒別其實也是安全問題，不過這些 Rust 和 C++ 相比沒有什麼優勢，也沒什麼劣勢（主要都是鏈接到 C 函數的問題，這個 Rust 並沒有比 C++ 差）。

rust：編譯時想撞牆。

c++：調試時想跳樓。

記得http://Rust.cc社區的Mike Tang提到的很重要的一點。

「Rust為了安全幾乎可以放棄一切。」

當然這裡的安全指的是safety，而不是security。

為了保證這一點Rust引入了很多東西，比如前面很多人都提到過的borrow checker和lifetime以及強約束的generic等等。

當然，踩過C++坑的都能夠理解為什麼會這麼設計，C++也是在沖著這個方向發展。

但是反過來你要跟一群熟悉了使用引用（指針）和GC的人說明白什麼是borrow，什麼是move，什麼是lifetime，以及為什麼要如此設計對象模型等，還是很困難的。

畢竟不像Go或者Swift，估計培訓機構一時半會兒也理解不了這些東西。（想想同樣是14年的新生語言的Hack吧。

所以，如果真的出現了支持Concept、Module和Reflection的C++1z、2z或者3z，我就不那麼熱愛Rust了。

Rust-Articles-Translation/Criticizing the Rust Language, and Why C_C++ Will Never Die.md at master · ScottHuangZL/Rust-Articles-Translation · GitHub

我翻譯了一篇文章，大家可以參考一下。（20150830：再次修訂了一下，應該比上次通順了一些）

Btw，我正在自學Rust中。

20150825 : 新翻譯了一篇關於Rust所有權指針的文章 Rust-Articles-Translation/r4cpp

20150826 : 借貸指針 https://github.com/ScottHuangZL/Rust-Articles-Translation/blob/master/r4cpp%20-%20Borrowed%20pointers.md

20150830：原始指針 https://github.com/ScottHuangZL/Rust-Articles-Translation/blob/master/r4cpp%20-%20Rc%20and%20raw%20pointers.md

網上有個o"reilly的公開文檔：《why rust？》，就是拿rust同cpp和java對比的。

rust的編譯條件更加嚴格，非常明確，你必須在最開始的時候想明白存儲的狀態。內存申請和釋放都是非常明確的。

c++更靈活，不過野指針飄飛了之類的不容易發現，而且內存不安全。

我把rust官網的例子走了一遍，做了個教程，希望對您有幫助~[oeasy]教你玩轉rust編程 - 網易雲課堂

其實，Rust是沒法取代C++的，沒有任何一個語言能取代C++。C++太大了，以很多毫不相干的方式應用在很多毫不相干的領域裡面。Rust只會取代C++的應用場景里的一部分，就像很多語言做過的一樣，但時代已經不同了，不可能再發明一個C++這樣高大全的語言了。因此，也沒有辦法比較Rust和C++的優劣。

C++大概有這麼幾個主要的應用場景：

高性能伺服器：高性能，高抽象

GUI：中等性能，極高抽象

編譯器：高性能，極高抽象

密集計算：極高性能，中等抽象

操作系統：高性能，中等抽象

大型遊戲：高性能，高抽象

有沒有極高性能，極高抽象的項目呢？其實就是STL，也就是C++本身。那麼，Rust，從現在的樣子看，它的特性是高性能、高抽象，這一塊確實是至今大家仍然被迫用著C++，沒有別的語言可轉的。那麼，如果一切順利的話，伺服器和大型遊戲將會有不少新項目轉向Rust。對於Rust來說，世界年輕，大有可為。

然後就是Rust缺的，首先是極高性能的部分，對於C/C++來說就是指針運算。Rust本身語法比較封裝，跟C++和Fortran比還是不夠底層，再加上C++編譯器幾十年來的優化，只能說Rust不是干這個的。然後是極高抽象的部分，Rust明顯是不能跟C++ class+模板的豪華陣容相比。當然，很多時候程序的抽象在高度分層的抽象層中體現，跟語言本身關係不大。但是像GUI庫和編譯器這種數量上很多的抽象問題，缺乏原生抽象特性就會顯得無力。應該說，很高興C++還在繼續進化，讓它能在不同的領域都能面對競爭對手的挑戰，不至於讓昔日的巨人只剩下情懷和舊代碼。

RUST最大的優點是能夠有java的開發效率和代碼安全，性能和C/C++一樣。其他的都是衍生品。

作為一個寫了十多年的C++用戶、重度C++ template語法使用者，我不得不嚴肅地考慮切換到rust這種可能性。由於有大量的歷史代碼，以及計算集群中rust環境的構建略有些麻煩（花了一個晚上還是搞定了），這種切換可能持續幾年時間，也許到時候C++會變得好用起來。

目前為止rust給我的一個感覺就是，寫起來 不傷神 C++裡面傷神的地方包括：

容器越界訪問
動態內存分派要麼容易泄漏，要麼用shared_ptr打字累
我喜歡的template特性不能編譯成二進位形式的庫，必須提供頭文件，所以我寫的庫有很多是header-only的
管理依賴累，如果自己不是root，安裝到自己目錄略有些麻煩
對初學者不友好，極大妨礙了我推銷

順便，作為python用戶，我也認為rust有如下的優勢：

效率高
編譯期檢查，python的運行到才報錯的特性極其煩人
類型提示好用（配合idea）

rust的劣勢當然也是有的：

用的人太少，導致庫不全，而且可能動不動不維護了
缺一個官方的scoped thread pool庫

20171211補充

作為一個Haskell學了五遍還沒入門的人再和Haskell比一下：

1. 不強求類型名首字母大寫

2. enum成員和成員訪問默認非全局

一直在模仿，從未被超越

讓我想起美電影的主角，渾身缺點但就有那麼一些特質能拯救世界。跟他一起搶主角的完美男二號，最終還是被女主拋棄…rust的取代如果有，也會是一個很長的過程。

c++背了太多的歷史包袱。rust不打算被任何包袱

Rust最近才開始關注，以前也嘗試過d語言，d語言語法接近c,性能和c還有一定距離，標準庫有點爛，很多性能還不如python，因為python的庫是c寫的。不知rust是否是我要找的語言，但是未來肯定會出現像c一樣高性能，像python高開發效率的語言，讓開發更重要的體現在設計和思想上，而不是糾纏在語言的蜜罐里

在網上看了相當多的對比和評價.也試過寫些rust的demo.建議對c++熟悉或者現有項目使用C++作為主要語言的繼續使用暫時沒必須用rust,裡面的一些東東還是比較繞.另外希望rust能更快的發展起來.