Rust 發展速度比 C++ 強很多。如果去翻 open-std 的故紙堆，會發現 C++ 這邊有很多人（包括標准委員會的人）提了有用的提案，但后來大多不了了之或經歷了非常長的時間才進入標准。
>> C++ 設計哲學&思想體系
另外就是以前就有的：
Rust 有很漂亮的宏和植入類型系統的生命期體系。目前看來 C++ 沒什么可能加進去。（雖然有的編譯器已經能將生命期診斷實現為警告，但這仍與語言標准本身關系不大）
Rust 有更加簡潔而規范的對象模型。 C++ 可以寫出很 weird 的類型，譬如移動或 swap 拋異常的類型， Rust 就沒這事。
……
我覺得你應該問就語言本身而言 Rust 比 C++ 弱在哪里。 Rust 作為站在 C++ 肩膀上發展的語言，更強是很自然的，弱的地方才需要找原因。（原因可能是在規范性上的顧慮、設計偏好等）
作者：暮無井見鈴
鏈接：https://www.zhihu.com/question/328263899/answer/715380135
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
rust不需要人類看不懂代碼也看不懂編譯錯誤的那種黑魔法，就能實現和黑魔法一樣的效果。
rust編譯通過了bug比cpp少上百倍，而且因為黑魔法引發的靈異bug起碼少10倍。
https://msgpack.org/msgpack.org
對比下首頁里C/C++的范例代碼，和Rust的范例代碼，就知道什么叫黑魔法和高科技的區別了，一個直接調用只能用tuple而且還又長又臭，一個可以隨便拿個struct往里面扔。
作者：諸葛不亮
鏈接：https://www.zhihu.com/question/328263899/answer/715307958
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
作者：孫嘉龍
鏈接：https://www.zhihu.com/question/328263899/answer/727826881
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
關注了很久，但上手開始轉寫一個現有的邏輯大概一周左右。用過很多語言，C++和Scala這種比較復雜的語言都過有過至少3年以上使用經驗。說下我的使用感受，可以供准備正式入坑的人參考（不打算寫實際項目的不算）
大概來潑一點冷水。
【1】上手rust之所以說曲線陡峭主要是因為，即使你看過了文檔，也仍然會遇到很多問題。只不過C++是你在調試的時候遇到，rust是你在編譯的時候遇到。rust的編譯錯誤提示還算友好，但還不夠友好。更多時候是設計上就不滿足要求，我看了提示研究半天知道了為什么這么寫不對，但不知道怎么寫才能實現我要的功能。
由於生命周期約束的問題，很多其他語言的典型范式在rust上都不通用，你用過再多的語言可能也很難顯著縮短學習時間。（沒用過Haskell，有熟練使用Haskell來評論下？）
【2】rust的API設計首先考慮是滿足rust基本原則，然后才是使用方便，而且很多地方使用方便性不足，舉兩個例子，大家就知道這幫人設計的標准庫API易用性是個什么尿性：
- BTreeMap<f64, T>是不可用的，因為f64不是全序的（因為有NaN），語言原生類型里也沒有其他浮點類型可以當作這里的key。
- map[key]=value這種賦值方式是沒有的
- ———— ？？
所以rust的標准庫API發展出一套自己特有的風格，跟所有主流語言都不一致。
【3】本質上來說，rust大概是給操作系統、嵌入式、業務邏輯非常復雜但又極致追求安全性的場景准備的，例如Firefox渲染引擎、TiDB這種。大部分會來看此回答的人大多不是這個群體，所以rust給你帶來的好處可能遠不足以抵消它過分的約束給開發效率的巨大折損。
【4】一些rust的設計模式已經出現。都說一個設計很好的語言就不需要很特別傳授的設計模式，常見需求都應該能夠被自然的寫出來，但在我來看rust做不到這個。例如就出現了這樣的：
Vec<Rc<RefCell<Box<Trait>>>>
https://www.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/
Vec<Rc<RefCell這樣的pattern已經固定，但這顯然么？我覺得並不顯然，只是大家的試錯之后的經驗，而且也沒有什么糖來再封裝一下。
【5】代碼中充斥着語法噪音：例如什么iter()，borrow()，unwarp()，我知道這些在這里是需要的，但你跟scala對比一下，從代碼視覺角度上來看這真的不能算是一個更好的C++。
看了rust之后，才知道C++標准委員會其實做的非常好了，&、&&和const等比較自然的組合在一起。雖然新人容易搞不懂，但你去看看rust，經常在lambda里面冒出一些&&&xxx，&mut &mut &xxx之類的東西，感覺就像是在看一個半成品的C++……
而且這里到底有幾層哪些種&如果沒有IDE的提示的時候真的不顯然……有IDE提示也讓人心智負擔徒增。
~ 第一次新增：
【6】內存泄露不算安全問題，這個我覺得對於很多場景也有點不夠，畢竟長期不重啟無人值守的地方，內存泄露過快還是個挺嚴重的問題。
作者：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差不多是穩賺不賠的。
原文地址：https://blog.csdn.net/chenxuanhanhao/article/details/97612996