编程语言研究书库
Zig 系统编程(MEAP)

四个设计决策 — 编译器当教练、comptime、分配器范式、构建不是事后事

四个设计决策 — 编译器当教练、comptime、分配器范式、构建不是事后事

这一章讲什么: 1.3 节是原书第 1 章的心脏。它回答「Zig 凭什么让程序员写出 更好的软件」——答案是四个连环决策:让编译器当教练、把代码生成统一成 comptime、 把内存管理变成可插拔接口、把构建当成正经工程。 读完你会拿到一套可以拿去评任何语言的检查表:一门语言说「我重视可靠性」时, 挨个问它这四个问题,就知道它认真到什么程度。

1. 这一章讲什么

作者这一节的组织方式很特别:不从语言特性出发,从「谁在受益」出发。 他的推理是:Zig 的第一优先级是让终端用户的日子更好过;软件只有在服务受众时才算好; 所以倒推出——要给程序员最好的工具1。

工具具体指什么?作者把 Zig 比作「用全世界编程语言设计里最好的想法炖成的一锅炖菜」2, 这锅菜里有四样主料,本章逐个讲:

  1. 一组「讨人嫌」的编译器检查(新手的公敌,作者的挚爱);
  2. comptime:编译期执行,顶替泛型 + 宏 + 代码生成;
  3. 分配器范式:手动管内存,但管法可以换;
  4. 构建系统:密封、跨平台、缓存、去中心化包管理。

2. 顶层全景:一张「为谁好」的因果图

  终端用户受了软件的苦(崩溃、慢、行为诡异)
      │
      ├─ 追根:苦多半是「歧义」变的——语言允许含糊,含糊迟早变成 bug
      │
      ├─ 对策 ①:编译器当场拦下歧义(静态检查,发布时零开销)
      │     对策 ②:生成代码交给 comptime,别让人手写样板
      │     对策 ③:内存怎么管,显式传接口进来
      │     对策 ④:构建可复现,别在「依赖地狱」里浪费时间
      │
      └─ 结果:程序员把时间花在「软件真正干什么」上 → 用户拿到的东西变好

  图说:作者把「开发者体验」当手段、「用户体验」当目的——这个顺序他自己明说。

3. 核心原理

3.1 编译器当教练:五条规定

作者先交代自己的心路:这些规则正是 Zig 新手最讨厌的那批—— 「它明明懂我的意思,为什么不让过编译?」——但他的恼火「很快变成了思考, 然后变成了更好的代码」3。

五条规定,每条配一个它拦下的灾难:

第 ① 条:不许留没用的东西。 未使用的变量和参数不允许存在, 除非你显式写明丢弃(_ = x;);反过来,丢弃一个其实被用到的变量也不许。 编译器还会砍掉它找得到的所有死代码;你可以显式告诉它某个分支不可达(unreachable), 甚至可以自己制造编译错误,让协作者和未来的你立刻明白「为什么这个改动 激活了一条本来不可能的代码路径」4。

第 ② 条:变量不许比必要的更可变。 变量只能声明成 const(之后不能重新赋值) 或 var;const 被改是错误,var 从头到尾没被改,也是错误5。 从声明那一行起,读代码的人就知道这个量会不会变——这是阅读和调试时的巨大提示。 书里还补了一句笔记:const 多的代码恰好对编译器极友好,这是 Zig 代码能 在性能上赢过地道 C 代码的一个途径6。

第 ③ 条:错误不许被忽略。 错误和返回值必须被处理或显式丢弃—— 「Zig 就是不允许你忽略错误」7。函数还能声明自己可能返回的全部错误, 编译器据此检查你对「这段代码会怎么失败」的假设。这一条同时防两种别家常见的痛: C 的错误码没人查、高级语言的异常不知从哪里飞来。

第 ④ 条:类型转换不许含糊。 数值类型之间的操作极其挑剔: 想把布尔当整数用、把整数转成浮点,都必须显式声明,通常用内建函数8。 这逼着程序员想清楚「这段数据到底该用什么类型」,也堵死了宽松类型系统里 一整类「转换出乎意料、或悄悄改了数据」的 bug。

