Rust 優劣勢： v.s. C++ / v.s. Go（持續更新）

<div class="htmledit_views" id="content_views">  html

Rust 發展速度比 C++ 強不少。若是去翻 open-std 的故紙堆，會發現 C++ 這邊有不少人（包括標準委員會的人）提了有用的提案，但後來大多不了了之或經歷了很是長的時間才進入標準。linux

>> C++ 設計哲學&思想體系程序員

另外就是之前就有的：面試

Rust 有很漂亮的宏和植入類型系統的生命期體系。目前看來 C++ 沒什麼可能加進去。（雖然有的編譯器已經能將生命期診斷實現爲警告，但這仍與語言標準自己關係不大）chrome

Rust 有更加簡潔而規範的對象模型。 C++ 能夠寫出很 weird 的類型，譬如移動或 swap 拋異常的類型， Rust 就沒這事。設計模式

……安全

我以爲你應該問就語言自己而言 Rust 比 C++ 弱在哪裏。 Rust 做爲站在 C++ 肩膀上發展的語言，更強是很天然的，弱的地方纔須要找緣由。（緣由多是在規範性上的顧慮、設計偏好等）架構

做者：暮無井見鈴 連接：https://www.zhihu.com/question/328263899/answer/715380135 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。函數

學習

<hr>rust不須要人類看不懂代碼也看不懂編譯錯誤的那種黑魔法，就能實現和黑魔法同樣的效果。

rust編譯經過了bug比cpp少上百倍，並且由於黑魔法引起的靈異bug起碼少10倍。

<a href="https://link.zhihu.com/?target=https%3A//msgpack.org/" rel="nofollow" data-token="e1d908eb1aca74c03b68420384a39155">https://msgpack.org/msgpack.org</a>

對比下首頁裏C/C++的範例代碼，和Rust的範例代碼，就知道什麼叫黑魔法和高科技的區別了，一個直接調用只能用tuple並且還又長又臭，一個能夠隨便拿個struct往裏面扔。

做者：諸葛不亮 連接：https://www.zhihu.com/question/328263899/answer/715307958 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

<hr>

做者：孫嘉龍 連接：https://www.zhihu.com/question/328263899/answer/727826881 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

關注了好久，但上手開始轉寫一個現有的邏輯大概一週左右。用過不少語言，C++和Scala這種比較複雜的語言都過有過至少3年以上使用經驗。說下個人使用感覺，能夠供準備正式入坑的人蔘考（不打算寫實際項目的不算）

大概來潑一點冷水。

【1】上手rust之因此說曲線陡峭主要是由於，即便你看過了文檔，也仍然會遇到不少問題。只不過C++是你在調試的時候遇到，rust是你在編譯的時候遇到。rust的編譯錯誤提示還算友好，但還不夠友好。更多時候是設計上就不知足要求，我看了提示研究半天知道了爲何這麼寫不對，但不知道怎麼寫才能實現我要的功能。

因爲生命週期約束的問題，不少其餘語言的典型範式在rust上都不通用，你用過再多的語言可能也很難顯著縮短學習時間。（沒用過Haskell，有熟練使用Haskell來評論下？）

【2】rust的API設計首先考慮是知足rust基本原則，而後纔是使用方便，並且不少地方使用方便性不足，舉兩個例子，你們就知道這幫人設計的標準庫API易用性是個什麼尿性：

<ul><li>BTreeMap<f64, T>是不可用的，由於f64不是全序的（由於有NaN），語言原生類型裏也沒有其餘浮點類型能夠看成這裏的key。</li> <li>map[key]=value這種賦值方式是沒有的</li> <li>———— ？？</li> </ul>因此rust的標準庫API發展出一套本身特有的風格，跟全部主流語言都不一致。

【3】本質上來講，rust大概是給操做系統、嵌入式、業務邏輯很是複雜但又極致追求安全性的場景準備的，例如Firefox渲染引擎、TiDB這種。大部分會來看此回答的人大多不是這個羣體，因此rust給你帶來的好處可能遠不足以抵消它過度的約束給開發效率的巨大折損。

【4】一些rust的設計模式已經出現。都說一個設計很好的語言就不須要很特別傳授的設計模式，常見需求都應該可以被天然的寫出來，但在我來看rust作不到這個。例如就出現了這樣的：

Vec<Rc<RefCell<Box<Trait>>>>

<a href="https://link.zhihu.com/?target=https%3A//www.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/" rel="nofollow" data-token="ce4ddf211daf018e477783183eac209c">https://www.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/</a>

Vec<Rc<RefCell這樣的pattern已經固定，但這顯然麼？我以爲並不顯然，只是你們的試錯以後的經驗，並且也沒有什麼糖來再封裝一下。

