自從20世紀80年代以來就存在的未來編程語言的預(yù)見失誤

我的上一篇博文《與 C 語言長別離》引來了我的老朋友，一位 C++ 專家的評論。在評論里，他推薦把 C++ 作為 C 的替代品。這是不可能發(fā)生的，如果 C++ 代替 C 是趨勢的話，那么 Go 和 Rust 也就不會出現(xiàn)了。

但是我不能只給我的讀者一個光禿禿的看法（LCTT 譯注：此處是雙關(guān)語）。所以，在這篇文章中，我來講述一下為什么我不再碰 C++ 的故事。這是關(guān)于計算機語言設(shè)計經(jīng)濟學(xué)專題文章的起始點。這篇文章會討論為什么一些真心不好的決策會被做出來，然后進入語言的基礎(chǔ)設(shè)計之中，以及我們該如何修正這些問題。

在這篇文章中，我會一點一點的指出人們（當然也包括我）自從 20 世紀 80 年代以來就存在的關(guān)于未來的編程語言的預(yù)見失誤。直到最近，我們才找到了證明我們錯了的證據(jù)。

我記得我第一次學(xué)習(xí) C++ 是因為我需要使用 GNU eqn 輸出 MathXML，而 eqn 是使用 C++ 寫的。那個項目不錯。在那之后，21 世紀初，我在韋諾之戰(zhàn)Battle For Wesnoth那邊當了多年的資深開發(fā)人生，并且與 C++ 相處甚歡。

在那之后啊，有一天我們發(fā)現(xiàn)一個不小心被我們授予提交權(quán)限的人已經(jīng)把游戲的 AI 核心搞崩掉了。顯然，在團隊中只有我是不那么害怕查看代碼的。最終，我把一切都恢復(fù)正常了 —— 我折騰了整整兩周。再那之后，我就發(fā)誓我再也不靠近 C++ 了。

在那次經(jīng)歷過后，我發(fā)現(xiàn)這個語言的問題就是它在嘗試使得本來就復(fù)雜的東西更加復(fù)雜，來粗陋補上因為基礎(chǔ)概念的缺失造成的漏洞。對于裸指針這樣?xùn)|西，它說“別這樣做”，這沒有問題。對于小規(guī)模的個人項目（比如我的魔改版 eqn），遵守這些規(guī)定沒有問題。

但是對于大型項目，或者開發(fā)者水平參差不齊的多人項目（這是我經(jīng)常要處理的情況）就不能這樣。隨著時間的推移以及代碼行數(shù)的增加，有的人就會捅簍子。當別人指出有 BUG 時，因為諸如 STL 之類的東西給你增加了一層復(fù)雜度，你處理這種問題所需要的精力就比處理同等規(guī)模的 C 語言的問題就要難上很多。我在韋諾之戰(zhàn)時，我就知道了，處理這種問題真的相當棘手。

我給 Stell Heller（我的老朋友，C++ 的支持者）寫代碼時不會發(fā)生的問題在我與非 Heller 們合作時就被放大了，我和他們合作的結(jié)局可能就是我得給他們擦屁股。所以我就不用 C++ ，我覺得不值得為了其花時間。 C 是有缺陷的，但是 C 有 C++ 沒有的優(yōu)點 —— 如果你能在腦內(nèi)模擬出硬件，那么你就能很簡單的看出程序是怎么運行的。如果 C++ 真的能解決 C 的問題（也就是說，C++ 是類型安全以及內(nèi)存安全的），那么失去其透明性也是值得的。但是，C++ 并沒有這樣。

我們判斷 C++ 做的還不夠的方法之一是想象一個 C++ 已經(jīng)搞得不錯的世界。在那個世界里，老舊的 C 語言項目會被遷移到 C++ 上來。主流的操作系統(tǒng)內(nèi)核會是 C++ 寫就，而現(xiàn)存的內(nèi)核實現(xiàn)，比如 Linux 會漸漸升級成那樣。在現(xiàn)實世界，這些都沒有發(fā)生。C++ 不僅沒有打消語言設(shè)計者設(shè)想像 D、Go 以及 Rust 那樣的新語言的想法，它甚至都沒有取代它的前輩。不改變 C++ 的核心思想，它就沒有未來，也因此，C++ 的抽象泄露leaky abstraction也不會消失。

既然我剛剛提到了 D 語言，那我就說說為什么我不把 D 視為一個夠格的 C 語言競爭者的原因吧。盡管它比 Rust 早出現(xiàn)了八年（和 Rust 相比是九年）Walter Bright 早在那時就有了構(gòu)建那樣一個語言的想法。但是在 2001 年，以 Python 和 Perl 為首的語言的出現(xiàn)已經(jīng)確定了，專有語言能和開源語言抗衡的時代已經(jīng)過去。官方 D 語言庫/運行時和 Tangle 的無謂紛爭也打擊了其發(fā)展。它從未修正這些錯誤。

