眾所周知，C 是一種廣泛非常使用的語(yǔ)言，從操作系統(tǒng)內(nèi)核到加密算法的編寫(xiě)，到處都在使用 C。如今，我們是否應(yīng)該用另一種語(yǔ)言來(lái)替換 C 呢？ 盡管C 語(yǔ)言發(fā)布于 1972 年，但至今仍是使用最廣泛的語(yǔ)言之一，同時(shí)按照如今的標(biāo)準(zhǔn)來(lái)看，C 語(yǔ)言也存在許多限制和缺陷。

圖：2020年 TIOBE 編程語(yǔ)言排行榜 有人希望用另一種語(yǔ)言來(lái)替換 C 的關(guān)鍵原因也正在于此。用 C/C++ 編寫(xiě)的關(guān)鍵性軟件實(shí)在太多了，但 C/C++ 中包含大量的“潛規(guī)則”。舉個(gè)例子 OpenSSL 庫(kù)中的 bug 就源于此。眾所周知，C 語(yǔ)言非常不善于處理類似于緩沖溢出的問(wèn)題。C 語(yǔ)言中的“坑”實(shí)在太多了。C 語(yǔ)言沒(méi)有類型安全，對(duì)于熱衷于動(dòng)態(tài)語(yǔ)言的人來(lái)說(shuō)，這聽(tīng)起來(lái)可能有些奇怪。而 Python 或 Julia 等動(dòng)態(tài)語(yǔ)言就可以捕捉到錯(cuò)誤的類型用法，例如在 if 語(yǔ)句中使用整數(shù)的錯(cuò)誤。雖然動(dòng)態(tài)語(yǔ)言無(wú)法在編譯時(shí)捕捉到這類問(wèn)題，但如果它們具有強(qiáng)大的類型系統(tǒng)，那么就可以在運(yùn)行時(shí)捕捉到很多問(wèn)題。這對(duì)于安全性特別重要。在很大程度上，安全漏洞都會(huì)引發(fā)未定義的行為，而不會(huì)正常終止程序。 話說(shuō)回來(lái)，如果 C 語(yǔ)言如此之糟糕，那么為什么還沒(méi)有被替換掉呢？其中的原因很多。其實(shí)在某些地方，它已經(jīng)被替換了。以前很多用 C 處理的任務(wù)如今都改用 Java、C#、C++ 以及其他語(yǔ)言了。 因此，我們需要深挖一下究竟還有哪些軟件仍然以 C 語(yǔ)言為主：

操作系統(tǒng)內(nèi)核。例如 Linux 等

微控制器

視頻編解碼器

底層共享庫(kù)，例如 OpenSSL 等

Unix 命令行工具，例如 ls、cat 和 git 等

為什么這些領(lǐng)域仍然由 C 語(yǔ)言主導(dǎo)？因?yàn)橹钡阶罱覀円矝](méi)有更好的替代 C 語(yǔ)言的方案。 上個(gè)世紀(jì) 90 年代，許多語(yǔ)言（例如 Java、C#、VB.NET 和 F#）都將重點(diǎn)放在創(chuàng)建垃圾收集上。對(duì)于上述領(lǐng)域來(lái)說(shuō)，這些語(yǔ)言都不是好的解決方案。 除此之外，還有其他 80 年代和 90 年代出現(xiàn)的語(yǔ)言，例如 Perl、Python、Ruby 和 JavaScript 等，它們都不適合這些任務(wù)。 當(dāng)然，我們還有一些其他靜態(tài)類型的語(yǔ)言，例如 Ada、Modula-2 等。但是，一般情況下，這些語(yǔ)言都很難與開(kāi)發(fā)人員的技術(shù)結(jié)合，也很難與已有的 C 語(yǔ)言庫(kù)配合使用。 還有 D 等其他語(yǔ)言，但是其復(fù)雜性與 C++ 差不多，因此對(duì) C 開(kāi)發(fā)人員沒(méi)有吸引力。而且，最初它也需要垃圾收集，所以可能并不適合上述提到的許多領(lǐng)域。如果你開(kāi)發(fā)的應(yīng)用程序需要保持很高的幀速率，那肯定不希望啟動(dòng)垃圾收集。

Go 和 Rust 有一定的可能性

我認(rèn)為，第一個(gè)真正有可能替代 C 和 C++ 的現(xiàn)代編程語(yǔ)言是 Go 和 Rust。我們看到許多過(guò)去用 C 或 C++ 編寫(xiě)的工具如今都改成了用 Go 或 Rust 編寫(xiě)。比如大量的命令行工具都用這些語(yǔ)言編寫(xiě)出來(lái)了。有些人甚至在嘗試用Rust 編寫(xiě)游戲引擎。

LLVM：填補(bǔ)空白

