LWN：Zig 2024 路线图！

关注了就能看到更多这么棒的文章哦～

Zig 2024 roadmap

By Daroc Alden
February 2, 2024
Translation totally done by Gemini
https://lwn.net/Articles/959915/

Zig 语言 2024 路线图 已于上周在 Zig Showtime（一场报道 Zig 新闻的展示）上发表演讲中展示。 Zig 项目的终身独裁者 Andrew Kelley 阐述了他对 Zig 语言的目标，主要关注编译器性能以及语言稳定的持续进展。他讨论了增量编译计划的详细信息，并从代码贡献和财务支持的角度解决了项目的可持续性问题。

Zig 的重点

Kelley 开场时讨论了即将发布的 0.12 版本，确认 GitHub 标记为 该里程碑 的 Issue 构成了他期望在该版本中实现的功能的准确列表，并且 0.12 中没有计划进行重大的破坏性修改。 Kelley 表示，他预计 0.12 将相当稳定，许多用户也会更喜欢它，因为它主要包含对 0.11 的错误修复，其中只有少数将会反向移植到 0.11.1。然后，他谈到了决定解决最关键问题的过程，这种做法旨在提高稳定性，并邀请任何有大型实际 Zig 项目的人将自己与语言相关的问题添加到 跟踪文档中。

随后，Kelley 转入讨论编译器中的大量未解决问题，并指出如果他每天修复一个错误，也要花数年时间才能解决所有这些问题。因此，显而易见，Zig 项目需要一些方法来更快地解决未解决的问题。 Kelley 解决此问题的方案是提高编译器的性能 — 如果贡献者无需花费太多时间进行编译，他们就可以花费更多时间真正处理自己的贡献。目前，Zig 编译器在我的笔记本电脑上从头构建需要十分钟，但测试需要超过 600 个 CPU 分钟。该时间的大部分都浪费在使用 LLVM 进行代码生成上，后者通常很慢（尽管 LLVM 项目 取得了最新的进步）。

LWN 先前报道 Zig 项目尝试使 LLVM 变成可选依赖。 Kelley 表示，该目标取得了重大进展，原生 x86 后端已经足够完整，“你可以开始使用它并查看它是否适用于你的用例”，尽管它尚未通过所有行为测试。他期望这些修改能纳入 0.12，尽管 LLVM 后端将至少再发布一个版本中保持默认。 Kelley 希望原生后端对调试版本有用，对于调试版本来说，快速生成代码比生成最佳代码更为重要。

他还对增量构建的进展感到兴奋，并表示：“这一特性对 Zig 来说是独一无二的，因为你根本不可能意外做到这一点。你需要从一开始就为此设计”。虽然其他语言支持增量编译，但 Zig 项目计划比其他语言更进一步，包括直接将已更改的函数修补到磁盘二进制文件中。为了支持增量编译，Kelley 一直在重新设计编译器的内部数据结构，以使增量编译尽可能顺畅。

他转换了编译器的内部表示以避免使用指针，而是将信息存储为按索引访问的扁平数组。这种表示允许编译器对程序的内部知识直接保存到磁盘，然后重新加载而不进行解析或修复，以便增量编译可以只需直接 mmap()先前的分析结果并直接访问它。 Kelley 继续说道，增量编译“实际上是 Zig 的杀手级特性，我们甚至还没有发布它”。最终，他想让项目增量重建快到显得瞬时完成的程度。

后来，Kelley 声称在标注 1.0 版本之前 Zig 的四个主要重点是性能、对语言本身的改进，将标准库提升到统一的质量水平，以及撰写正式的语言规范。他将每一项都作为后续步骤的必要先决条件提出，其中对性能的研究决定了必要的语言更改，而语言更改本身决定了规范的内容。他通过指出“目前的情况非常不稳定，但也许 1.0 并不是你真正等待的东西”，解决了有关 Zig 何时才能达到 1.0 的担忧。也可能是你在等待语言规范的草稿发布。我认为那将是一个稳定的转折点”。

在主讲后的问答环节中，有人询问他们如何在公司引入 Zig 的使用，因为该语言尚未稳定。 Kelley 的回答是，大家应该“请求宽恕，而不是许可”。 Zig Showtime 的主持人 Loris Cro 进一步解释说，过于关注 Zig 是否已达到 1.0 版本是对重点的偏离。 Cro 表示，更重要的是要对 Zig 与其他语言相比如何定位有一个良好的心理模型，以及使用该语言是否对你的用例来说实际上更好。 Kelley 同意这一评估，并表示只有当 Zig 能够真的改善某个软件，而不是为了引入一种新语言而引入一种新语言时，才应该在其公司中引入 Zig。