【5】代碼中充斥着語法噪音：例如什麼iter()，borrow()，unwarp()，我知道這些在這裏是須要的，但你跟scala對比一下，從代碼視覺角度上來看這真的不能算是一個更好的C++。

看了rust以後，才知道C++標準委員會其實作的很是好了，&、&&和const等比較天然的組合在一塊兒。雖然新人容易搞不懂，但你去看看rust，常常在lambda裏面冒出一些&&&xxx，&mut &mut &xxx之類的東西，感受就像是在看一個半成品的C++……

並且這裏到底有幾層哪些種&若是沒有IDE的提示的時候真的不顯然……有IDE提示也讓人心智負擔徒增。

~ 第一次新增：

【6】內存泄露不算安全問題，這個我以爲對於不少場景也有點不夠，畢竟長期不重啓無人值守的地方，內存泄露過快仍是個挺嚴重的問題。

<hr>

做者：Krys 連接：https://www.zhihu.com/question/328263899/answer/727800320 來源：知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

Rust其實強就強在，它的特性是討好管理層的，而不是程序員，好比說「這裏怎麼不能這樣寫，好彆扭，不舒服」，這些不是管理層關心的事情，管理層更關心產品質量和穩定性。你工做爽不爽是次要問題。如今就連linux內核，firefox，chrome這種項目都能有內存BUG和數據競爭，哪一個程序員要跟我說用C和C++能徹底避免這些錯誤，我就當他在吹牛。

而後管理層纔是真正能夠決定公司內部技術選型的人，或者你若是是下面寫代碼的，你要說服管理層去用一個新技術，你也要從QCD這些指標上去跟管理層談，而不是什麼你喜歡的特性。而後再加上rust和C的FFI作得不錯，因此也能夠逐步引入。

固然還有另外一個問題比較影響一個語言的長期發展，好比C++並非每一個主流編譯器都像clang同樣編譯到LLVM IR的，而rustc只有一個編譯器，而後HIR和MIR這些東西基本上成爲了rust事實上的標準了。因此一旦出現向後不兼容的語法改動，rust徹底能夠像2018兼容2015同樣，好比這個crate是2015和那個crate是2018的能夠編譯到一塊兒，由於只要IR層面上兼容就OK。也就是說進入穩定版之後就算髮現有些地方設計得很差那也是能夠改的，只要新的和老的能夠一塊兒編譯就好了。可是我看C++好像還沒提出這種相似的提案，說全部編譯器都要遵循一個什麼架構，之後好作新舊版本的兼容。那C++若是出現任何設計上的失誤就一直揹着這個歷史包袱走吧。

上面基本上是比較抽象的比較，具體一點的比較的話，rust和C++裏面不少東西仍是比較相似的。

unique_ptr -> Box

shared_ptr -> Arc

span -> slice

RValue Reference (原對象每每保存一個空狀態) -> move semantics

C++在網上也有一個很不成熟的lifetime checker的實現（基於clang），可是連一個函數返回一個抓了引用的lambda都檢測不出來。visual studio貌似也有一個，不過我沒用過，不評論了。

唉，其實說了那麼多，最直觀的感覺就是，假如團隊裏面來了一個Junior Engineer，若是是rust的模塊，我敢讓他寫代碼，只要他的代碼裏沒有unsafe基本上我不太擔憂，最多屁顛屁顛跑過來問「哎呀，爲何這裏編譯不過」，要是C++的話真心不敢放手讓他寫，到時候不知道會給其餘人挖多大個坑。

====================20190701修改=========================

評論區有人提出rust對tech leader也是有幫助的，這點我很贊成。

leader和member這兩種角色有很大的不一樣，member通常就是在一家公司呆兩三年就跑路了，後面這個項目怎麼樣其實根本管不着。每每leader在公司呆的時間長些，因此一個項目後期好很差維護，leader們比較關心。上面說的是通常的狀況。因此若是有決定權的人喜歡rust，對rust的生態發展是有好處的。

而後根據我最近面試一些C++候選人的狀況，基本上C++程序員對C++11以及以上的不少東西都不清楚。因此說不管項目是採用rust仍是現代C++都是要學習成本的，並非說只有rust纔有學習成本。

通常技術選型的時候，使用新技術就是看前期學習成本的投資能不能在後期賺回來。若是和C++98相比，那絕對能賺回來由於rust比C++98好太多，若是和現代C++相比，反正你們都有學習成本（現代C++的學習成本可能稍微低點，可是好不到哪去），雖然現代C++在一些方面好上一些，可是仍是有差距。有時候無非就是一些第三方庫是C++的因此那些模塊就用C++，否則如今引入rust差很少是穩賺不賠的。

<hr>原文地址：https://blog.csdn.net/chenxuanhanhao/article/details/97612996 </div>