第 ⑤ 条(总账):歧义就是技术债。 上面四条的共同名字,作者写作 「AMBIGUITY IS TECHNICAL DEBT」9:所有静态检查都是为了在歧义变成 用户可见的 bug 之前,强迫程序员处理它。并且这些检查在 release 编译时 「不带来任何运行期开销」10。

这一章的主线例子,就是这段三行小程序过五道关卡—— 它每一节都会回来一次:

// 我们故意写坏的三行程序
pub fn main() !void {
    const limit: i32 = 10;
    var count: i32 = 0;
    count = count + 1;
    // ……后面还有很多代码,但从这三行已经能演完全部五条规定
}
  第 ① 道关卡 limit:程序后面再没用过它
      → 编译错误:unused local variable
      → 修法二选一:删掉,或写明 _ = limit;(「我是故意的」)
  第 ② 道关卡 limit 其实从没被改过
      → 编译错误:never mutated,建议改成 const
      → 也就是说:const 和 var 写反了,两头都报错
  第 ③ 道关卡 假设 count = count + 1 那一行换成可能失败的文件写入
      → 返回类型里不写「可能失败」:编译不过
      → 写了「可能失败」却不去处理:也编译不过
  第 ④ 道关卡 假设换成 count = count + 1.5(给整数加浮点)
      → 编译错误:不允许含糊的类型转换
      → 必须显式声明:你是想取整?想转浮点?溢出怎么办?
  第 ⑤ 道关卡 全部改对之后,release 编译
      → 这些检查不产生任何运行期开销

  图说:每一道关卡拦的都是「程序员的含糊」,不是「程序的表达」。
  代码框架照原书 2.1 节的清单改写,报错措辞是概念示意,不是逐字引用。

3.2 Do it at comptime:一种机制顶替四样工具

先讲病。 作者说野外的大量代码在浪费时间:给用户白烧 CPU、 给程序员逼出不必要的样板(boilerplate,为凑语言要求而重复的模板代码)、 给评审者制造混乱11。

再盘点别家的药,以及它们的边界。 元编程(让代码生成代码的技术)各家都有, 但都是补丁摞补丁:C/C++/Rust 有宏(在代码被解析——被编译器读成它能处理的结构——之前改写它; Rust 的宏语法精致得多);Rust 和 C++ 有初级的常量函数求值; C++ 模板和 Rust 类型系统能造泛型,但程序员常被「长篇小说式的编译错误」折磨; Lisp/Python/Ruby 这类解释型语言想怎么改写代码都行,代价是一切都在运行期发生12。

然后给最重的证据:Chromium。 谷歌 Chrome 的地基、世界上用得最广的浏览器引擎, 在 C++ 的元编程不够用的时候,用 Python 脚本生成 C++ 代码; 它同时也以「构建困难」传奇闻名——作者谨慎地说「我不是说这些脚本是唯一原因, 但这是一个刺眼的例子」13。

最后给 Zig 的药。 comptime 让程序员在编译期运行几乎任意的代码14。 别家分开提供的四样东西——泛型、宏、代码生成脚本、常量函数和表达式—— comptime 一个机制全部顶替,而且几乎不加新语法15。 作者称这是「一个真正的范式转变」16,理由在括号里:它发生在 「一门低级的、静态的、强类型的系统编程语言」里——这个位置此前被认为 不可能装下这种自由。

为什么有效? 因为编译器反正已经在编译期执行你的部分代码了(算常量、展开类型), Zig 只是把这件事的权限完整放开:能跑的代码,就能在编译期跑,用它的结果生成机器码。 (第 09 篇有一个完整走通的例子:缓冲区大小变成编译选项,代码里 [options.reader_buffer_size]u8 这种「类型里套变量」的写法靠的就是它。)

3.3 Memory is a resource:分配器范式

起点:作者不交出一个默认答案。 「程序碰过的每个字节都得存在某个地方」, Zig 假定你知道你的数据该存哪、生命周期怎么管——这和 C 的 malloc/free (运行时向系统要内存的函数/还回内存的函数)一个路子, 但多给了「管理内存的那套数据结构本身」的访问权17。

