D語言架構師Andrei Alexandrescu談D、Go、Rust取代C/C++

做爲D語言的聯合創始人之一，儘管個人身份來回答這個問題顯得有點不合適，可是我仍會盡量客觀地回答這個問題。我關注着Go和Rust的發展，同時我也知道D語言的缺點。在Go和Rust社區中，我一直鼓勵同行的朋友分享他們的真實想法，因此在這裏也一如既往。

首先，C++在這個問題上處在一個特殊的位置，不管它是否會像C同樣被取代，亦或是成爲替代C的語言，C++都是程序語言領域中的一個關鍵部分。

C++是最接近C的語言，安裝配置的方式也明顯類似，鑑於C++的年齡，下面我假設標題的問題也將C++語言列入替代C語言的語言列表中。

每一種語言都有一些它最根本的優點（我稱之爲「十倍優點」，指在這方面它比其餘語言高几個等級）和一些它要面對的挑戰。 這些語言的將來如何，以及它們是否可以取代C語言，取決於它們使用什麼策略來利用好本身的「十倍優點」，以及它們如何克服他們所面對的各類挑戰。

D語言

顯然，這對於我來講輕車熟路，因此我知道如何在你面前秀出D語言設計的亮點之處，也知道如何帶着你繞開D語言設計的很差之處。相比Go和Rust我更瞭解D語言，因此我可能會更多地去談論D語言。坦白而言，D語言所面對的主要挑戰是以下：

• 存在多年卻一直沒有被業界普遍採用。D社區內的一些業內人士有資格這樣說（D當前仍是相對比較年輕的一門語言，並且它的市場佔用率也確實在逐漸增長），然而觀念很難改變，同時觀念也支配着市場佔有率，所以管理者和工程師很難去接受一門在很長時間內都沒有取得成功的語言，更進一步地說，若是短時間以內D語言不能取得市場佔有率的明顯提高，那麼時間的流逝將對D語言更加不利。

• D語言同垃圾收集器的關係。GC是一項偉大的發明，可是將其用於D語言的決定使D遠離了核心市場（也就是現有的C和C++開發人員）。對於C和C++程序員，歷史悠久的主流思想是不使用GC，或者是在D中使用RAII或手工管理內存。儘管如此，因爲標準庫存對於其它的內存管理方式缺少支持，以致於它形同虛設，須要用戶本身去實現底層的基礎設施，因此不使用GC而使用其它的內存管理方式在D語言中的意義不大。此外，對於那些願意使用GC的人，其實現質量也是乏善可陳。總體而言，D持有由GC致使的缺點，卻沒有得到GC帶來的好處。

• 缺少遠見。缺少企業的支持，D一直是社區驅動，工程智慧比長期願景更容易找到魅力和領導能力。在很長一段時間內，D的推廣和公關作的都很差。第一個願景文檔（http://wiki.dlang.org/Vision/2015H1）是定在2015年1月1日，下一個迭代(Vision/2015H2 - DWiki)已經晚了4個月，持續了6個月的迭代週期已最好的諷刺。

固然D語言還有其它問題，可是它們要麼由上面的問題所衍生，要麼影響比較小。

我認爲D語言的「10倍」優點在如下幾方面(在接下的部分當個人說到"10x"時，通俗的理解是一個數量級):

• 同等規模的代碼，D語言的編譯速度比C++快。編譯速度上的差距對於C++而言根本就不可能彌補，其餘語言要想追遇上D也是比登天還難。（Go的編譯速度比D略微快一點，可是生成的代碼運行效率更慢一點）使用系統級的語言快速的構建代碼，這是一種具備深遠意義的變革。D語言的高度抽象能力使它成爲編寫高度優化代碼的一很好的選擇，由於實驗成本很低。

• 比同等開發效率的腳本語言快。使用D語言的一個好處是能夠像使用腳本語言同樣便利地去處理各類平常的事務。構建/運行的過程很是快，而且速度的提高是很是明顯的，同時D語言沒有「碰壁效應（hitting the wall）」，若是腳本變得很是巨大，D老是有其它的如模塊化這樣的機制來提供對於速度優化的支持。固然，這種比較前提是基於類似的顆粒度，像Python有更多的可直接使用的庫資源，可是一個數量級的差距是根本存在的：系統級編程語言很難達到D語言的水平，而腳本語言又沒法在速度上縮小與D語言的差距。

