簡單講，原文http://eax.me/cpp-will-never-die/是俄語，有人感興趣，得到作者同意后，把它翻成英文。（譯者：然后我再把它翻成中文。）
顯而易見，這篇博文將會導致一場語言大圣戰，所以，請思考兩遍，確定你將會通過“有建設性的辯論”的評論參與討論后再開始閱讀這篇文章。
再次說明原文是俄語：）
注意：進一步講，我冒昧的認為Rust有意嘗試創建一個快速并且安全的語言。畢，Mozilla的人初構思用它作為工具來開發一個瀏覽器引擎。如果它被證明是另外一個僅僅安全的語言，那么我認為 它沒有達成目標。那里有許多非常不同的安全語言供人們選擇和品味，如果Rust沒有打算代替C++，那么：
為什么它需要包含一個不安全子集；
并且，為什么作者要拋棄Rust的輕量級進程？畢它們很方便，對吧？換句話說，如果我假設錯了，那么整件事情就沒有討論的意義了。
如有你碰巧偶爾逛逛linux.org.ru論壇，那么請被提醒到這篇文章沒有觸及為什么不喜歡Rust的那10條純技術理由。一條和親愛的伙伴@sum3rman的Skype交談透露出不止一種的“技術性”理由的看法。所以，我不得不承認，我下面羅列的東西不討人喜歡，但是我還是冒險從中引用一些感興趣的條款到這里。實際上，一些普通共識的理由自己就足夠大到不用觸及技術性的討論。
對于每一個理智程序員都非常清楚的知道的C/C++在近期不會死掉。沒有人會嘗試重用新語言新編寫幾乎所有已經存在的桌面應用程序，操作系統內核、編譯器、游戲以及瀏覽器引擎、虛擬機、數據庫、壓縮工具、音視頻編碼解碼器、一堆其他的C庫等等。這是一批數量巨大的快速的、調試過的被時間證明了的代碼。重寫的代價太昂貴了和太冒險了，并且，誠實的講，除了一些瘋狂的Rust粉絲，沒人會認為這有意義。對C/C++程序員的需求從來都是高的，并且在未來很長一段時間都是。
那么用Rust寫一些新的代碼怎么樣？
嗯，你也許記得，這并不是次嘗試創建一個“更好的”C/C++。拿D語言來舉例。它在2001年發布，且確實是一個好的語言。但沒有空間發展，沒有合適的開發工具，沒有的成功案例可以聯想到它。OpenMW項目初用D開發，但作者突然決定用C++從頭重寫。據他們坦白，他們收到一大堆的郵件說，“你們創建了一個很酷的項目，我想貢獻一些力量給它，但是我們不懂，也不喜歡學習這個愚蠢的D語言”。維基百科告訴我們，除了D，還有有其它嘗試準備殺死C++ - 舉例說Vala、Cyclone、Limbo、Bitc。有多少人曾經聽說過這些語言？
我覺得人們必須理解從歷史中得到教訓。沒有一個理智的人會在他們的項目中開始使用一個新語言，直到你展示一些非常酷的開發支持工具，告訴他們一些成功故事，并且證明一堆程序員靠這個語言做日常工作維持生活。作為程序員，他們從來不會 - 除了一些年輕的人 - 花他們的時間和健康來學習另外一種“非常棒”的語言，直到你展示一些非常酷的開發工具（不是未完工的像Racer工具那樣）和許多確實準備好的庫（不是“實驗性的”或者“不穩定的”東西），告訴他們一些成功案例，告訴他們有許多空缺在他們的城市或鄉鎮。你知道，這就像“雞和蛋”的兩難處境。只有非常少的機會，這個問題確實得到解決（近相關的案例是Go和Scala） - 這得感謝一些大公司（Google、Typesafe)的時間和金錢投入，他們基于某種理由認為值得推廣一個新語言。
正如我提到的，有許多非技術性的理由單獨就可以質疑Rust。但是，讓我們假想一會兒這些理由都不存在。那么沒有理由不用Rust寫程序，對吧？好的，這一點仍然非常可疑，這么說吧。
C/C++被從很多方面批判。順便說一下，大多數批評者還從來沒有看過產品級的C++代碼。簡短的說，C++的問題是非常快（并且只需求一點點內存、電量，等等），但是從允許數組越界，自由的存取內存等方面看不夠安全。過去，這個問題促使程序員們開發出一系列安全的語言，比如Java、C#、Python還有其他等等。但是，他們被證明和C++相比，對資源需求太多，同時還有其他一些不足 - 比如，比如當進行垃圾回收時“世界停止了”的問題。這也是為什么程序員爭扎地去創建一個和C++一樣快，但安全的語言。Rust是其中一個候選人。
Rust確實是安全的，但是，不幸的是，離快還差很遠。在寫這篇文章的時候，它和Java,go和Haskell的性能如下圖所示：
我真誠的希望程序員找到一個方法來及時的加速，但直到那時，幾乎沒有語言比Scala或者Go對安全/速度進行妥協更加感興趣。是否可以使一種語言同時具有速度和安全，或者是否由于對數組越界，安全包裹C語言庫，或則其他一些類似東西而天生注定比C/C++慢兩倍的問題仍然懸而未決。
順便問一下，什么實際上使得Rust安全？簡單的說，這門語言有內建的代碼分析器，非常艱難的一條：它可以捕獲全部典型的C++錯誤，不僅處理內存管理，而且同時考慮多線程。通過一條管道來傳遞一個指定對象的引用到另外一個線程，并且接著由你自己嘗試使用這個引用 - 程序會拒絕通過編譯。這確實非常酷。
但C++在過去30年一直屹立不倒，有大量的靜態的和動態的分析器在這些時間段被發布出來。舉一個例子，看一個關于Google sanitizers（明智分析器）的一個短片 - 他們確實非常難。不管怎么說，在任何一個嚴肅的項目中，你使用一個不斷集成的系統，運行一大堆的測試來編譯程序。如果你不這么做的話，那么你的麻煩比語言缺乏安全性而言會更糟糕，因為靜態的類型不會保證程序按你的邏輯正確的運行！所以，由于你總是運行測試，為什么不同時使用。另一方面，如果你在你的代碼的某個深處地方沒有檢查數組越界，并且Sanitizer也沒有報告這個錯誤，也許，這僅僅由于所有必須的檢查已經在上一層提供過了，同時，多一次檢查不是會使程序變慢？即使沒有sanitizers，你還可以發現許多東西供你在不同平臺編譯項目時提供伴隨適當的失真的"assert(obj -> isvalid)"風格論斷來檢查你代碼的不變性。粗糙的說，這個問題實際上源自過去那些好的圣戰，關于異教徒和加爾各答接近軟件開發（指的是，一項創新太理想化的嘗試和一個傳統經驗主義者認為被前者的支持者無心簡單化了 - 原譯者注）。
你經常可以聽到一個爭論說，90%的執行時間被10%的代碼所執行（據我理解，僅僅是一條經驗主義 - 對一個主題快速的掃描互聯網無法替代任何嚴格的科學的研究）。因此，你可以用安全的Rust語言寫你大部分的代碼，然后，剩下的10%（那些“熱”代碼）寫在不安全的子集中，所以現有的Rust實現實際上不會有不好的性能。好的，但這不更是暗示我根本不需要Rust，因為我可以用Go寫90%代碼，然后用C寫剩下的10%？只有那些尋找銀彈的人和幻想神話的異教徒會因為所有代碼都100%用同一種語言編寫而感到開心，而用Rust。但實際上一種語言有兩者方言，這和"Java + C"或者"Go+C"組合沒什么不同。
但實際上90/10規則是垃圾話。按照它的邏輯，我們可以用Java90%重寫Webkit或者VirtualBox或者GCC而得到同樣的結果。但這顯然是錯的。并不是這個比率因不同程序而變動太大，讓我們做一些計算來瞧瞧。假設整個程序用不安全的C/C++編寫，并且它的執行時間，假設是0.91（一小部分熱代碼）+0.11（大量的冷代碼）=1。現在和一個用一個帶有C代碼插入的安全語言編寫的程序做比較： 0.91 + 0.12 = 1.1，這樣，理論上說，區別是10%。是多了還是少了？這取決于項目的規模。以Google為例，即使是很少的一點比例都可以節省大量的金錢（請看第五小結，“利用”，在這篇文章中）。或者想象當下一次更新，JVM突然開始要求多10%的資源！我都害怕猜想需要多少個0在數字后面才能把比率轉化為金錢。10%是C和C++完成任務所需要的所有份額。
我們不停的念咒語“不成熟的優化是所有邪惡的根源”。但如果我們想逐字的跟隨，為什么在所有代碼里不用冒泡排序來替換快速排序？畢，我們沒有辦法確切的知道哪里是瓶頸，對嗎？為什么要把普通的活動包含在actors或者事務內存中而不用馬上用更加有效率的原子？并且，通常說，在小案例中，強制性的初始化每一個單獨的變量，執行一堆輔助性的檢查等等根本沒有意義。讓你僅花額外的幾分鐘去考慮而獲取即使只有2~5%而不是10%的性能改進，其實也不壞。此外，就像我們已經指出的，這會使C/C++程序有巨大的不同！畢，誰敢爭辯說找到了熱點，重寫那些代碼（也許有一堆）并且證明這真的變快了是一項比預先考慮性能而言更輕松的工作？
即使除了速度/安全問題比較之外，我還懷疑那語言的設計。特別對于它使用5種指針類型。一方面，讓程序員仔細考慮他們的變量存放在棧或堆里，允不允許被多線程操作的想法并不差。另一方面，想象你在寫一個程序，且在某一刻發現一些變量應該存在堆里而不是棧上。所以你用Box重寫代碼。接著你發現你實際上需要Rc或者Arc。另外，你重寫了所有的代碼。接著，再次，你再次重寫它在棧上擁有普通變量。所有的東西你都手工操作而沒有使用一個合適的IDE。正則表達式沒有幫助。或者你剛剛結束一個噩夢像“Vec>>>” - 對Java說hello吧！但悲傷的事情是編譯器已經知道每一個變量的每一件關于使用期的事，并會自動插入所有這些Box's、Arc's等等。但由于某種原因，這個責任被轉移給了程序員。讓程序員簡單的寫val（我們活在第三個千年，畢！）會更加方便。并且顯式的在需要的地方指定特殊的Box或者Rc。從這一點看，Rust的開發人員搞砸了整件事情。這個，特別的，讓Rust's的使用范圍更加窄了。沒有一個理智的人會用這樣的一個語言寫web或者服務器端軟件 - 特別當考慮到它并沒有提供比JVM相關語言更顯著的優勢。即使是Go - 帶有普通輕量級的進程（不是未來) - 看起來都是一種更好的選擇來解決這些任務。至于未來，你得學會如何正確的操作它們而不會砸到自己的腳 - 并且你談到“安全”的語言，啊？確實，所有的這些語言都有他們自己的獨特的怪癖 - 舉“整個世界都停止了”的例子。但這個問題可以通過把代碼分解成小的服務或者通過其它技術而解決。并且是的，沒有人愿意把Rust轉為Javascript，通過它來為AWS寫腳本或則為MongoDB來做查詢語言。至于安卓，它也不容易可信，但是有一個不同的理由：不僅僅只有一個架構風格，所以JVM可以做的更好。所以，如果你恰巧認為Rust是“適合所有任務”的話，我讓你失望了。
還有更多的理由來終結它：
宏使用一個拐杖來彌補由于缺乏普通異常處理而導致的過度冗長。我已經寫了關于元編程的問題 - 就是因為他們是特別的，導致我們沒有辦法得到一個合適的Rust IDE。并且，即使我并不確定，看起來Rust宏甚至并沒有命名空間。Cargo積極的鼓勵繞過Crates.io從git中直接下載各種倉庫就當人們是白癡。作為一種結果，我們有被被巨量的混亂的包終結的風險，就像Erlang世界中的Rabar。順便，我懷疑Go世界有同樣的麻煩。就像許多新語言，Rust在走簡單化的路。我通常理解為什么它沒有合適的繼承和例外，但事實本身是有些人替我做決定讓我覺得有些不舒服。C++不會限制程序員說哪些他們可以或者不可以做。現在，由于我們在走簡單化的路，為什么不拋棄所有那些語言擴展？目前組成Haskell世界的那些東西是每個程序員用他們自己方言碼出來的。智能指針，讓你知道，遠不會沒有代價，也并不會確保一個固定時間的垃圾收集。假如一些線程榮幸的釋放一個非常深的數據結構會發生什么？當死引用在一個迷宮里流浪時，所有依賴它的其他線程都安靜的耐心的等待著。Erlang以及它的一小片有同樣的困難 - 我曾經自己面對過它許多次。智能指針自己本身也有一些問題 - 例如內存碎片化和泄漏。就像讓一個弱指針在一個循環結構里 - 整件事情搞砸了。所有這些都是一個語言試圖假裝變得安全點...如果你需要一個固定的GC時間，學習你程序的行為，減輕負載并且采取預防性（舉例，提供對象池）如果你不滿意這些數字，或者可以手工管理內存。有人看到Rust里面嚴格的語義描述嗎？它至少有一個內存模型嗎？當你考慮到它可以用10種方法翻譯源代碼，你還會叫它為一個“安全”的語言可以寫出“確保正確”的程序？我不能，但再一次提醒你麻煩的根源通常是人，而不是技術。如果你的C++代碼沒有足夠好，或者Java代碼很痛苦的運行緩慢，這不是由于這個技術不好 - 這是因為你還沒有學會如何正確的使用它。因此，你也不會因為其他一些理由對Rust滿意。學習那些更流行的工具并且喜歡上它不是更容易嗎？所以，總結一下，個人來說，在下一個五年左右，我會投資我的時間去學習C/C++而不是Rust。C++是一個工業標準。程序員們已經習慣用它去解決巨量的差異化的任務超過30年了。至于Rust和其他類似的 - 他們僅僅是奇怪的玩具帶有模糊的優點。從2000年開始人們已經假設C++很快就會死掉，但自從那時開始起，C/C++并沒有變得少用。相反的，事實上，它演進了（C++11、C++14)，新的工具發布了（舉例說Clion和Clang)，并且空間巨大。
一個C++程序員從來不會很難找到一個工資不錯的工作，必要的話，可以很快的學會Rust。但相反的情況非常非常不會發生。順便說一下，找工作時，語言的選擇從來都不是和重要事。另外，一個熟練的C/C++程序員可以容易的學習PostgreSQL's或者Linux核心代碼，接觸現代的強大的開發工具，并且有一大堆的書和文章在手（比如說OpenGL）。
所以，關心一下你的健康吧，不要浪費你的時間 - 你只有比你想象的更少的時間！
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