另一个问题涉及 Zig 项目是否打算专注于外部工具，例如更好的语言服务器。 Kelley 回答说，他打算在集成官方支持的语言服务器之前先让增量编译正常工作，因为它可以重用许多相同的内部组件。他确实声称，任何人都可以通过提交拉取请求来影响 Zig 的路径和时间表，并鼓励任何对特定工具或特性特别感兴趣的人尝试为该项目做出贡献。

另一个听众问道，Martin Wickham 在 Software You Can Love 大会上发表的 2023 演讲 中突出的问题在 Zig 中是否存在任何补救措施，其中一个隐式按引用传递的函数参数可以 在该相同内存也通过可变指针变为别名的时 导致问题。 Kelley 回答说，此问题尚未解决，并指出虽然此问题在科技新闻界引起了很大关注，但并不认为它很重要。他指出 TigerBeetle 是一款用 Zig 编写的金融数据库，非常注重正确性，列出了该语言的几个其他问题作为更紧迫的问题。尽管如此，他向听众保证最终会解决该问题，但这目前尚未成为优先事项。

一位潜在的贡献者表示，他们很高兴为 Zig 编写一些编译器优化通道，并想知道编译器将在何时稳定下来，他们可以考虑贡献这些通道。 Kelley 回答说，在高效内部表示方面仍有一些额外研究工作要做，并且他还特别关注了 Nodes 之海 表示。 Kelley 继续说，高级优化需要等到完成这项探索后再进行。

另一个问题与 async-await 何时重新回到语言有关。 Kelley 回答说，Zig 以前版本中的异步 I/O 支持是实验性的，并且他们已经了解了在系统语言中尝试执行此操作时会遇到哪些问题。他说，他非常喜欢单线程异步事件循环，因为它们使你能够非常明确地指定 I/O 操作的发生顺序，并且他想将其带回语言，但缺少先决条件。他谈到了调试异步程序的困难（包括 DWARF 对异步函数缺少支持），以及 LLVM 协程代码生成的问题。最终，他说异步编程将需要等待原生后端，该后端可以更好地控制如何生成异步函数的代码。

财务状况

Kelley 还花了一部分时间讨论了 Zig 软件基金会 的财务状况。该基金会最近公布了 一份报告，作为其 2024 年筹款活动的一部分，解释了其如何在 2023 年使用捐款。虽然许多志愿者直接为 Zig 项目贡献时间，但该基金会近三分之二的支出用于支付承包商完善核心语言。剩余的三分之一用于支付 Kelley 完善该语言的时间以及支付必要的基建和法律费用。

2023 年最后，捐款有所减少，但 Zig 比以往任何时候都更受欢迎。当年的 GitHub 上的反馈问题以及 pull requests 合并数都创下了记录。2024 年，Zig 软件基金会希望大部分资金能再次来自于个人捐款，这是其 2023 年收入的三分之一。它也在尝试新的资金来源，包括 "捐赠者赏金"。该基金会以前对功能赏金表达过不满，"bounties 是软件开发领域的一种赞助形式很差劲，因为它们阻碍协作以及代码可维护性”。捐赠者赏金是一种另类提案，其中赏金是支付给基金会的，而不是直接支付给贡献者。在这种模式下，赏金仍然可以促成 Zig 的开发，而不必让贡献者们互相不对付或鼓励开发劣质代码。Kelley 很快强调了捐赠者赏金是一种试验，"我们并非希望每个人都这么做"。没有任何附加条件的捐款仍然是基金会最优选的捐款方式。但一些有特定、紧急的、针对某一个功能的捐赠者可以联系 Zig 软件基金会来资助一项赏金。

结论

在 Zig 项目向着雄心勃勃的语言目标不断前进的同时，未来还有许多困难的技术挑战。凯利对 2024 年该语言的愿景主要集中在 性能，以此来提高开发速度并解除其他工作的阻碍。标准库、文档以及语言规范需要做很多长期附加工作。尽管如此，Zig 项目很健康，去年有 354 位贡献者并且有一群成长中的认真的实际用户。Kelley 指出他不确定将其标记为 1.0 需要多长时间；与任何自由软件项目一样，Zig 的进展取决于人们的帮助意愿。尽管有这样的现实，但 Kelley 声称该项目终会随着时间的推移而实现目标。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～