核心对比:一张五行表。 作者用一张表把五种内存管理策略摆在一起18:

策略它放弃什么它得到什么
全世界暂停的垃圾回收(GC)执行中不可预料的停顿;追踪每次分配的开销;默认对缓存不友好;可能循环引用;几乎无法控制内存不用规划,开发周期快
引用计数的 GC每次分配的小开销;默认对缓存不友好;仍可能循环引用无停顿、运行特征平稳,常对多线程友好
静态分析(Rust 及研究语言)代码要精心设计,避开编译器证不出安全的情况;仍可能泄漏;生命周期要逐个对象想编译器能 largely 保证内存安全;无直接性能开销
C 式 malloc/free繁琐;无护栏;极易泄漏或引用已失效内存;实践中失败常被无视每次分配的细粒度控制;无性能开销
Zig 的分配器安全要靠测试来验;哪怕最简单的代码也必须显式给出分配器C 式手管的全部好处 + 显式生命周期 + 安全模式有护栏 + 策略可叠可换 + 分配失败可优雅恢复19

怎么读这张表。 注意最后一行的「缺点」列里藏着整个范式: 「最简单的代码也必须显式定义分配器」——在 Zig 里,readFileAlloc(ally, …) 这类函数全都把分配器当参数收进来,而不是自己偷偷去要内存。 所以你的代码接什么分配器,取决于你现在在干什么:调试时接会记录每次分配来历的, 上线时接最快的,单片机上接从固定内存块里抠的。

判断(我们的,不是书里的): 这张表是全书被低估的一段。 它难得地把「GC 拥护者」和「手动管理拥护者」各写的半页优点都承认了, 然后指出两边的真正分歧不在「哪边对」,而在**「决定权住在哪」: GC 把决定权交给运行时,Rust 把决定权交给编译器的证明能力, malloc/free 把决定权交给程序员但不给他工具, 分配器范式把决定权交给程序员并给他工具**。 这个「决定权住在哪」的视角,比表本身耐用得多。 如果错,会错在: 它省略了「决定权的代价」这一列—— 显式传分配器意味着所有库的接口都要多一个参数, 这个传染成本书里轻描淡写(第 3 章的 cat 会亲身演示)。

3.4 Building is not an afterthought:构建不是事后事

这一小节把「构建」从杂活提升为语言设计的一部分,给了四样东西:

① 编译器本身够快。 作者引用 Zig 创始人 Andrew Kelley 2021 年的演讲: Zig 编译器在普通消费级硬件上每秒能生成 890 万行代码的中间产物20, 风格是 performance-first、data-oriented(数据导向:围绕数据怎么在内存里排 来组织程序,而不是围绕代码流程)。 顺手他立了个 flag:「我也会教你应用其中一些数据导向的原则」21。

② 密封(hermetic)构建。 书里的定义:同样的输入,在任何机器上 都产出同样的输出22。落到事实上:同一平台产出逐字节相同的二进制; 用包管理器和跨平台标准库 API,大多数场景不需要为平台改代码; 发布就是「为每个目标各编一次,用户下载一个文件」23。

③ 缓存让改-跑循环快得离谱。 因为构建过程每一步都可靠(密封), 每一步都能缓存——重编译永远只花最少必要的时间24。

④ 去中心化的包管理。 不搞中央包数据库, 一个 tarball 的 URI(网址那类地址)就够; 依赖放在 GitHub/GitLab 上就天然是 Zig 包。

包永远锁在同一个源码哈希上——哈希是把源码整个算成一个指纹, 内容变,指纹就变——直到你手动更新:「你拉取的代码有任何变化, 都是明确被想要的」25。

收尾是一声感叹:Zig 让程序员「停止妥协」,告别「依赖地狱、配容器、 学第 13 种构建脚本语言」26。

4. 作者的判断与证据

