與以前的C競爭者(例如C ++，D，Java，C#，Go，Rust和Swift)的比較

從很多方面來說，我整個編程生涯都像是在等待C的替代產(chǎn)品的漫長等待。20年前，盡管我用C ++。 隨著時間的流逝，我了解到C ++是一個復(fù)雜的怪物，無論我讀了多少本書，都永遠無法馴服。

我認(rèn)為Yossi Kreinin和他的C ++常見問題解答(https://yosefk.com/c++fqa/)在總結(jié)我對C ++討厭的各個方面都做得很好。

因此，在成為一名專業(yè)的C ++程序員時，我總是著眼于其他選擇。 第一個有希望的替代品是D。D最初看起來很有前途，但經(jīng)過仔細(xì)檢查，我認(rèn)為D實際上只是一個根本上不好的主意的清理版本。 C ++的主要問題之一是它的接收器語言設(shè)計方法。

當(dāng)用C和Lua實現(xiàn)一個簡單的游戲引擎時，我意識到與C ++相比，同時保留這兩種語言的思路實際上更少了。 它給我?guī)砹藢的重新熱愛。盡管有其所有局限性，C是一種相當(dāng)簡單的語言，可以提供很多控制。

Java和C#在許多方面只是嘗試重新實現(xiàn)C ++。他們可能使事情變得更簡單，但最終卻陷入了虛擬機和90年代面向?qū)ο蟮木幊坛醋髦?。不是說Java或C#不好，其中很多可能與那些支持臃腫的IDE和過度設(shè)計的語言的相關(guān)社區(qū)有關(guān)。

C簡單性的回歸

從Google轉(zhuǎn)到Go是對多余的C ++，D，Java和C#的歡送。Go將我們帶回到了起點，回到了C。Go重新設(shè)想了如果不冒險走C ++道路，C可能會是什么。我們得到的是一種簡單的語言，它修復(fù)了我在C語言中經(jīng)常遇到的許多問題。

但是故事還沒有結(jié)束。 緊隨Go之后，我們得到了Rust。 最初，我認(rèn)為Rust實際上是D應(yīng)該一直以來的目標(biāo)。 對C ++應(yīng)該是什么的真正的重新思考。 Rust保持了低級控制，高級抽象機制和手動內(nèi)存管理，但增加了無與倫比的類型安全性。 一切看起來都太好了，難以置信。

坦率地說，我認(rèn)為是。我記得能夠在兩天內(nèi)用Go編寫一些不錯的程序。朱莉婭，我目前的最愛也有些相似。另一方面，學(xué)習(xí)Rust就像學(xué)習(xí)Haskell。在做任何有用的事情之前，只需了解許多概念和理論即可。

如果C ++教會了我任何東西，那就是要重視簡單性，而Rust不會這樣做。

后來，我從互聯(lián)網(wǎng)上許多Rust用戶的評論中學(xué)到了，Rust重復(fù)了C ++的主要缺點之一。它的編譯時間確實很慢。我認(rèn)為沒有什么比等待C ++編譯破壞我編程的樂趣了。聽起來好像Rust更糟了。那是一個破壞交易的因素。

Swift-我想愛的語言

我20年來一直是蘋果的忠實粉絲。 我很喜歡Cocoa GUI庫，并在沒有iPhone之前就對Objective-C進行了編程，突然，每個人和他們的寵物都在用Objective-C進行編程。

是的，Objective-C有點笨拙，但它的簡單性具有一定的美感。 與C ++不同，它是對C語言的相當(dāng)簡單的補充。 根據(jù)經(jīng)驗，您實際上可以真正快速地教初級開發(fā)人員Objective-C。

因此，Swift的發(fā)布讓我覺得我已經(jīng)達到了編程的必殺技。最終，一種非常現(xiàn)代的語言與Objective-C很好地集成在一起，因此我們?nèi)匀豢梢允褂煤馨舻腁pple庫，例如Cocoa。

Swift從Rust那里借來了很多想法，從很多方面來說，我認(rèn)為我們終于為普通人獲得了Rust?？梢栽谙喈?dāng)短的時間內(nèi)學(xué)會Swift。

