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

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

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

微控制器

視頻編解碼器

底層共享庫，例如 OpenSSL 等

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

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

Go 和 Rust 有一定的可能性

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

LLVM：填補(bǔ)空白

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

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

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

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

什么樣的語言可以替代 C？

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

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

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

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

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

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

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

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

總結(jié)

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