判断是书里给的证据,还是作者的推测
这些静态检查能拦住「歧义变成用户可见的 bug」信念 + 机制论证,没有数据(多少 bug 是被这类检查拦下的,书里没有数字)
const 多的代码对编译器友好、能赢过地道 C书中注记一句带过,无测量
comptime 顶替泛型/宏/代码生成,代码「更优化也更可读」立场断言,Chromium 是旁证(别家真的在用脚本生成代码),但没有对照实验
分配器范式最大化控制与显式设计陈述;「安全要靠测试来验」是作者自己写进缺点列的,这点诚实
编译器每秒 890 万行中间代码有出处的事实(Kelley 2021 演讲,书里给了链接),但这是 2021 年的数字
告别依赖地狱修辞;去中心化包管理的取舍(没有中央仓库意味着发现性、审计性都弱)没有讨论

5. 边界与局限

  • 「发布时零开销」有一个隐含前提:所有检查都只在 Debug 模式下开着。 也就是说「安全」和「快」在 Zig 里是编译档位的事——ReleaseFast 下越界访问、 整数溢出都不再拦。这一点 3.4 节的优化档表会说透,但 1.3 节没提前讲。
  • 分配器范式的传染成本未量化:每个需要堆内存的函数都要多收一个参数, 整个库的接口形状都被它改变。
  • comptime 的风险本节只字未提:编译期执行的代码会把编译变慢、 把错误信息变复杂——这些要到用它的时候才会撞见。
  • **包管理「锁哈希」**防的是「依赖悄悄变」,防不了「依赖作者删库」—— URI 指向的 tarball 没了怎么办,本节没有答案。

6. 可带走的

  1. 「开发者体验是手段,用户体验是目的」——这一节的价值排序,作者自己明说;
  2. 五条规定一张账:不许留没用的、var 不改是错、错误不许忽略、类型转换不许含糊、 总账叫「歧义就是技术债」;
  3. 这些检查 release 时零运行开销,但代价是 Debug/Release 行为不一致—— 这个交换要心里有数;
  4. comptime 的病根是「样板 + 别家工具的缝合」,Chromium 用 Python 生成 C++ 是书里举的实例;
  5. 分配器范式的本质是把「内存决定权」连工具一起交给程序员—— 代价是所有接口多一个参数;
  6. hermetic(密封)= 同样输入任何机器同样输出,它是缓存和「为每个目标编一个二进制」 这两件事的地基;
  7. 包管理锁的是源码哈希,不是版本号——变化必须被明确想要。

7. 原文地图

