與 C 語言長別離

這幾天來，我在思考那些正在挑戰 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 語言來寫系統程序對我來說不算麻煩，我發現我寫 Go 寫的還挺開心的。我的很多 C 編碼技能還可以繼續使用，我還收穫了垃圾回收機制以及並發編程機制，這何樂而不為？

（這裡有關於我第一次寫 Go 的經驗的更多信息）

本來我想把 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 語言去完成。

via: http://esr.ibiblio.org/?p=7711

作者：Eric Raymond 譯者：name1e5s 校對：yunfengHe, wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive