這幾天來，我（Eric Raymond）在思考那些正在挑戰C語言的系統編程語言***地位的新潮語言，尤其是 Go 和 Rust。思考的過程中，我意識到了一個讓我震驚的事實——我有著 35 年的C語言經驗。每周我都要寫很多C代碼，但是我已經記不清楚上一次我創建一個新的C語言項目是在什么時候了。

　　如果你完全不認為這種情況令人震驚，那你很可能不是一個系統程序員。我知道有很多程序員使用更高級的語言工作。但是我把大部分時間都花在了深入打磨像 NTPsec、 GPSD 以及 giflib 這些東西上。熟練使用C語言在這幾十年里一直就是我的專長。

　　但是，現在我不僅是不再使用 C 語言寫新的項目，甚至我都記不清我是什么時候開始這樣做的了，而且……回頭想想，我覺得這都不是本世紀發生的事情。

　　這個對于我來說是件大事，因為如果你問我，我的五個最核心軟件開發技能是什么，“C語言專家” 一定是你最有可能聽到的之一。這也激起了我的思考。

　　C 語言的未來會怎樣 ？C語言是否正像當年的 COBOL 語言一樣，在輝煌之后，走向落幕？

　　我恰好是在C語言迅猛發展，并把匯編語言以及其它許多編譯型語言擠出主流存在的前幾年開始編程的。

　　那場過渡大約是在 1982 到 1985 年之間。在那之前，有很多編譯型語言爭相吸引程序員的注意力，那些語言中還沒有明確的***；但是在那之后，小眾的語言就直接毫無聲息的退出了舞臺。

　　主流的語言（FORTRAN、Pascal、COBOL）則要么只限于老代碼，要么就是固守單一領域，再就是在C語言的邊緣領域頂著愈來愈大的壓力茍延殘喘。

　　而在那以后，這種情形持續了近 30 年。盡管在應用程序開發上出現了新的動向：Java、 Perl、 Python， 以及許許多多不是很成功的競爭者。起初我很少關注這些語言，這很大一部分是因為在它們的運行時的開銷對于當時的實際硬件來說太大。因此，這就使得C的成功無可撼動。

　　為了使用和對接大量已有的C語言代碼，你得使用C語言寫新代碼（一部分腳本語言嘗試過打破這種壁壘，但是只有 Python 有可能取得成功）。

　　回想起來，我在 1997 年使用腳本語言寫應用時本應該注意到這些語言的更重要的意義的。當時我寫的是一個名為 SunSITE 的幫助圖書管理員做源碼分發的輔助軟件，當時使用的是 Perl 語言。

　　這個應用完全是用來處理文本輸入的，而且只需要能夠應對人類的反應速度即可（大概 0.1 秒），因此使用C或者別的沒有動態內存分配以及字符串類型的語言來寫就會顯得很傻。

　　但是在當時，我僅僅是把其視為一個試驗，而完全沒有想到我幾乎再也不會在一個新項目的***個文件里敲下 int main (int argc, char **argv) 這樣的C語言代碼了。

　　我說“幾乎”，主要是因為 1999 年的 SNG。 我想那是我***一個用C從頭開始寫的項目了。

　　在那之后我寫的所有的C代碼都是在為那些上世紀已經存在的老項目添磚加瓦，或者是在維護諸如 GPSD 以及 NTPsec 一類的項目。

　　當年我本不應該使用C語言寫 SNG 的。因為在那個年代，摩爾定律的快速迭代使得硬件愈加便宜，使得像 Perl 這樣的語言的執行效率也不再是問題。僅僅三年以后，我可能就會毫不猶豫地使用 Python 而不是C語言來寫 SNG。

　　在 1997 年我學習了 Python， 這對我來說是一道分水嶺。這個語言很美妙——就像我早年使用的 Lisp 一樣，而且 Python 還有很酷的庫！甚至還完全遵循了 POSIX！還有一個蠻好用的對象系統！Python 沒有把C語言擠出我的工具箱，但是我很快就習慣了在只要能用 Python 時就寫 Python ，而只在必須使用C語言時寫C。

　　（在此之后，我開始在我的訪談中指出我所謂的 “Perl 的教訓” ，也就是任何一個沒能實現和C語言語義等價的遵循 POSIX 的語言都注定要失敗。在計算機科學的發展史上，很多學術語言的骨骸俯拾皆是，原因是這些語言的設計者沒有意識到這個重要的問題。）

　　顯然，對我來說，Python 的主要優勢之一就是它很簡單，當我寫 Python 時，我不再需要擔心內存管理問題或者會導致核心轉儲的程序崩潰 —— 對于C程序員來說，處理這些問題煩的要命。

　　而不那么明顯的優勢恰好在我更改語言時顯現，我在 90 年代末寫應用程序和非核心系統服務的代碼時，為了平衡成本與風險都會傾向于選擇具有自動內存管理但是開銷更大的語言，以抵消之前提到的C語言的缺陷。

　　而在僅僅幾年之前（甚至是 1990 年），那些語言的開銷還是大到無法承受的；那時硬件產業的發展還在早期階段，沒有給摩爾定律足夠的時間來發揮威力。

　　盡量地在C語言和 Python 之間選擇 C —— 只要是能的話我就會從C語言轉移到 Python。這是一種降低工程復雜程度的有效策略。我將這種策略應用在了 GPSD 中，而針對 NTPsec ， 我對這個策略的采用則更加系統化。這就是我們能把 NTP 的代碼庫大小削減四分之一的原因。

　　但是今天我不是來講 Python 的。盡管我覺得它在競爭中脫穎而出，Python 也未必真的是在 2000 年之前徹底結束我在新項目上使用C語言的原因，因為在當時任何一個新的學院派的動態語言都可以讓我不再選擇使用C語言。也有可能是在某段時間里在我寫了很多 Java 之后，我才慢慢遠離了C語言。

