原文問題為：D、Go、Rust 哪一種語言最有機會取代 C？為什麼？
回覆者為 Andrei Alexandrescu，他是 D 語言架構師，此外他自 1985 年開始就用 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/ vi sion/2015H1) 是 2015 年 1 月寫的，第二個迭代 (Vision/2015H2 – D Wiki) 是 4 個月後，一個週期是 6 個月，這真是最好的諷刺。
當然啦，還有其他的問題， 但是其他問題要麼是從這幾個問題上衍生出來的，要麼就是有類似的影響
我認為 D 語言 10 倍的優勢有以下（當我在下面說「十倍」的時候，通俗來講意味著「一個數量級」)
·比 C++ 快 10 倍的編譯速度。相對於 C++ 和其他別的語言這種差距根本不可彌補。（Go 編譯的速度稍微比 D 快一點，但是運行慢一點）使用系統級語言快速編碼是一種深遠的變革。結合 D 語言的抽象能力，基本上可以把 D 作為一個很好的選擇編寫高度優化的代碼，原因很簡單，實驗性成本很低。
·比腳本語言快 10 倍的運行速度。D 的一個很好的用處是作為腳本語言使用處理一些簡單任務，這在速度上的好處是巨大的。當然，沒有「瓶頸期」的影響；如果一個腳本增長的很大，D 總是有很有效和模塊化的機制提供。當然，這值得懷疑，比如 Python 已經有很多的庫可供選擇，但是 10 倍的差距才是根本上的：系統級語言很難達到 D 的水平，但腳本語言很難突破與之的速度差距
·與 C 和 C++ 結合使用，比其他語言容易 10 倍。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 安全且精確的內存管理一切的前沿和中心、很少的問題域，但不幸的是這意味著思考和編碼的大部分是致力於基本文書工作（GC 語言實際上自動化不見了）。因此 Rust 在這個語言設計問題上消耗巨大。唯一的解決方案是發展語言，但問題仍然很抽象，端看能否幫助處理各級資源的必要性。
·外國的語法。Rust 的語法是不同的，沒有明顯優勢的差異。
Rust 的 10 倍優勢是：
·理論上要比其他語言快 10 倍。在三者之中，Rust 是其中唯一的一款有世界一流水平的語言。這些在它精確定義的語言和技術方法的深度都可以看得出。
·比其他系統語言 10 倍佳的安全性。當然，在這裡我們只限於討論它在安全上的開支。
·性價比上要比其他好 10 倍。在很長一段時間裡，Rust 的 1.0 預覽版都是社區的寵兒，沒有一點錯誤：無論發生什麼問題，現有的 Rust 或者將來的 1.0 版本都會有解決的辦法。現在，1.0 版本已經結束了蜜月期，人們的興趣發生了很明顯的下降（據我個人測算和估計），但是它的影響仍將繼續存在。此外，畢竟，Rust 是一個正統的有實用價值的語言，它很容易將人們的熱情轉化實體的銷售。
- 總而言之
無論是這幾種語言被定位於逐步替換 C，C++ 或者同時存在於代碼庫中，還是它們會成為未來項目的首選，今天的人們還是會首先選擇 C 或 C++——這一切都取決於這些語言的能力，盡量發揮它們的長處並且在各自的挑戰中獲得突破。