但是我在Swift方面的經(jīng)歷好壞參半。 即使在今天，我也仍然無法正確表達語言的問題，因為它似乎可以解決很多問題。

我將iPhone應(yīng)用程序從Objective-C移植到了Swift。 我最好的經(jīng)歷之一是Swift僅僅由于嚴(yán)格的類型系統(tǒng)就發(fā)現(xiàn)了一大堆錯誤，這些系統(tǒng)捕獲了在Objective-C中不可見的問題，而這在編譯時至少是關(guān)于類型的，這是眾所周知的。

與C ++，C#和Java相比，我會說Swift是更好的語言。 Swift幾乎解決了我所有有關(guān)C ++的特定問題。 但是我每次使用Go時都意識到，編寫Go程序比Swift有趣得多。 但是Go的錯誤處理有點糟糕，它重復(fù)了具有空指針的百萬美元錯誤。 Swift避免了這兩個問題。

上次與Julia在一起很長時間后，我回到Swift時，看到Swift的一些問題變得更加清晰：

Swift語法不適合函數(shù)式編程

從Objective-C繼承的Smalltalk啟發(fā)式語法在面向?qū)ο蟮木幊讨泻芎玫毓ぷ?，但是對于函?shù)式編程卻非常糟糕。將函數(shù)用作一等公民時，您無需費心確保參數(shù)名稱正確。

面向?qū)ο蟮木幊毯秃瘮?shù)式編程之間的停戰(zhàn)。Swift試圖為兩個不同的主人服務(wù)，并為此遭受痛苦。在進行非常實用的樣式編程時，您希望您的函數(shù)主要是自由函數(shù)。這些更易于傳遞并在函數(shù)設(shè)置中使用。

但是Swift最終主要是面向OOP人群，將函數(shù)放在方法中。 一旦完成了許多函數(shù)編程，這就會變得很麻煩。

Zig適合編程領(lǐng)域的何處?

因此Swift從來沒有真正成為我最終的通用編程語言。如果我想以更高的抽象級別進行編程，獲得高性能并完成工作，我將選擇Julia。

但這仍然為C之類的替代品留下了未填補的空間。朱莉婭(Julia)不能真正取代C。它吞噬了內(nèi)存，無法產(chǎn)生小的二進制文件，不適合使其他語言可以使用的庫。您不想使用它來創(chuàng)建OS內(nèi)核或進行微控制器編程。

Go和Rust都真的接近于替換C。Go擺脫了使用C的簡單性和使用感。但是它使用垃圾回收并不能完全替代C。與Java相比，在Go中對內(nèi)存使用的更多控制仍然是毫無價值的，因為您可以獲得指針，并且實際上可以創(chuàng)建自己的輔助分配器。

Rust降低了手動的內(nèi)存分配，但是未能復(fù)制C的簡單性和感覺。也許這兩種語言之間是否有什么可以填補的空間?

確實有。 我認(rèn)為這就是Zig。 Zig比Go更復(fù)雜，但比Rust更易于學(xué)習(xí)和使用。

但是，這樣的Zig總結(jié)并不能使語言公正。Zig為表帶來了很多新想法，這很有道理，并且使Zig編碼的體驗非常獨特。但是在深入探討之前，讓我們先看一下基礎(chǔ)知識。

正確掌握基礎(chǔ)知識

如果我們要學(xué)習(xí)另一種類似C的語言，我們將無法重復(fù)C ++最糟糕的情況，例如糟糕的編譯時間。 Zig如何解決這些問題?

我遇到了V編程語言的創(chuàng)建者Alexander Medvednikov進行的測試。這是編譯具有400 K函數(shù)的文件的測試：

• C 5.2秒 gcc測試
• C ++ 1分25秒 g ++ test.cpp
• Zig 10.1秒 Zig build-exe test.zig
• Nim 45秒 nim c test.nim
• Rust 30分鐘 rustc test.rs 后Rust停止
• Swift 在30分鐘的swiftc測試后停止
• D 6分鐘后 segfault dmd test.d
• V 0.6秒 v test v

Rust，Swift和D都失敗了。Medvednikov用更少的行數(shù)對這些語言進行了進一步的測試，Rust再次表現(xiàn)出了最差的預(yù)期。