然后就是 Go 語言（我本來想說“以及 Rust”。但是如前文所述，我認為 Rust 還需要幾年時間才能有競爭力）。它的確是類型安全以及內(nèi)存安全的（好吧，是在大多數(shù)時候是這樣，但是如果你要使用接口的話就不是如此了，但是自找麻煩可不是正常人的做法）。我的一位好友，Mark Atwood，曾指出過 Go 語言是脾氣暴躁的老頭子因為憤怒而創(chuàng)造出的語言，主要是C 語言的作者之一（Ken Thompson） 因為 C++ 的混亂臃腫造成的憤怒，我深以為然。

我能理解 Ken 惱火的原因。這幾十年來我就一直認為 C++ 搞錯了需要解決的問題。C 語言的后繼者有兩條路可走。其一就是 C++ 那樣，接受 C 的抽象泄漏、裸指針等等，以保證兼容性。然后以此為基礎(chǔ)，構(gòu)建一個最先進的語言。還有一條道路，就是從根源上解決問題 ——修正C語言的抽象泄露。這一來就會破環(huán)其兼容性，但是也會杜絕 C/C++ 現(xiàn)有的問題。

對于第二條道路，第一次嚴謹?shù)膰L試就是 1995 年出現(xiàn)的 Java。Java 搞得不錯，但是在語言解釋器上構(gòu)建這門語言使其不適合系統(tǒng)編程。這就在系統(tǒng)編程那留下一個巨大的洞，在 Go 以及 Rust 出現(xiàn)之前的 15 年里，都沒有語言來填補這個空白。這也就是我的 GPSD 和 NTPsec 等軟件在 2017 年仍然主要用 C 寫成的原因，盡管 C 的問題也很多。

在許多方面這都是很糟糕的情況。盡管由于缺少足夠多樣化的選擇，我們很難認識到 C/C++ 做的不夠好的地方。我們都認為在軟件里面出現(xiàn)缺陷以及基于安全方面考慮的妥協(xié)是理所當然的，而不是想想這其中多少是真的由于語言的設(shè)計問題導(dǎo)致的，就像緩存區(qū)溢出漏洞一樣。

所以，為什么我們花了這么長時間才開始解決這個問題？從 C 1972 年面世到 Go 2009 年出現(xiàn)，這其中隔了 37 年；Rust 也是在其僅僅一年之前出現(xiàn)。我想根本原因還是經(jīng)濟。

從最早的計算機語言開始，人們就已經(jīng)知道，每種語言的設(shè)計都體現(xiàn)了程序員時間與機器資源的相對價值的權(quán)衡。在機器這端，就是匯編語言，以及之后的 C 語言，這些語言以犧牲開發(fā)人員的時間為代價來提高性能。 另一方面，像 Lisp 和（之后的）Python 這樣的語言則試圖自動處理盡可能多的細節(jié)，但這是以犧牲機器性能為代價的。

廣義地說，這兩端的語言的最重要的區(qū)別就是有沒有自動內(nèi)存管理。這與經(jīng)驗一致，內(nèi)存管理缺陷是以機器為中心的語言中最常見的一類缺陷，程序員需要手動管理資源。

當相對價值斷言與軟件開發(fā)在某個特定領(lǐng)域的實際成本動因相匹配時，這個語言就是在經(jīng)濟上可行的。語言設(shè)計者通過設(shè)計一個適合處理現(xiàn)在或者不遠的將來出現(xiàn)的情況的語言，而不是使用現(xiàn)有的語言來解決他們遇到的問題。

隨著時間的推移，時興的編程語言已經(jīng)漸漸從需要手動管理內(nèi)存的語言變?yōu)閹в凶詣觾?nèi)存管理以及垃圾回收（GC）機制的語言。這種變化對應(yīng)了摩爾定律導(dǎo)致的計算機硬件成本的降低，使得程序員的時間與之前相比更加的寶貴。但是，除了程序員的時間以及機器效率的變化之外，至少還有兩個維度與這種變化相關(guān)。

其一就是距離底層硬件的距離。底層軟件（內(nèi)核與服務(wù)代碼）的低效率會被成倍地擴大。因此我們可以發(fā)現(xiàn)，以機器為中心的語言向底層推進，而以程序員為中心的語言向著高級發(fā)展。因為大多數(shù)情況下面向用戶的語言僅僅需要以人類的反應(yīng)速度（0.1 秒）做出回應(yīng)即可。

另一個維度就是項目的規(guī)模。由于程序員抽象發(fā)生的問題的漏洞以及自身的疏忽，任何語言都會有可預(yù)期的每千行代碼的出錯率。這個比率在以機器為中心的語言上很高，而在程序員為中心的帶有 GC 的語言里就大大降低。隨著項目規(guī)模的增大，帶有 GC 的語言作為一個防止出錯率不堪入目的策略就顯得愈發(fā)重要起來。