• 與C和C++的交互比其它語言容易。D使用與C和C++相同的內存佈局，它所作的一切其它的工做都是創建在這個基礎上，同時底層能作到零開銷讀取。整個C標準庫均可以在不作特殊的語法處理的狀況下實現無運行損耗的去訪問，對於C++標準庫要達到一樣的支持，還有一些工做要作，還有許多C庫能夠直接支持(https://github.com/D-Programming-Deimos)，甚至能夠這樣說，沒有其它語言可以達到D語言的集成水平。

• 在泛型編程方面比其它系統級語言好。D語言的靜態內省、編譯時計算、minedin-deriven代碼生成構成一個強大的組合，而這在其它語言裏是很難正確作到的。在這方面，Go沒有任何深度，由於它直接不提供這個功能。C++17也絕望地迷失了方向，Rust則是剛剛企圖涉足。

Go語言

申明一下，下面都是個人我的觀點。我認爲Go語言要面對如下挑戰：

• 因爲間接調用和垃圾回收機制而致使的根本性緩慢。Go語言的一個核心特徵是不借用間接的函數調用和垃圾回收機制幾乎沒法寫出有意義的代碼，而這也正是Go在實現核心性能道路上所面對的主要障礙，Go團隊對於這一點做出的應對是戰術性的，例如他們採起的措施是在實現更好的垃圾收集器方向展開工做，可是我認爲Go對C的這種戰術性的挑戰是很難取得成功的。

• 政治。Go所走的路線在一些問題上持有極其強硬和死板態度，這些問題有大有小。在比較大的方面，泛型編程被嚴格控制，甚至貶低到只有"N"個字；有關泛型編程的討論都是試圖去勸阻任何有意義的嘗試，這已經足夠讓人以爲恥辱。從長遠來看，技術問題的政治化是一種極其有害的模式，因此但願Go社區可以找到修正它的方法。

• 從簡單到簡單化。Go是出了名的簡單，有不少人們快速學習使用它的事蹟。然而隨着時間的推移，這也一樣成了一個問題。Go程序員是沒有但願的過路人，他們發現本身一次又一次寫着相同的東西，因爲Go甚至沒法對最簡單的概念和算法進行抽象。沒有被庫很好地支持的區域是很難進入的，這在使用Go開發了一個項目並永遠再也不想使用Go的開發者中是一個強烈的反映。若是Go可以使開發中的「回頭客」過的更好，那將是很是偉大的。

在我看來，Go語言的十倍優點以下：

• 策略更好。在短暫的定位於系統編程語言以後，它將本身定位於網絡基礎服務設施領域，這是一個明智的營銷舉措，結合了Go團隊的技術優點（這個世界上最好的網絡服務開發工程師），做爲一個市場熱點，網絡服務開發領域一直被JavaEE和其它一些緩慢的腳本語言統治着，Go爲這個領域帶來了一股新的氣息，如今Go是這個領域的一個主要成員，而且它的地位很難被取代。

• 工程性好。Go的背後有一個堅實的工程技術團隊，他們保證了Go語言，以及其網絡庫和工具的質量。直到目前爲止，良好的工程性已經彌補了Go語言自己的不少不足之處。

• 品牌好。咱們中的不少人都得認可Go的一個重要推廣因素是它與Google的關係，這使得人們對於它的專業性、質量和穩定性有更多的信心。固然品牌不是萬能的，可是那意味着Go只須要成爲一個體面的語言，它不須要成一個「夢幻」般的語言，因這品牌會去幫助它推廣。

Rust語言

讓我再次強調一下，這只是個人我的見解。我認爲Rust面臨着一些有趣的挑戰：

• 一個不和諧的特性。閱讀任何數量的Rust代碼都能讓人想起這個笑話「朋友們不要讓朋友跳腿日」和體格強壯的男人躺在廋腿上休息的漫畫形象。Rust把安全、精確的內存管理做爲一切的中心放在首位。不幸的是，這在其餘語言中幾乎都算不上問題。它意味着思考和編碼的工做的很大一部份內容將是致力於一份相似文職的工做(而GC卻可讓這一部份內容自動淡出人們的視線)，安全、肯定地進行內存回收是一個困難的問題，但並非惟一的問題，在編程中它也不是最重要的問題。所以，Rust爲解決這個問題花費了不成比例的語言設計成本，有趣的是Rust在其餘方面也慢慢成長起來。讓Rust在個性上更和諧的惟一解決方案是在語言發展的過程當中，引入其它抽象機制來幫助解決煩人的資源管理的問題。

• 另類的語法。Rust的語法比較獨特，可是這種語法的差別並無明顯的優點，它的語法讓來自於Algol語法風格的人們以爲很是難受。

Rust的十倍優點以下：

• 理論優點。在三個語言中，Rust是惟一的由世界級PL理論家領銜的語言，這能夠經過其語言的精肯定義和其技術方法的深度獲得驗證。
• 安全性好。固然我前面只是討論了一下這樣作的成本。
• 公關好。當Rust在社區中深受喜好和幾乎不會出錯時，pre-1.0已經有很長一段時間了。不管何時出現問題，Rust要麼本身解決，要麼經過1.0解決。1.0的發佈結束了Rust和大衆的蜜月期，據個人測量和評估，人們對於Rust的廣泛熱情會有必定程度的降低，可是Rust終究是一門體面的語言，它有實物來應對而且創建一個良好推廣模式。

總結

哪種語言都能取代C、C++，亦或者是共存，甚而哪種語言更好，但大多數狀況下，在實際的項目中都仍是默認選擇了C或者C++，至於哪種語言是項目的更好選擇，這取決於幾個語言在項目中的特有長處。