編譯丨諾亞
新語言的出現，真的能威脅到老牌語言嗎？或許，真的沒有永遠的王者。就像最近春風得意的Mojo，LLVM之父Chris Lattner稱其不會威脅到 Python，但會讓C++等語言感到恐懼。
新語言層出不窮之時，舊語言的中年危機就會愈發凸顯。但像C++、C好似一直穩坐釣魚台，「一直被唱衰，但從未被打倒」。
但總會有新的挑戰者，比如Zig、Go躍躍欲試，試圖取代這個編程老祖。而且許多新語言的使用者也會幡然相信：C，或許真的需要進化了！
本篇文章具體解釋了目前在所有C的替代品中，Zig為什麼是最好的，以及Zig本身已經有了可行的替代C的計劃，諸君不妨一探究竟。
1、C那麼牛，為什麼會有許多替代品？
誠然，C傲視群雄的資本還是有目共睹的，畢竟這門編程老祖之所以如此霸氣，是因為它是每個現代軟體系統組件的創造者。開發人員用C語言製作web伺服器、資料庫、作業系統、框架、程式語言、雲組件和許多軟體組件。儘管許多程式語言都說它們可以「取代」C語言，但這是不可能的，因為整個計算機歷史都是用C語言創造的。
但資格老的語言總是不太能跟上「現代開發」的腳步。C++語言通過實現面向對象的概念、生產語言特性和通過保持C語言的性能優先設計的標準庫API，為現代開發人員改進了C語言語法。也有一些C替代方案可以解決每個C開發人員面臨的問題。Zig、D、Go和Odin是流行的C語言替代品。
Zig展示了一個充滿希望的未來，有一個內置的包管理器、一個構建系統、類似C但更好的語言語法、一個功能齊全的標準庫和一個不斷增長的社區。像Uber這樣的大企業也開始使用Zig工具鏈進行交叉編譯。此外，一些軟體公司開始使用基於Zig的代碼存儲庫開展業務。我將用這個故事解釋Zig如何成為C語言的最佳選擇。
2、為什麼Zig只能替代C，而不是C++
系統編程通常指的是開發更接近計算機硬體或作業系統層的東西。系統編程通常實現可以運行其他軟體系統的軟體模塊。編寫作業系統、應用程式框架和嵌入式系統是系統編程的好例子。系統程式設計師主要有兩種語言類型選擇:
- C 及其替代方案：使用小型的高性能語言，如傳統的 C、Go、Zig 或 Nim。
- C++及其替代方案：使用有點複雜、高性能的語言，如傳統的C++、Rust、Carbon 或 Cppfront。
Zig屬於第一種語言。它是一種小型的、類似C語言的高性能語言，沒有專用的運行時(沒有內置的垃圾收集器)。Zig試圖通過解決C開發人員面臨的問題來成為「更好的C語言」，而Rust試圖成為「更好的C++」語言。
3、Zig 如何成為最好的 C 替代品？
C語言現在有一個標準規範，也有了幾個實現。例如，你可以在GNU/Linux系統上使用GNU C編譯器，在macOS上使用Apple Clang，在Windows上使用MSVC。C也有多個標準庫實現，如libc、Microsoft C運行庫、BSD libc、musl、Bionic等。
一個編譯器實現和一個基本的標準庫是不足以高效地構建軟體系統的——C程式設計師需要使用構建系統、包管理器、測試運行器等。對於這些工具，他們要麼必須使用現有的第三方工具，要麼編寫自己的工具(如BuildZri構建系統)。
Zig提供了一個內置的構建系統、包管理器和測試運行器。Zig通過為C開發人員經常面臨的問題提供解決方案來與C競爭。例如，Zig的官方編譯器支持交叉編譯，並且內置的測試運行器可以執行放在原始碼本身內部的測試用例。Zig的語言設計傾向於通過維護類似C的硬體友好設計來提供更高效的開發人員友好特性。Zig是硬體友好的，但它是最小的、安全的、語法上類似Rust的和現代的。因此，開發人員可以比C更高效地使用它。
看看下面這些簡單的Zig代碼片段，來理解Zig未來的、硬體友好的語言概念：
複製
const std = @import("std");
pub fn main() void {
var nums = [_]u8{1, 2, 4, 5, 120};
var x: usize = 3;
var nums_seg = nums[1..x];
std.debug.print("{any}\n", .{nums_seg}); // { 2, 4 }
std.debug.print("{}\n", .{@TypeOf(nums_seg)}); // []u8 (slice)
}
Zig不像C語言那樣使用預處理器或宏系統來處理導入——它使用類似nodejs的模塊導入語法和內置的@import函數。這裡，我們使用u8基本類型創建了一個無符號位元組大小的整數數組。然後，我們使用Zig切片概念從數組創建一個切片。正如你所看到的，Zig提供了一個類似於C的硬體友好的原子類型系統，但是它使用更好的標準化、自解釋的命名來改進它們，而不像c中那樣使用char、short、long等。
C通常要求程式設計師自己保護他們的程序，但是Zig實現了嚴格的內存安全特性。嘗試將256添加到上面的位元組數組。如果你用C語言做這個實驗，程序會靜默地存儲一個不正確的值。在Zig中，你會得到一個編譯錯誤，因為255是無符號位元組類型可以表示的最大值:
Zig 編譯器顯示的整數溢出檢查，作者的螢幕截圖
Zig的內置測試運行器和單元測試API允許你在源文件中編寫測試:
複製
const std = @import("std");
fn add(a: i8, b: i8) i8 {
return a + b;
}
test "add returns the summation" {
try std.testing.expectEqual(add(10, 5), 15);
}
我從未在其他流行語言中見過像Zig這樣高效的C-互操作。大多數語言使用FFI(外部函數接口)來實現C-互操作，但是Zig允許你調用C，甚至不需要在Zig範圍內定義C函數。當你導入C頭文件時，它會自動創建結構類型:
複製
const std = @import("std");
const c = @cImport({
@cInclude("stdio.h");
});
pub fn main() void {
var a: u8 = 10;
var char_count = c.printf("a = %d\n", a); // a = 10
std.debug.print("{}\n", .{@TypeOf(char_count)}); // c_int
std.debug.print("{}\n", .{char_count}); // 7
}
如上面的代碼片段所示，Zig允許你像調用本地Zig函數一樣調用C函數，但是使用自定義前綴(經常使用C)。
Zig沒有提供一個內置的字符串類型，但是它允許你通過一個類似C語言的、低級的、基於字符數組的字符串處理概念和有用的快捷方式來處理字符串：
複製
std.debug.print("{s}\n", .{"Zig" ++ "Lang"}); // ZigLang (concatenation)
std.debug.print("{s}\n", .{"Zig" ** 5}); // ZigZigZigZigZig (repetition)
std.debug.print("{}\n", .{@TypeOf("string")}); // *const [6:0]u8 (a pointer to an unsigned byte array)
Zig語言更接近硬體層，但它實現了各種快捷方式和現代語言概念(即，切片、內置函數、循環簡寫等)，為系統編程提供了一種高效的語言。其功能齊全的模塊化標準庫幫助Zig超越了系統編程。它為你提供了你在通用程式語言中尋求的控制結構、數據結構和基本算法，這也非常適合系統編程。
Zig工具鏈的特性，如交叉編譯和構建系統API，激勵程式設計師在現代系統編程中選擇Zig而不是C！對於現有的C代碼庫，Zig工具鏈提供了一個可替換的C/ C++編譯器和C互操作，因此程式設計師可以將傳統的C代碼庫增量地遷移到現代的Zig。
4、Zig語言和工具鏈的突出特點
我們討論了一些突出的Zig語言/工具鏈事實，並了解了它如何以成為「更好的C」語言為目標。許多Zig特性促使我們選擇它作為系統編程的C替代方案。
看看以下突出顯示的功能總結:
- Zig提供的不僅僅是一種簡單的語言——它是一個功能齊全的工具鏈，用於開發、測試、構建和發布系統編程項目
- 它的開發人員友好的CLI可以立即支撐可執行和共享庫項目。
- Zig允許您調用C，但它不依賴於C——libc是Zig二進位文件的可選組件。
- Zig沒有專用的運行時，因為它沒有自動垃圾收集器——所以它可以生成快速、輕量級的二進位文件。
- 儘管Zig通常是一種中級語言，但它提供了現代的通用特性，如異步編程語法、泛型和類型強制轉換(自動和手動)。
- Zig工具鏈可以通過交叉編譯來編譯C/ C++，因此您可以在使用Zig語言之前使用它的C/ C++編譯器來構建現有的C代碼庫。
- 一個編寫良好的、模塊化的、功能齊全的標準庫，包括跨平台的作業系統級api，如Python。
- 它提供了生產力優先的語言特性，而不會損害硬體友好的系統編程環境，例如，for-in循環、多個切換用例(切換範圍)、內聯for、切換語句等。
- 它附帶了基於流行的C編程模式的基於枚舉的錯誤處理方法，沒有複雜的、容易出錯的異常概念。
- 它允許您通過分配器概念和defer關鍵字進行手動內存管理。
5、具有長期計劃的替代方案
到目前為止，我們已經討論了如何通過語言和工具鏈特性使Zig成為更好的C替代方案。性能如何?它的性能比C好嗎?
所有沒有專用運行時的語言，如C、C++、Rust和Zig，都會從用特定語言編寫的每個原始碼生成原始彙編，因此系統程式語言的性能取決於二進位文件中彙編代碼的質量。系統程式語言的編譯器要麼使用LLVM優化，要麼使用它們自己的成熟優化，因此很難說哪種語言更快——系統編程性能通常取決於程式設計師編寫的算法。
然而，Zig官方文檔聲稱，由於基於llvm的優化和增強的未定義行為，Zig比C運行得更快。此外，Zig還計劃通過移除作為依賴項的LLVM來進一步改進Zig。Zig軟體基金會(ZSF)積極維護該項目，並接受來自社區的新設計建議。
Zig充滿希望的未來使它成為最好的C語言替代品，甚至促使C程式設計師將他們現有的代碼庫遷移到現代的Zig。
6、結語
在這個故事中，我們討論了Zig如何通過提供小型的、開發人員友好的、硬體友好的、高效的、高性能的和安全的語言設計，成為「更好的C」語言。改進的語言設計和工具鏈幫助Zig在使用C的用例中表現良好，例如構建作業系統、庫、雲計算模塊和框架。此外，其未來的語言功能甚至可以與流行的Go語言競爭!
儘管Zig或任何其他未來的系統程式語言永遠不會「取代」C/C++，但隨著現代化進程的加速，Zig已經成為有史以來最好的C語言替代品之一。