正如您在列表中所看到的，Zig是最杰出的演員。 盡管很難不注意到V語言會在不到一秒鐘的時間內(nèi)完成所有操作。 這使我想起更詳細(xì)地探索V。 快速掃描表明它可以手動分配內(nèi)存，泛型和可選(必須明確允許使用空指針)。

Zig內(nèi)存分配

如果不進行手動內(nèi)存管理，您將無法使用C語言。進行C風(fēng)格編程的人都希望這樣做。如果我不需要，那么我可以為Julia編程。

Zig沒有提供Rust所提供的那種最高的安全性，但是如果不這樣做，它所獲得的是一個對于初學(xué)者來說更容易掌握和使用的模型。

需要在Zig中分配內(nèi)存的任何內(nèi)容都將分配器作為參數(shù)。 因此Zig非常明確地說明了何時需要內(nèi)存管理。

這是我編寫的一個簡單函數(shù)，它使用32位無符號整數(shù)n并將其拆分為十進制數(shù)字：

fn decimals(alloc: *Allocator, n: u32) !Array(u32) { 
var x = n; 
var digits = Array(u32).init(alloc); 
errdefer digits.deinit(); 
while (x >= 10) { 
try digits.append(x % 10); 
xx = x / 10; 
} 
try digits.append(x); 
return digits; 
} 

請注意，必須使用分配器分配用于保留各個十進制數(shù)字的數(shù)組數(shù)字，該分配器是十進制函數(shù)的參數(shù)。

這就是Zig真正的光芒所在。 確保您不會忘記分配內(nèi)存在C語言中很難。而且很容易以錯誤的位置結(jié)束內(nèi)存。 Zig從Go復(fù)制了延遲概念。 但是除了推遲它還有errdefer。 如果您不了解Go，那么從本質(zhì)上講，延遲是將行或代碼塊的執(zhí)行推遲到函數(shù)退出之前的一種方法。

為什么這么好? 因為它使您可以確保某些代碼得以運行，而不管退出該函數(shù)之前使用了什么復(fù)雜的if-else語句。

errdefer digits.deinit(); 

上面的行與正常的Go延遲有所不同，因為只有在返回錯誤代碼的情況下，它才會執(zhí)行。因此，如果一切正常，那么它將永遠不會運行。

在呼叫站點，我們將使用常規(guī)延遲來確保我們不會忘記釋放分配給數(shù)字的內(nèi)存。

const digits = try decimals(allocator, 4123); 
defer digits.deinit(); 
for (digits.items) |digit| { 
try print("{},", .{digit}); 
} 

從我在Zig玩游戲方面的有限經(jīng)驗，我會說這是一個很好的系統(tǒng)。分配器和defer的結(jié)合使用使您非常清楚要分配和釋放內(nèi)存的位置，同時可以輕松正確地進行分配。

C兼容

許多類C語言的問題是它們無法與C配合使用。這意味著從該語言調(diào)用C函數(shù)應(yīng)該很容易，而從C對該語言調(diào)用函數(shù)應(yīng)該很容易。

此外，您編寫程序的一般方式應(yīng)該與C完全兼容，因此您不必創(chuàng)建較大的C抽象級別。例如。C ++對C語言不是很友好，因為沒有大量包裝就無法在C中使用典型的C ++庫。

但是Zig非常C，因為它沒有暴露C不會得到的奇怪的東西。 結(jié)構(gòu)中沒有vtable(C ++中的虛擬函數(shù)表)。 沒有C知道如何調(diào)用的構(gòu)造函數(shù)或析構(gòu)函數(shù)。 也沒有任何例外，C也會在捕獲方面遇到困難。

從Zig使用C很簡單。 實際上，Zig的創(chuàng)建者會聲稱Zig比C本身更擅長使用C庫。

const c = @cImport({ 
@cDefine("_NO_CRT_STDIO_INLINE", "1"); 
@cInclude("stdio.h"); 
}); 
pub fn main() void { 
_ = c.printf("hello\n"); 
} 

如您所見，Zig解析C頭文件并包含來自C的類型和函數(shù)沒有問題。實際上Zig是完全成熟的C編譯器。您可以根據(jù)需要使用Zig編譯C程序。