當我們使用這三種維度來看當今的編程語言的形勢 —— C 語言在底層，蓬勃發(fā)展的帶有 GC 的語言在上層，我們會發(fā)現(xiàn)這基本上很合理。但是還有一些看似不合理的是 —— C 語言的應(yīng)用不合理地廣泛。

我為什么這么說？想想那些經(jīng)典的 Unix 命令行工具吧。那些小程序通常都可以使用帶有完整的 POSIX 支持的腳本語言快速實現(xiàn)出來。重新編碼那些程序?qū)⑹沟盟鼈冋{(diào)試、維護和拓展起來都會更加簡單。

但是為什么還是使用 C （或者某些像 eqn 的項目，使用 C++）？因為有轉(zhuǎn)換成本。就算是把相當小、相當簡單的程序使用新的語言重寫并且確認你已經(jīng)忠實地保留了所有非錯誤行為都是相當困難的?；\統(tǒng)地說，在任何一個領(lǐng)域的應(yīng)用編程或者系統(tǒng)編程在一種語言的權(quán)衡過時之后，仍然堅持使用它。

這就是我和其他預(yù)測者犯的大錯。 我們認為，降低機器資源成本（增加程序員時間的相對成本）本身就足以取代 C 語言（以及沒有 GC 的語言）。 在這個過程中，我們有一部分或者甚至一大部分都是錯誤的 —— 自 20 世紀 90 年代初以來，腳本語言、Java 以及像 Node.js 這樣的東西的興起顯然都是這樣興起的。

但是，競爭系統(tǒng)編程語言的新浪潮并非如此。 Rust 和 Go 都明確地回應(yīng)了增加項目規(guī)模這一需求。 腳本語言是先是作為編寫小程序的有效途徑，并逐漸擴大規(guī)模，而 Rust 和 Go 從一開始就定位為減少大型項目中的缺陷率。 比如 Google 的搜索服務(wù)和 Facebook 的實時聊天復(fù)用。

我認為這就是對 “為什么不再早點兒” 這個問題的回答。Rust 和 Go 實際上并不算晚，它們相對迅速地回應(yīng)了一個直到最近才被發(fā)現(xiàn)低估的成本動因問題。

好，說了這么多理論上的問題。按照這些理論我們能預(yù)言什么？它告訴我們在 C 之后會出現(xiàn)什么？

推動 GC 語言發(fā)展的趨勢還沒有扭轉(zhuǎn)，也不要期待其扭轉(zhuǎn)。這是大勢所趨。因此：最終我們將擁有具有足夠低延遲的 GC 技術(shù)，可用于內(nèi)核和底層固件，這些技術(shù)將以語言實現(xiàn)方式被提供。 這些才是真正結(jié)束 C 長期統(tǒng)治的語言應(yīng)有的特性。

我們能從 Go 語言開發(fā)團隊的工作文件中發(fā)現(xiàn)端倪，他們正朝著這個方向前進 —— 可參見關(guān)于并發(fā) GC 的學(xué)術(shù)研究 —— 從未停止研究。 如果 Go 語言自己沒有選擇這么做，其他的語言設(shè)計師也會這樣。 但我認為他們會這么做 —— 谷歌推動他們的項目的能力是顯而易見的（我們從 “Android 的發(fā)展”就能看出來）。

在我們擁有那么理想的 GC 之前，我把能替換 C 語言的賭注押在 Go 語言上。因為其 GC 的開銷是可以接受的 —— 也就是說不只是應(yīng)用，甚至是大部分內(nèi)核外的服務(wù)都可以使用。原因很簡單： C 的出錯率無藥可醫(yī)，轉(zhuǎn)化成本還很高。

上周我嘗試將 C 語言項目轉(zhuǎn)化到 Go 語言上，我發(fā)現(xiàn)了兩件事。其一就是這活很簡單， C 的語言和 Go 對應(yīng)的很好。還有就是寫出的代碼相當簡單。由于 GC 的存在以及把集合視為首要的數(shù)據(jù)結(jié)構(gòu)，人們會預(yù)期代碼減少，但是我意識到我寫的代碼比我最初期望的減少的更多，比例約為 2:1 —— 和 C 轉(zhuǎn) Python 類似。

抱歉吶，Rust 粉們。你們在內(nèi)核以及底層固件上有著美好的未來，但是你們在別的 C 領(lǐng)域被 Go 壓的很慘。沒有 GC ，再加上難以從 C 語言轉(zhuǎn)化過來，還有就是 API 的標準部分還是不夠完善。（我的select(2)又哪去了??？）。

對你們來說，唯一的安慰就是，C++ 粉比你們更糟糕 —— 如果這算是安慰的話。至少 Rust 還可以在 Go 顧及不到的 C 領(lǐng)域內(nèi)大展宏圖。C++ 可不能。