表达能力我能在这门语言中多好地表达自己的想法换句话说用它来表达程序的业务领域有多容易这其实是在测试我在程序中表达想法时会受到多少“噪音”的干扰。这里的“噪音”指的是为了让程序运行而必须编写但与业务领域无关的代码。比如常见的“噪音”就是手动内存管理。为了让程序运行我们必须分配内存但这与程序的业务领域并无直接关联只是一个实现细节。类型系统编程能力这门语言为我提供了哪些工具来创建构造正确的系统我能多轻松地对类型系统进行编程本质上这是在测试我能在多大程度上对语言本身进行编程或者说能多好地创建深度嵌入。意外出现的平均时间在真空系统比如外太空的研究中有一个概念叫“平均自由程长度”简称“平均自由程”。真空系统的“平均自由程”是指一个粒子在系统中不发生碰撞所能移动的平均距离它本质上是衡量真空质量的一个指标。当我把这个概念应用到编程语言上时我把它理解为“在我的实现与我对所实现系统的理解出现偏差之前我能写多少代码”。这就是我把这个指标称为“意外”的原因即“我写多少行代码才会遇到意外情况”。这里的“意外”指的是我认为自己实现的内容与实际实现的内容之间的差异。对 Zig 感兴趣的原因现在来谈谈 Zig。我对 Zig 感兴趣主要有以下几个原因。首先我觉得编译时comptime是一个更简单、更灵活的系统能实现很多我在 Haskell 生态中看到的类型系统编程。我有超过 10 年的 Haskell 使用经验对我来说能够对类型系统进行编程是认真对待一门语言的必要条件。其次我非常想避免编写函数式系统语言。这可能值得单独写一篇博客但编程语言行业还没有真正理解 monad 的含义。Monad 并不是只有高智商人群才认为必要的晦涩数学概念。实际上monad 是对命令式编程作为计算上下文的一种基本抽象代数描述。它让编程语言可以没有内置的时间概念还有其他好处。所以如果我想要一门命令式编程语言我可以实现 MonadCont延续 monad如果我想要一门逻辑编程语言我可以实现 LogicT一种具有非确定性语义和回溯功能的 monad。没有内置的时间概念意味着我的语言实际上更具表达力能让用户根据自己的需求塑造语言还能提高该语言编译器的优化上限。与系统编程的关系我已经转变了观念。我学习了足够多的面向性能的编程知识对常见的函数式语言如 Haskell、OCaml、Common Lisp/Clojure、Scheme感到不满因为这些语言都依赖于垃圾回收和堆。我认为我们对垃圾回收的大规模实验已经接近尾声。回顾过去 30 年我们可以得出结论垃圾回收通过减少“噪音”确实带来了巨大的价值但代价是程序中会出现大量指向堆的指针这会给程序和语言实现带来性能上限。更糟糕的是我认为垃圾回收存在认知风险。它让开发者太容易不去思考或关心底层的机器和运行时系统。这导致了一代开发者从未掌握或已经失去了程序在计算机上实际执行方式的知识。或者用更直白的话说看看垃圾回收器带来的软件时代就知道了。与运行它们的超级计算机相比程序变得臃肿、缓慢且浪费资源。我们肯定能做得更好。此外我认为垃圾回收器的价值主张已经发生了变化。第一个垃圾回收器于 1957 年在 LISP 中被发明1995 年随着 Java 的兴起而变得流行这是有原因的。然而2026 年的计算机与 1995 年的计算机大不相同但我们的语言却没有跟上。自 1995 年以来CPU 的计算速度提高了约 10000 倍而内存访问时间却滞后了。1995 年并非如此那时两者大致相当。所以我们现在使用的是为过去的计算机设计的语言而没有考虑到现在的计算机。作为一个行业我们在很大程度上已经停止了对新语言的创新。我曾经看过 Steven Diehl 的一个演讲题目是[下一门编程语言将从何而来](https://web.archive.org/web/20220325175116/http://dev.stephendiehl.com/nearfuture.pdf)它很好地描述了当前的糟糕状况。他的主要观点是编程语言创新的激励机制要么严重失调要么根本不存在。他指出我们可以认为有三类人有能力进行创新学术界、工业界和爱好者。但学术界没有动力去进行使一门编程语言可行所需的实际工程工作任何尝试这样做的学者都相当于自毁前程。工业界由于追求股东价值最大化的文化无法资助任何长期项目而且还受到粘性网络效应的束缚。爱好者通常既没有时间也没有经济能力去实现真正有价值的东西因为这需要数十年的全职工作才能完成。所以我们陷入了局部最优解。Zig 的创新之处现在回到 Zig。我看好 Zig因为 Zig 及其仁慈的独裁者 [Andrew Kelley](https://andrewkelley.me/) 正在进行创新而且有勇气去创新。以下是一些创新之处。Zig 不鼓励使用大量指针的方式而是通过竞技场Arenas和分配器Allocators来鼓励更好的手动内存管理。这意味着用户对程序的内存管理有更多的控制权。这就是用 Zig 编写的程序如此快速的原因之一Zig 程序往往能更好地利用现代计算机而不是过去的计算机。[Zig 0.16](https://ziglang.org/download/0.16.0/release-notes.html) 刚刚发布并将 IO 系统重新设计为接口设计以下是发布说明中的示例const std import(std);const Io std.Io;pub fn main(init: std.process.Init) !void { const gpa init.gpa; const io init.io; const args try init.minimal.args.toSlice(init.arena.allocator()); const host_name: Io.net.HostName try .init(args[1]); var http_client: std.http.Client .{ .allocator gpa, .io io }; defer http_client.deinit(); ...}当我看到这段代码时我看到 http_client 存在于一个包含分配器和 IO 接口的 Reader monad 中。这与 Haskell 中的 IO monad以及 IO#的工作方式完全一样。Zig 团队能独立想出这个不仅说明了 monad以及编程语言的代数结构的普遍性也表明他们走在了正确的道路上。为这个团队点赞我甚至在 Hacker News 上[提到](https://news.ycombinator.com/item?id46123083)了这一点引发了一场有趣的讨论感兴趣的人可以去看看。编译时comptime示例我的最后一个例子是编译时comptime。前面提到我希望能够创建构造正确的程序这意味着我需要名义类型就像 Haskell 中的 newtype。在 Zig 中它只是一个单例结构体struct PlayerHealth { health: u32}不错那么和类型sum type呢很简单就是一个联合体unionconst std import(std);// 经典的 Maybe 类型即使 Zig 有内置的语法fn Maybe(comptime T: type) type { return union(enum) { value: T, nothing, const Self This(); pub fn just(the_val: T) Self { return .{ .value the_val }; } pub fn nothing() Self { return .nothing; } // 这是 fmap展示了类似 Haskell 的 case 表达式 // map :: Maybe(T) - Maybe(B) pub fn map(self: Self, comptime B: type, f: fn (T) B) Maybe(B) { return switch (self) { .value |v| .{ .value f(v) }, // Just 情况 .nothing .nothing, }; } };}非常好那类型类typeclasses呢同样编译时comptime和结构体structs是关键const std import(std);// 这是class Eq where ...fn Eq(comptime T: type) type { // 注意我们不仅可以在编译时编程还可以编写自己的错误消息而且语言鼓励我们这样做 if (!hasDecl(T, eql)) // 这表示 T 必须有一个 eql 方法 compileError(typeName(T) must implement eql(T, T) bool); return struct { pub fn eql(a: T, b: T) bool { return T.eql(a, b); } pub fn neq(a: T, b: T) bool { return !T.eql(a, b); } };}// 用户定义的类型const Point struct { x: i32, y: i32, // instance Eq Point where ... pub fn eql(a: Point, b: Point) bool { return a.x b.x and a.y b.y; }};// 现在使用它pub fn main() void { const EqPoint Eq(Point); const a Point{ .x 1, .y 2 }; const b Point{ .x 1, .y 2 }; const c Point{ .x 3, .y 4 }; std.debug.print(a c: {}\n, .{EqPoint.eql(a, c)}); // false std.debug.print(a b: {}\n, .{EqPoint.eql(a, b)}); // true}你会注意到这有点繁琐我们必须实例化一个 Eq(Point)然后调用 EqPoint.eql。EqPoint 本质上就是 Haskell 在幕后创建的类型类字典所以在 Zig 中我们必须手动传递这个字典。好处是这符合 Zig 的“无远距离幽灵行为”哲学类型类字典传递就是一种远距离幽灵行为。但我们可以通过在 Point 类型上派生 Eq 来让它更方便const std import(std);fn EqClass(comptime T: type) type { if (!hasDecl(T, eqlImpl)) // 现在我们验证是否有实例实现 compileError(typeName(T) must implement eqlImpl(T, T) bool); return struct { // 这些函数只是包装了 T 提供的实现 pub fn eql(a: T, b: T) bool { return T.eqlImpl(a, b); } pub fn neq(a: T, b: T) bool { return !T.eqlImpl(a, b); } };}const Point struct { x: i32, y: i32, // 实际实现这是实例中 () 的主体 pub fn eqlImpl(a: Point, b: Point) bool { return a.x b.x and a.y b.y; } // 派生 Eq: EqClass 读取上面的 eqlImpl所以我们不会创建循环 pub const Eq EqClass(This());};pub fn main() void { const a Point{ .x 1, .y 2 }; const b Point{ .x 1, .y 2 }; const c Point{ .x 3, .y 4 }; std.debug.print(a c: {}\n, .{Point.Eq.eql(a, c)}); // false std.debug.print(a b: {}\n, .{Point.Eq.eql(a, b)}); // true std.debug.print(a ! c: {}\n, .{Point.Eq.neq(a, c)}); // true}还不错。当然它不如 Haskell 方便但我认为这是件好事。实际上我仔细观察后发现它背后似乎隐藏着类似 ML 模块系统的东西。我还可以继续说下去。实际上在 Zig 中你可以使用结构体来创建闭包、进行柯里化从而编写高阶函数而且不需要垃圾回收器如果你感兴趣可以看看标准库的[排序函数](https://codeberg.org/ziglang/zig/src/commit/ce198b7c28e89c0bb502d215f9f9de99abb25f08/lib/std/sort/pdq.zig#L15)。但我会留到另一篇文章再讲。看好 Zig 的原因不用说我非常看好 Zig。我认为 Zig 有很多优点。Zig 具备我简洁表达业务领域和想法所需的能力这是我最初标准中的第一点。Zig 的编译时comptime对类型系统编程和创建构造正确的程序有很好的支持。我还需要更多地进行实验但我认为它至少与 Haskell 处于同一水平而且编程起来更容易这是第二点。最后Zig 的“无远距离幽灵行为”意味着在我的实验中我从未对其语义感到意外。我相信肯定会有一些边缘情况但我可以自信地说与经常与之比较的语言如 Rust、C相比Zig 的平均自由程更长。我热爱 Haskell在过去 10 - 13 年里它一直是我的首选语言但我看到未来会有很多 Zig 的应用。