同樣，將Zig函數(shù)暴露給C也很容易。這是一個Zig函數(shù)，采用32位整數(shù)并返回32位整數(shù)。

export fn add(a: i32, b: i32) i32 { 
return a + b; 
} 

通過將export放在它的前面，可以使我們與程序鏈接的C代碼可以訪問它。實際上，我們的主要功能是在C代碼部分中定義的，并且使用了Zig中定義的功能。

#include <stdint.h>int32_t add(int32_t a, int32_t b); 
int main(int argc, char **argv) { 
assert(add(42, 1337) == 1379); 
return 0; 
} 

這意味著您可以輕松地開始將較大的C程序的某些部分轉(zhuǎn)換為Zig并繼續(xù)進行編譯。 移植程序時，這是一項非常強大的功能。 過去讓我很容易地從Objective-C移植到Swift的原因是，我可以一次用Swift版本替換一個Objective-C方法，進行編譯并看到一切仍然有效。

實際上，通過允許您自動將C程序轉(zhuǎn)換為Zig代碼，Zig使其變得更加容易。 這是Zig編譯器內(nèi)置的：

$ zig translate-c foobar.c 

當(dāng)然，該代碼不是最佳的，可能有點混亂。但這有點像使用Google翻譯進行自然語言翻譯。這是一個很好的起點，可以節(jié)省大量的體力勞動。您可以稍后自己手動修復(fù)細(xì)節(jié)。

極簡主義

極簡主義首先吸引了很多人使用C編程。 這就是Go正確的事情，并使編程變得很高興。 您可以輕松地將整個程序放在腦子里。

現(xiàn)在，如果您開始閱讀Zig并查看我在這里給您的源代碼示例，它可能看起來很復(fù)雜。 有些語言結(jié)構(gòu)可能看起來很奇怪。 可以很容易地感覺到它是一種復(fù)雜的語言。

因此，弄清Zig不支持的所有事物實際上非常有用：

• 沒有類繼承，例如C ++，Java，Swift等。
• 通過Go之類的接口沒有運行時多態(tài)性。
• 沒有泛型。 您不能像在編譯時檢查的Swift中那樣指定通用接口。
• 沒有函數(shù)重載。您不能多次使用不同的參數(shù)編寫具有相同名稱的函數(shù)。
• 沒有異常拋出。
• 沒有閉包。
• 沒有垃圾收集。
• 沒有用于資源獲取的構(gòu)造函數(shù)和析構(gòu)函數(shù)是初始化(RAII)。

但是，通過巧妙地使用一些核心功能，Zig能夠提供幾乎相同的功能：

• 類型可以在編譯時像對象一樣傳遞。
• 標(biāo)簽工會。在其他編程語言中也稱為求和類型或變體。
• 函數(shù)指針。
• 實數(shù)指針和指針?biāo)阈g(shù)。
• Zig代碼可以在編譯時部分評估。您可以使用comptime關(guān)鍵字將代碼標(biāo)記為在編譯時可執(zhí)行。
• 函數(shù)和類型可以與結(jié)構(gòu)相關(guān)聯(lián)，但不能物理存儲在結(jié)構(gòu)中，因此C代碼不可見。

在Zig中模擬泛型

例如。通過利用在編譯時運行代碼的能力，在Julia中創(chuàng)建了類似于模板的內(nèi)容。洛里斯·克羅(Loris Cro)有一篇很好的文章更詳細(xì)地描述了這一點。我將僅使用該文章中的示例來快速了解該想法。

我們可以定義例如一個稱為LinkedList的函數(shù)，該函數(shù)只能在編譯時調(diào)用，該函數(shù)采用鏈表中元素的類型，然后返回包含以下元素的鏈表類型：

fn LinkedList(comptime T: type) type { 
return struct { 
pub const Node = struct { 
prev: ?*Node = null, next: ?*Node = null, data: T, 
}; 
first: ?*Node = null, last: ?*Node = null, len: usize = 0, 
}; 
} 

這利用了結(jié)構(gòu)可以是匿名的事實。 您不需要給他們起個名字。 但是，此功能需要一點包裝。 注意這一部分：