我認(rèn)為有可能出現(xiàn) C 語(yǔ)言替代品的一個(gè)主要原因是LLVM 的成熟。LLVM 意味著生成高性能的代碼、支持多平臺(tái)的難題得到了解決。LLVM 為更多人提供了嘗試語(yǔ)言開(kāi)發(fā)的機(jī)會(huì)。 Go 和 Rust 提供了一些啟發(fā)，讓我們重新思考 C / C++，在這些啟發(fā)的帶動(dòng)下，再加上 LLVM 助陣，很多人都躍躍欲試尋找 C 語(yǔ)言的替代品：

Zig：一門開(kāi)源的編程語(yǔ)言，專為穩(wěn)定性、可維護(hù)性和最優(yōu)性而設(shè)計(jì)。

Odin：C 語(yǔ)言的替代品，與 Go 非常相似。

V 語(yǔ)言：另一個(gè)類似于 C 的語(yǔ)言，受到了 Go 和 Rust 的大量啟發(fā)。

什么樣的語(yǔ)言可以替代 C？

如果一門編程語(yǔ)言想要替代 C，首先必須適合 C 語(yǔ)言占主導(dǎo)地位的領(lǐng)域。并非所有類型的語(yǔ)言都能夠滿足這一點(diǎn)。我認(rèn)為能夠替代 C 的語(yǔ)言有以下這些共同點(diǎn)：

能夠重用現(xiàn)有的 C 庫(kù)。Ada、Modula-2 等語(yǔ)言在很大程度上就在這一點(diǎn)上栽了跟頭，因?yàn)槟銦o(wú)法在大型 C 生態(tài)系統(tǒng)中有效使用這兩種編程語(yǔ)言。

建立在已有的知識(shí)和慣例之上。Go 語(yǔ)言很容易上手，因?yàn)楸M管語(yǔ)法有所變化，但 API 和編程的方式與 C 非常相似。

沒(méi)有垃圾回收，或者采用手動(dòng)內(nèi)存管理。在 C語(yǔ)言占主導(dǎo)的領(lǐng)域內(nèi)，你需要嚴(yán)格控制內(nèi)存的使用。在這里領(lǐng)域內(nèi)，垃圾收集派不上用場(chǎng)，這就是 Go 無(wú)法完全代替 C 的原因。

控制可執(zhí)行文件的大小。像 C 一樣，Zig 可以將可執(zhí)行文件壓縮到很小。你無(wú)法在嵌入式等領(lǐng)域使用 Go 語(yǔ)言，因?yàn)檫@些語(yǔ)言生成的可執(zhí)行文件都太大。

系統(tǒng)層面的友好。你需要能夠操縱位和字節(jié)。你需要良好的二進(jìn)制運(yùn)算符和指針。在過(guò)去的幾十年中，許多語(yǔ)言都沒(méi)有合適的指針。Java 為指針帶來(lái)了各種罵名，好在 Go 挽回了一些。

逐步替換 C 代碼。能夠良好地兼容 C 的可執(zhí)行文件。

我們深入討論一下最后一點(diǎn)。如果需要一次性重寫(xiě)整個(gè)程序，那么壓根沒(méi)有人會(huì)考慮替換掉現(xiàn)有的用 C 語(yǔ)言編寫(xiě)的基礎(chǔ)設(shè)施。以我的經(jīng)驗(yàn)來(lái)看，從 Objective-C 過(guò)渡到 Swift 之所以如此簡(jiǎn)單，是因?yàn)槲铱梢砸淮沃貙?xiě)一個(gè)方法，重新編譯，并測(cè)試程序。 使用 Zig 之類的語(yǔ)言，也可以輕松地做到這一點(diǎn)。

總結(jié)

我們應(yīng)該替換掉 C 的原因有很多，而截止到目前仍未換掉的主要原因在于，其他編程語(yǔ)言的重點(diǎn)都放在了別處，而且我們?nèi)鄙俟ぞ摺＿@不是一個(gè)大型組織必須決定做的事情。你需要讓大家都來(lái)嘗試一下。如今在 LLVM 的支持下，在 Go 的啟發(fā)下，我們完全可以替換掉 C。 那么，我個(gè)人是否認(rèn)為 C 將來(lái)會(huì)被替換掉呢？我并沒(méi)有那么期待。這是一個(gè)漫長(zhǎng)的過(guò)程，我們還沒(méi)有明確的贏家。大型組織不會(huì)采用 Zig、Odin、V 或其他編程語(yǔ)言，他們都在等待明確的替代方案出現(xiàn)。 說(shuō)到底，替換掉 C 究竟表示什么意思？時(shí)至今日很多金融機(jī)構(gòu)仍在使用 Cobol，但我們可以說(shuō) Cobol 已被取代了，因?yàn)榻駮r(shí)今日沒(méi)有新項(xiàng)目會(huì)選擇 Cobol。人們都在盡可能遠(yuǎn)離 Cobol。 同樣，大量經(jīng)過(guò)測(cè)試的 C 代碼也不會(huì)被重寫(xiě)。這些代碼會(huì)一直遺留下去。 但是，終有一天，C 語(yǔ)言會(huì)被其他語(yǔ)言所替代，即使是在自己占主導(dǎo)地位的領(lǐng)域中。