主题原书章原文位置
第一优先级是终端用户1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:33(搜「first priority」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:35(搜「end user experience should come first」)
「最好的想法炖成的一锅炖菜」1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:46(搜「stew」)
五条规定:无用变量1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:59(搜「Unused variables」)
五条规定:unreachable 与自定义编译错误1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:63(搜「when a condition is unreachable」)
五条规定:const/var1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:75(搜「var variable is never changed」)
五条规定:错误不许忽略1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:85(搜「will not allow you to ignore」)
五条规定:类型转换无歧义1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:91(搜「Type coercion must be unambiguous」)
总账:歧义就是技术债;零运行开销1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:99(搜「TECHNICAL DEBT」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:102(搜「runtime cost」)
元编程的病:Chromium 用 Python 生成 C++1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:129(搜「Chromium」)
comptime:顶替四样工具、几乎零新语法、范式转变1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:135(搜「comptime feature」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:139(搜「zero new syntax」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:136(搜「paradigm shift」)
分配器范式:像 malloc/free 但给你数据结构1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:145(搜「malloc and free」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:146(搜「data structures managing」)
内存策略对比表(Zig 行:护栏、可叠可换、优雅恢复)1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:210(搜「Zig’s Allocators」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:216(搜「recover gracefully」)
「内存管理不是一个已解决的问题」1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:219(搜「Memory management is not a solved」)
编译器速度:每秒 890 万行1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:240(搜「8.9 million lines」)
hermetic 定义与默认密封1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:249(搜「same input」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:253(搜「Hermetic by default」)
缓存每一步构建1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:267(搜「cache every step」)
包管理:URI 与哈希锁定1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:271(搜「URI for a」) · text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:274(搜「same source code hash」)
「依赖地狱」收尾1.3 Leveling up developer experience, for the userstext/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:281(搜「dependency hell」)

Footnotes

  1. 出处:「1.3 Leveling up developer experience, for the users」第 33–36 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:33,搜「first priority」)。原文:「Zig's first priority is making life better for end users. Software is only good when it serves the needs of its audience.」「Zig's language design starts from the core idea that end user experience should come first - and concludes that programmers should be given the best possible tools to provide it.」 ↩

  2. 出处:「1.3 Leveling up developer experience, for the users」第 45–47 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:46,搜「stew」)。原文:「I think of Zig as a delicious stew made up of the best of ideas from across the world of programming language design.」 ↩

  3. 出处:「1.3 Leveling up developer experience, for the users」第 51–56 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:53,搜「wants you to write good code」)。原文:「The Zig compiler wants you to write good code, and it is happy to stop you in your tracks to accomplish that goal.」「my annoyance quickly turned into consideration, and then into better code.」 ↩

  4. 出处:「1.3 Leveling up developer experience, for the users」第 59–70 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:59,搜「Unused variables」;:63,搜「when a condition is unreachable」)。原文:「Unused variables and parameters are not allowed in Zig, unless the code explicitly discards them.」「You can even provide your own compilation errors to help you understand why a particular change might have activated a previously impossible code path.」 ↩

  5. 出处:「1.3 Leveling up developer experience, for the users」第 73–77 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:75,搜「var variable is never changed」)。原文:「Variables must never be more mutable than necessary.」「If a const value is changed, it's an error. If a var variable is never changed, it's an error too.」 ↩

  6. 出处:「1.3 Leveling up developer experience, for the users」第 79–81 段(注记,text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:79,搜「compiler-friendly」)。原文:「const-heavy code happens to be incredibly compiler-friendly, which is one of the ways Zig code can beat idiomatic C code in performance.」 ↩

  7. 出处:「1.3 Leveling up developer experience, for the users」第 83–88 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:85,搜「will not allow you to ignore」)。原文:「Errors and return values must be handled or explicitly discarded.」「Zig simply will not allow you to ignore the error.」「Zig programs can also specify the entire set of errors that a function may produce, allowing the compiler to check your assumptions about the possible ways some code could fail.」 ↩

  8. 出处:「1.3 Leveling up developer experience, for the users」第 90–97 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:91,搜「Type coercion must be unambiguous」)。 ↩

  9. 出处:「1.3 Leveling up developer experience, for the users」第 99 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:99,搜「TECHNICAL DEBT」)。原文小节标题即「AMBIGUITY IS TECHNICAL DEBT」。 ↩

  10. 出处:「1.3 Leveling up developer experience, for the users」第 99–106 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:102,搜「runtime cost」)。原文:「these checks will never incur any runtime cost when you compile for release.」 ↩

  11. 出处:「1.3 Leveling up developer experience, for the users」第 109–118 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:114,搜「boilerplate」)。原文:「For reviewers, by being too confusing, complex, or repetitive to properly evaluate.」「Metaprogramming works to save time in these ways and others.」 ↩

  12. 出处:「1.3 Leveling up developer experience, for the users」第 119–127 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:124,搜「novel-length compiler errors」;:127,搜「everything happens at runtime」)。原文:「programmers often find themselves confounded by novel-length compiler errors」「the caveat, of course, is that everything happens at runtime.」 ↩

  13. 出处:「1.3 Leveling up developer experience, for the users」第 129–134 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:129,搜「Chromium」)。原文:「Chromium, the basis for Google Chrome and the world's most widely used browser engine, uses Python scripts in a variety ways to generate C++ code when C++'s features simply aren't enough. It is also legendary for being difficult to build.」 ↩

  14. 出处:「1.3 Leveling up developer experience, for the users」第 135–137 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:135,搜「comptime feature」)。原文:「Zig's comptime feature allows programmers an extraordinary amount of freedom to run almost arbitrary code at compile time.」 ↩

  15. 出处:「1.3 Leveling up developer experience, for the users」第 137–141 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:139,搜「zero new syntax」)。原文:「Comptime fills in the same gaps as generics, macros, code generation scripts, and constant functions and expressions, and adds almost zero new syntax.」 ↩

  16. 出处:「1.3 Leveling up developer experience, for the users」第 136 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:136,搜「paradigm shift」)。 ↩

  17. 出处:「1.3 Leveling up developer experience, for the users」第 143–150 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:145,搜「malloc and free」;:146,搜「data structures managing」)。原文:「This is just like C's malloc and free paradigm, but with even more control by giving you access to the data structures managing your program's memory.」 ↩

  18. 出处:「1.3 Leveling up developer experience, for the users」第 152–218 段(表 1.1,text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:185,搜「Static Analysis (Rust」;:196,搜「C-style malloc and free」)。五行策略为表中原文各行。 ↩

  19. 出处:「1.3 Leveling up developer experience, for the users」第 203–217 段(表 1.1 的 Zig's Allocators 行,text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:210,搜「Zig’s Allocators」;:211,搜「swappable allocation」;:216,搜「recover gracefully」)。该行优点列:「The same benefits as C-style manual memory management. Explicit lifetimes. Guardrails in safe mode. Easily stackable and swappable allocation strategies to suit a code path's needs. Allows code to recover gracefully from allocation failure.」缺点列:「Requires testing for safety to be checked. Even the simplest code must explicitly define the allocator.」 ↩

  20. 出处:「1.3 Leveling up developer experience, for the users」第 232–242 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:240,搜「8.9 million lines」)。原文:「As of that talk in 2021, the Zig compiler could generate intermediate code at a rate of 8.9 million lines of code per second on consumer hardware.」演讲链接为 https://vimeo.com/649009599(照录原书,查阅于 2026-10-19)。 ↩

  21. 出处:「1.3 Leveling up developer experience, for the users」第 244 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:244,搜「data-oriented principles」)。原文:「I'm going to teach you how to apply some of those data-oriented principles, too!」 ↩

  22. 出处:「1.3 Leveling up developer experience, for the users」第 247–251 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:249,搜「same input」)。原文:「When given the same input, a hermetic build system is able to produce the same output in a reproducible and deterministic manner - regardless of what machine you're building your code with.」 ↩

  23. 出处:「1.3 Leveling up developer experience, for the users」第 253–260 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:253,搜「Hermetic by default」)。原文:「Zig is able to produce the same exact binary for the same platform regardless of where your project is compiled.」「simply compile your code for each target you wish to support, and the installation process can be as simple as a single download.」 ↩

  24. 出处:「1.3 Leveling up developer experience, for the users」第 265–269 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:267,搜「cache every step」)。原文:「it is able to cache every step of your build process. This results in recompiling always taking the minimum time necessary.」 ↩

  25. 出处:「1.3 Leveling up developer experience, for the users」第 270–276 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:271,搜「URI for a」;:274,搜「same source code hash」)。原文:「Instead of managing a centralized package database, Zig just needs a URI for a tarball.」「Your packages will always be locked to the same source code hash until manually updated, guaranteeing that any change in the code you're fetching is explicitly desired.」 ↩

  26. 出处:「1.3 Leveling up developer experience, for the users」第 278–282 段(text/06-ch01-03-1-3-leveling-up-developer-experience-for-the-use.txt:281,搜「dependency hell」)。原文:「Zig will allow you to stop wasting time in dependency hell, configuring containers and learning a 13th build script language, and get back to writing useful code.」 ↩

大主张 — 怎么学、为什么 Zig 站在 C 旁边而不是取代 C

Previous Page

第一个程序 — 学习曲线的真相,和「hello world 一点都不简单」

Next Page

On this page

四个设计决策 — 编译器当教练、comptime、分配器范式、构建不是事后事1. 这一章讲什么2. 顶层全景:一张「为谁好」的因果图3. 核心原理3.1 编译器当教练:五条规定3.2 Do it at comptime:一种机制顶替四样工具3.3 Memory is a resource:分配器范式3.4 Building is not an afterthought:构建不是事后事4. 作者的判断与证据5. 边界与局限6. 可带走的7. 原文地图Footnotes