本文承接《Zig 词法分析和语法解析》的内容，继续讨论 Zig 程序编译的下一步：从抽象语法树（AST）中生成中间表示（IR）。
本文翻译自 Mitchell Hashimoto 关于 Zig 的系列博客第三篇：
翻译本文的过程中，我越来越回想起自己使用 Perl 6 做编译实习作业的时候。通过 Perl 6 内嵌的 Grammar 语法，我基本把词法分析和语法分析的内容给快速解决了。余下的大部分时间都在完成从 AST 到课程定义的中间表示的翻译，数据流分析和生成 riscv 汇编代码的工作。应该说，北京大学仿照虎书内容做的编译实习课程还是很有含金量的。
感兴趣的读者可以查看我当时的代码仓库，其中包括一个完整的 PDF 报告。
以下原文。
Zig 语言是近几年来逐渐声名鹊起的一个新编程语言，也是数目稀少的系统编程语言家族中的一个新成员。它由 Andrew Kelley 于 2015 年开始创造，至今已经开发了八个年头，但是仍然还未发布 1.0 版本。
不过，已经有不少新锐项目选择使用 Zig 开发，例如 JavaScript 运行时和完整开发套件 bun 和分布式金融数据库 tigerbeetle 等。
Hashicorp 的创始人 Mitchell Hashimoto 也在前年卸任 CEO 成为 IC 后开始投入大量时间开发 Zig 程序，包括开源的 libxev 库和目前尚未公开的 Ghostty 等等。
Mitchell 在开发 Zig 程序的过程中，撰写了系列博客介绍 Zig 程序的编译过程。这些内容有助于理解 Zig 语言的设计，以及它如何在 LLVM 提供的抽象和系统开发者之间建立起一层抽象。
我在取得 Mitchell 的同意后对这些文章做一个翻译，以飨读者。
本文翻译自系列第一篇和第二篇博客：
这一部分属于编译器的前端，相对而言比较简单。
以下原文。
上周，我收到清华大学出版社编辑寄来的新书《流计算系统图解》。趁着周末的功夫，我快速浏览了本书的主要内容。一句话评价：值得一读，尤其是对开始开发流计算任务或系统一到两年，初步实现过一些功能或作业，但是还没有对流式系统建立起系统认识的开发者。
上一篇文章《Rust 社群何以走到今天？》发布之后，得益于 Rust 社群的繁荣和成员的分享惯例，我收到了不少关于 Rust 现状的评论。
大部分评论集中在 Rust 项目社群的治理上，即 BDFL 和基金会会对 Rust 项目社群产生什么影响，以及 Rust 项目社群是否需要 Leadership 组织。
本文有些标题党，实际想讲的内容，是我从部分 Rust 曾经的核心开发者的自述当中，所发现的 Rust 项目社群开源协同模式发展至今的一些特点。
我会从这些自述发言的内容切入和展开，对比其他社群遇到相似挑战的状况和应对方式，讨论 Rust 项目社群在协同方式维度上走到今天的沿革。
昨天的文章里，我介绍了 Async Rust 当前的实现以及一个实现 Async Runtime 需要了解的概念和现有的一些实践。
文章发出后，有评论称 Async Rust 创造性工作，没有可借鉴的经验。诚然，Rust 系统编程语言的定位就决定了它与其他有运行时的语言在设计时存在巨大的不同，同类语言 C 和 C++ 在异步编程方面，受限于语言的历史包袱，相关的支持往往以三方库而不是语言级的支持出现。
不过，Rust 至少可以借鉴自己一路走来的经验。Async Rust 的主要开发者之一 @withoutboats 在今年十月份的时候写了一篇 Why Async Rust 的博文，介绍了 Async Rust 一路发展的沿革和背后的设计决策。也是这一篇文章，帮助我理解了大量 Async Rust 设计的理由，从而融会贯通地写出昨天的文章。
随着软件系统越来越复杂，一个完整的复杂软件动辄几十上百万、甚至上千万行代码，提交记录少说几千，动辄几万甚至几十万。个人再也很难有足够的时间，单纯依靠读源代码和提交历史来理解系统运行的机制。这个时候，设计文档和作者现身说法讨论设计过程，尤其是失败的设计过程，就显得尤为重要。
实际上，我认为国内软件行业前沿的水平已经能跟世界前沿竞争，差的是时间积累的底蕴和人才的绝对数量。例如，全球第一波做数据库的人，到现在几乎都是三五十年经验起步，他们通过师父带徒弟甚至带出徒孙的形式，培养出了一大批领域专业人才。这一壁垒是很难走旁门左道超越的。
所幸开源运动的发展使得我们能够无国界的接触最前沿的软件设计思想和技术实践，我们于是可以对照一个完全开放的软件系统，根据核心开源开发者的介绍，理解这些智慧和经验的结晶。
以下原文，文中的“我”是 @withoutboats 的自称。
绝大多数第一次接触 Async Rust 的开发者所写的 Hello World 程序是下面这样的：
1 | async fn say_world() { |
目前最流行的 Rust Async Runtime tokio 告诉你，只要在 main 函数前加上 #[tokio::main] 这个咒语，再把 main 函数定义成一个 async fn 函数，就可以在程序的任何地方用 async fn 和 .await 语法享受到并发编程的免费午餐了。
但是，这样的解释显然不足以满足相信 Rust 尽可能显式表达所有开销的哲学的人；也就是说，到底 async fn 里的逻辑是怎么被执行的，代码中出现 .await 的时候，Rust 程序实际在执行什么动作。
本文基于具体的异步运行时和并发库代码，介绍支持 Rust 并发模型工作的核心概念。
我在此前的多篇文章中讨论了商业开源的话题：
这些讨论当中观点的源头，除了我在商业开源公司的工作经历以外，也有对国外企业主和律师的内容的理解。其中，撰写了《Open Source for Business》（中文版为开放原子开源基金会律师刘伟翻译的《商业开源》）的大律师 Heather Meeker 的观点尤为重要。早在夜天之书 #6 一文里，我就引用过 Heather Meeker 的观点。
今年五月份前后，我读到了 Elastic License 2.0 and the Evolution of Open Source Licensing 一文。它是 Heather Meeker 律师带头撰写 Elastic License 2.0 协议背后的故事和自述。我深感它对于近五年商业开源软件形势发展的影响，于是向 Heather Meeker 申请了翻译本文的授权。今天终于有时间完成翻译，希望能帮助国内关注商业开源的企业家、开发者以及律师，了解发生在北美软件行业的一系列变化。
以下原文翻译。
过去数年，我从参与 Perl 6 和 Apache Flink 等项目出发，逐步进入到开源的世界当中。我在 2019 年成为 Apache Flink Committer，2020 年成为 Apache Curator 的 PMC 成员，2021 年全力投入 TiDB 社群的建设，2022 年成为 Apache 软件基金会（ASF）的正式成员和孵化器导师并接连帮助三个开源项目加入孵化器孵化，2023 年成为 Apache ZooKeeper Committer 和 Apache Pulsar PMC 成员。
在这个过程里，我持续接触到了风格各不相同的开源社群和开源开发者，并逐渐认识到中国开发者是开源运动的中坚力量之一：中国不缺好的开源开发者。
然而，当下大部分人讨论和评价中国开源的现状时，往往会认为中国开源距离全球主流水平仍有较大差距。《中国信息化周报》撰文提到，中国开源“整体呈现‘散似满天星’之势，还未形成‘聚似一团火’的强大合力”。
立足现状，我想以一个普通的开源开发者的视角，分享我所遇见的高水平中国开源开发者的形象，进而讨论从开发者个人出发，为建设好中国开源做贡献的几个可能的探索方向。
当地时间 8 月 10 日，知名开源软件公司 HashiCorp 发布一则公告，称其原先在 Mozilla Public License 2.0 下发布的 Terraform、Consul 和 Vault 等多款软件，将在未来的版本中改为使用商业源码协议，即 Business Source License 1.1 来发布。
此前，已有其他知名开源软件公司也改用或从一开始就使用商业源码协议许可其源码公开的软件。
本文首先介绍商业源码协议的由来和内容，进而以剖析选择该协议的公司和软件的方式讨论其作用。最后，从企业开源的动机和利益权衡出发，讨论为何 HashiCorp 等一众所谓开源软件公司，最终都走向带有商业保护条款的源码公开协议。