D、GO、Rust 誰會在未來取代 C？為什麼？

不要管我的地位和 D 語言創造者之一的身份。我會坦誠的回答這個問題。我熟悉 Go 和 Rust，並且知道 D 的缺點在哪裡。我鼓勵人們在 Rust 和 Go 社群相似職位的人可以提出他們誠懇的觀點。接著，我們開始吧。

首先，C++ 應該放在問題的哪個位置。不管它是否取代 C，或是成為取代 C 的候選人之一，C++ 是這個等式的一個關鍵部分。它是最接近 C 的，同時也是從 C 中來的。在下面幾個問題中我會假設 C++ 是把取代 C 作為目標的。

每一個語言都有一些基礎優勢（我稱之為“十倍優勢”，因為在一定的基準上比較其他確實效率更高）和數個挑戰。這些語言在未來能否取代 C 語言取決於它們如何利用它們的十倍優勢，並且如何克服他們的數個挑戰。

先讓我來棄用 D

說起D，就像是領著你在我自己的屋子裡遊覽， 我知道如何讓你看見/藏起來乾淨的/髒的角落。跟其他兩個語言相比， 關於D ，我能說的更多。原因很簡單： 我瞭解 D 瞭解地更深入，直白地說：

D 的主要挑戰有以下：

• 採用率不高 – 雖然名義上存在這麼多年了。 D 圈子裡的知情人可能會說， D 當前還是相對新的，且採用率也上漲了不是。 而且，這種看法依然存在， 而採用率是由認知驅動的。所以經理和工程師就覺得采用一種多年還沒有成熟的語言很擔心。 未來， 時間會繼續對 D 帶來負面作用，除非/直到 採用的人數有突飛猛進增長。
•  D 和垃圾回收故事的微弱聯絡。 垃圾回收是個偉大發明，但是用在D 身上的決定卻立即使D 跟核心市場 – 現有 C 和C++程式設計師分離開。對於這些程式設計師， 黨派的分割線一貫都是“不想垃圾回收？不是個事兒，你可用D with RAII 或手動管理風格！ ” 雖然這話沒錯，但是這很接近於於沒用了，因為標準庫對於其他記憶體管理風格基本不支援，這就意味這，推定的使用者需要重新建整個核心基礎設施。而且，即使覺得使用垃圾回收沒關係，實現的質量也沒有什麼可讓臉上貼金的。總之，可以這麼說， D 有 GC 的缺點，但是沒有享有他的好處。
• 一直缺乏前景。 很少有公司支援 D，D 是靠圈子流行起來的，圈裡的工程敏感度高，長期的前景，魅力和領導力難。很長一段時間， D 嘗試進行影響， 公關，都取得了負面效果， 第一個前景文件  (http://wiki.dlang.org/Vision/2015H1)  是2015 年 1 月寫的， 第二個迭代 (Vision/2015H2 – D Wiki) 是 4 個月後，一個週期是 6 個月， 這真是最好 的諷刺。

當然啦，還有其他的問題， 但是其他問題要麼是從這幾個問題上衍生出來的，要麼就是有類似的影響

我認為 D 語言 10 倍的優勢有以下(當我在下面說”十倍”的時候，通俗來講意味著”一個數量級”)

• 比C++快 10 倍的編譯速度。相對於 C++ 和其他別的語言這種差距根本不可彌補。(Go 編譯的速度稍微比 D 快一點，但是執行慢一點) 使用系統級語言快速編碼是一種深遠的變革。結合 D 語言的抽象能力，基本上可以把 D 作為一個很好的選擇編寫高度優化的程式碼，原因很簡單，實驗性成本很低。
• 比指令碼語言快 10 倍的執行速度。D 的一個很好的用處是作為指令碼語言使用處理一些簡單任務，這在速度上的好處是巨大的。當然，沒有”瓶頸期“的影響-如果一個指令碼增長的很大，D 總是有很有效和模組化的機制提供。當然，這值得懷疑，比如 Python 已經很多的庫可供選擇，但是 10 倍的差距才是根本上的：系統級語言很難達到 D 的水平，但指令碼語言很難突破與之的速度差距
• 10 倍的容易與 C 和 C++ 結合使用相對其他語言而言。D 使用和 C 和 C++ 相同的記憶體佈局；它所做的是在它之上構建結構，但是更接近底層幾乎沒有花銷，整個 C 的標準庫在語法和速度上不能更接近了，它也同為 C++ 的標準庫，許多 C 的庫都很容易和 D 結合使用。(https://github.com/D-Programming-Deimos)。它可以聲稱沒有其他語言能達到它整合的水平
• 10倍更好相比其他的系統級語言以及一般性的語言。D 的靜態內省，編譯時間的評價，混合驅動程式碼變的很有效這對其他語言是很困難的，無論是新的還是現存的；在這場遊戲中，Go 缺乏深度甚至不能抓住重點；C++還 在絕望的迷失之中；而 Rust 還在嘗試之中。

說一下Go

這裡再重申一下，Go 語言是我唯一的選擇，值得你為其付出。選擇 Go 主要有下面這些挑戰：

• 間接呼叫和垃圾收集帶來的本質上的效能下降。事實上，把 Go 改造成沒有間接函式呼叫和垃圾收集是沒有意義的，因為這些是其核心的功能。這些是提高核心效能指標的主要障礙。Go 團隊的回應是，戰術上會提高垃圾收集的效能。不過，替換 C 語言這樣的挑戰不是通過一些戰術就可以完成的。
• 政治因素。 Go 的派別異常強大，在不少問題上都各有堅持，類似的問題有大有小。在比較大的問題中，泛型的實現方式非常笨拙而低下，使得泛型可以算是 Go 語音的短板之一；在類似話題上的討論上，都足以讓人鬱悶不已。我認為技術問題的政治因素在長期是一個極端的破壞因素，希望 Go 團隊能找到解決的方式。
• 簡化卻過於簡化。Go 語言的精簡是很有名的 – 大家上手起來確實都很快。不過隨著時間推移，這成為一個問題；Go 程式碼徹底慢下來 – 程式設計師發現整天在寫同樣的東西，就像一隻螞蟻做的那樣，這是因為 Go 語言即使對很簡單的觀念和演算法也沒法很好的進行抽象。如果一個領域沒有現成的易用的庫，一般人是很難進入的。程式設計師要是用過 Go 之後再也不想用了，那感覺真不好。如果 Go 能讓那些總是重複工作的使用者改善一下處境就好了。

我認為的 Go 的10倍優勢如下：

• 10倍更好的策略。有一段時間 Go 語言宣稱要成為系統程式語言，不過後來它的屬地完全變成網路服務領域。這是一個前景非常光明的市場，Go 團隊對此把握的很好（Go 團隊有著這方面的世界級的工程師）。這個市場非常熱，一直由 Java EE 和一些執行緩慢的指令碼語言佔據著，Go 在這個領域完全就是全新的選擇，不過現在已經成為一個主要的選擇，其低位已經不可替代了。
• 工程上的10倍優勢。 Go 語言背後有一個純粹的工程團隊，這對語言的質量起著很大的幫助，尤其是對於網路庫和工具。優秀的工程管理很好的彌補了語言能力上的一些不足。
• 10倍的品牌效應。很多打算使用 Go 語言的使用者都是看在 Google 的份上。Google 出品，似乎就意味著專業、高質量和穩定。當然，品牌不是全部，不過這意味著 Go 語言只需要做到不錯就行，不需要做到完美。品牌可以完成剩下的任務。

最後但並非最不重要的

讓我再次提醒，這僅僅是我的意見。我認為 Rust 正面臨一些有趣的挑戰：

• 一個不和諧的人格。閱讀任何數量的 Rust 程式碼讓人想起這個笑話“朋友別讓朋友翹腿的一天”的漫畫影像(https://www.google.com/search?q=..)。把軀幹放在瘦腿上的人。Rust安全、精確的記憶體管理一切的前沿和中心。很少的問題域,不幸的是，這意味著思考和編碼的大部分是致力於基本文書工作(GC 語言實際上自動化不見了)。安全的，確定的記憶體回收困難的問題，但並不是唯一的問題,甚至在一個程式中最重要的問題。因此 Rust 在這個語言設計問題上消耗巨大。這是有趣的，Rust 開始成長的其他方面的語言；唯一的解決方案是發展語言，但問題仍然是抽象能否幫助處理各級資源的必要性。
• 外國的語法。Rust 的語法是不同的，沒有明顯優勢的差異。這是人來自 Algol-style 刺激性語言，需要處理一個無緣無故地不同的語法除了正確的資源簿記。

Rust 的 10 倍優勢是：

• 理論上要比其他快 10 倍。在三者之中，Rust 是其中唯一的一款有世界一流水平的語言。這些在它精確定義的語言和技術方法的深度都可以看得出。
• 比其他系統程式設計語言 10 倍更好的安全性。當然，在這裡我們只限於討論它在安全上的開支。
• 價效比上要比其他好 10 倍。在很長一段時間裡，Rust 的 1.0 預覽版都是社群的寵兒，沒有一點錯誤：無論發生什麼問題，現有的 Rust 或者將來的 1.0 版本都會有解決的辦法。現在，1.0 版本已經結束了蜜月期，人們的興趣發生了很明顯的下降（據我個人測算和估計），但是它的影響仍將繼續存在。此外，畢竟，Rust 是一個正統的有實用價值的語言，它很容易將人們的熱情轉化實體的銷售。

總而言之

無論是這幾種語言被定位於逐步替換 C，C++ 或者同時存在於程式碼庫中，還是它們會成為未來專案的首選，今天的人們還是會首先選擇 C 或 C++——這一切都取決於這些語言的能力，儘量發揮它們的長處並且在各自的挑戰中獲得突破。