pub const Node = struct { prev: ?*Node = null, next: ?*Node = null, data: T,}; 

這里有許多Zig特定功能在起作用，需要一些解釋。 在Zig中，可以在定義結(jié)構(gòu)時將值分配給結(jié)構(gòu)成員。 成員可以是在編譯時或運行時存在的字段。 上一個：?* Node = null是結(jié)構(gòu)字段的一個示例，該字段在編譯時存在，但其默認(rèn)值為null。 那瘋狂的*前綴呢?

在Zig中，* Node表示類似于C / C ++的指向Node類型對象的指針。但是，由于Zig除非明確允許，否則不允許指針為null，因此必須添加?。指示指針可以為空。

節(jié)點本身被設(shè)置為周圍匿名結(jié)構(gòu)的字段。 但是，由于將其定義為const，因此僅在編譯時存在。 如果在運行時檢查LinkedList結(jié)構(gòu)的內(nèi)存，則找不到與Node對應(yīng)的區(qū)域。

另外請記住，雖然您可以在編譯時將類型用作任何其他對象，但它們在運行時在Zig中并不存在。 因此，基本上我們在這里所做的就是創(chuàng)建帶有嵌套類型的結(jié)構(gòu)。

讓我使用Loris Cro的示例之一進行更好的解釋。首先，他創(chuàng)建一個包含點的鏈表，并將其分配給僅在編譯時存在的名為PointList的變量：

const PointList = LinkedList(Point); 

然后，我們可以使用此新創(chuàng)建的類型實例化一個空列表。

var my_list = PointList{}; 

我們不需要為first，last和len指定任何初始值，因為它們具有默認(rèn)值。

在這里，我們使用嵌套類型創(chuàng)建一個Node對象來保存我們的點數(shù)據(jù)：

const p = Point{ .x = 0, .y = 2, .z = 8 }; 
var node = PointList.Node{ .data = p }; 
my_list.first = &node; 
my_list.last = &node; 
my_list.len = 1; 

在Zig中模擬接口

盡管Zig沒有類或面向?qū)ο笳Z言之類的接口的關(guān)鍵字，但我們?nèi)匀豢梢詷?gòu)建自己的運行時多態(tài)系統(tǒng)，類似于C程序員多年來所做的那樣。

您只需使用函數(shù)指針定義結(jié)構(gòu)即可。在Unix內(nèi)核中，您看到了類似的操作，可以對任何文件描述符進行通用處理，無論它們是文件，套接字還是管道。

typedef struct _File { 
void (*write)(void *fd, char *data); 
void (*read)(void *fd, char *buffer, int size); 
void (*close)(void *fd); 
} 
File; 

這并不完全是它的定義方式。 我只是從內(nèi)存中做到這一點。 這允許我們做的是為文件，套接字和管道提供不同的打開功能。 但是，由于它們都給了我們File結(jié)構(gòu)，因此其他函數(shù)可以使用其包含的這些函數(shù)指針對此進行操作，從而抽象出底層結(jié)構(gòu)的差異。

在Zig中，我們使用Nathan Michaels在此處更詳細(xì)描述的類似方法。 Zig比C提供了更好的功能，因此您會看到Zig在創(chuàng)建通用迭代器，分配器，讀取器，寫入器以及在Zig中進行更多操作時使用了更多功能。

有人可能會問，為什么不將這類內(nèi)容納入語言呢?如果您曾經(jīng)使用過Lua，那么您將了解一些優(yōu)點，而不是給您構(gòu)造塊以創(chuàng)建面向?qū)ο蟮南到y(tǒng)，而不是對其進行硬接線。

使用Zig，您可以構(gòu)建C ++風(fēng)格的面向?qū)ο蟮南到y(tǒng)，類似于Go甚至是類似于諸如Objective-C之類的更動態(tài)語言的面向?qū)ο缶幊獭?/p>

這種自行開發(fā)的方法可能非常有效。我們已經(jīng)看到LISP程序員使用它來在LISP中構(gòu)建面向?qū)ο蟮木幊滔到y(tǒng)，甚至創(chuàng)建類似于Julia的多調(diào)度系統(tǒng)。