　　我寫這個回憶錄是因為我覺得我并非特例，在世紀之交，同樣的發展和轉變也改變了不少C語言老手的編碼習慣。像我一樣，他們在當時也并沒有意識到這種轉變正在發生。

　　在 2000 年以后，盡管我還在使用 C/C++ 寫之前的項目，比如 GPSD ，游戲韋諾之戰以及 NTPsec，但是我的所有新項目都是使用 Python 的。

　　有很多程序是在完全無法在C語言下寫出來的，尤其是 reposurgeon 以及 doclifter 這樣的項目。

　　由于 C 言受限的數據類型本體論以及其脆弱的底層數據管理問題，嘗試用C寫的話可能會很恐怖，并注定失敗。

　　甚至是對于更小的項目——那些可以在C中實現的東西——我也使用 Python 寫，因為我不想花不必要的時間以及精力去處理內核轉儲問題。這種情況一直持續到去年年底，持續到我創建我的***個 Rust 項目，以及成功寫出***個使用 Go 語言的項目。

　　如前文所述，盡管我是在討論我的個人經歷，但是我想我的經歷體現了時代的趨勢。我期待新潮流的出現，而不是僅僅跟隨潮流。

　　在 98 年的時候，我就是 Python 的早期使用者。來自 TIOBE 的數據則表明，在 Go 語言脫胎于公司的實驗項目并剛剛從小眾語言中脫穎而出的幾個月內，我就開始實現自己的***個 Go 語言項目了。

　　總而言之：直到現在***批有可能挑戰C語言的傳統地位的語言才出現。

　　我判斷這個的標準很簡單——只要這個語言能讓我等C語言老手接受不再寫C的事實，這個語言才 “有可能” 挑戰到C語言的地位—— 來看啊，這有個新編譯器，能把C轉換到新語言，現在你可以讓他完成你的全部工作了 —— 這樣C語言的老手就會開心起來。

　　Python 以及和其類似的語言對此做的并不夠好。使用 Python 實現 NTPsec（以此舉例）可能是個災難，最終會由于過高的運行時開銷以及由于垃圾回收機制導致的延遲變化而爛尾。

　　如果需求是針對單個用戶且只需要以人類能接受的速度運行，使用 Python 當然是很好的，但是對于以機器的速度運行的程序來說就不總是如此了 —— 尤其是在很高的多用戶負載之下。

　　這不只是我自己的判斷 —— 因為拿 Go 語言來說，它的存在主要就是因為當時作為 Python 語言主要支持者的 Google 在使用 Python 實現一些工程的時候也遭遇了同樣的效能痛點。

　　Go 語言就是為了解決 Python 搞不定的那些大多由C語言來實現的任務而設計的。

　　盡管沒有一個全自動語言轉換軟件讓我很是不爽，但是使用 Go 語言來寫系統程序對我來說不算麻煩，我發現我寫G寫的還挺開心的。我的很多C編碼技能還可以繼續使用，我還收獲了垃圾回收機制以及并發編程機制，這何樂而不為？

　　本來我想把 Rust 也視為 “C 語言要過時了”的例證，但是在學習并嘗試使用了這門語言編程之后，我覺得這種語言現在還沒有做好準備。也許 5 年以后，它才會成為C語言的對手。

　　隨著 2017 結束，我們已經發現了一個相對成熟的語言，其和C類似，能夠勝任C語言的大部分工作場景（我在下面會準確描述），在幾年以后，這個語言界的新星可能就會取得成功。

　　這件事意義重大。如果你不長遠地回顧歷史，你可能看不出來這件事情的偉大性。三十年了 —— 這幾乎就是我作為一個程序員的全部生涯，我們都沒有等到一個C語言的繼任者，也無法遙望C之后的系統編程會是什么樣子的。而現在，我們面前突然有了后C時代的兩種不同的展望和未來……

　　……另一種展望則是下面這個語言留給我們的。

　　我的一個朋友正在開發一個他稱之為 “Cx” 的語言，這個語言在C語言上做了很少的改動，使得其能夠支持類型安全；他的項目的目的就是要創建一個能夠在最少人力參與的情況下把古典 C 語言修改為新語言的程序。

　　我不會指出這位朋友的名字，免得給他太多壓力，讓他做出太多不切實際的保證。但是他的實現方法真的很是有意思，我會盡量給他募集資金。

　　現在，我們看到了可以替C語言實現系統編程的三種不同的可能的道路。而就在兩年之前，我們的眼前還是一片漆黑。我重復一遍：這件事情意義重大。

　　我是在說C語言將要滅絕嗎？不是這樣的，在可預見的未來里，C語言還會是操作系統的內核編程以及設備固件編程的主流語言，在這些場景下，盡力壓榨硬件性能的古老規則還在奏效，盡管它可能不是那么安全。

　　現在那些將要被C的繼任者攻破的領域就是我之前提到的我經常涉及的領域 —— 比如 GPSD 以及 NTPsec、系統服務以及那些因為歷史原因而使用 C 語言寫的進程。還有就是以 DNS 服務器以及郵件傳輸代理 —— 那些需要以機器速度而不是人類的速度運行的系統程序。

　　現在我們可以對后C時代的未來窺見一斑，即上述這類領域的代碼都可以使用那些具有強大內存安全特性的 C 語言的替代者實現。Go 、Rust 或者 Cx ，無論是哪個，都可能使C的存在被弱化。

　　比如，如果我現在再來重新實現一遍 NTP ，我可能就會毫不猶豫的使用 Go 語言去完成。