Zig Bypasses LLVM to Boost Compiler Speed and Clear 1,200-Bug Backlog

Zig绕过LLVM以提升编译器速度并清理1200个待修复缺陷 Kelley断言编译器缓慢是导致Zig问题积压的主要瓶颈，这使得非LLVM原生代码生成和破坏性语言变更成为敲定1.0版本前必需的前提条件。 Andrew Kelley介绍了即将推出的Zig 0.12版本及后续版本的战略，将编译器性能确立为消除缺陷和提升开发者效率所必需的核心飞轮。为了实现极致的编译速度，Zig正通过开发原生代码生成后端、自研链接器，以及由扁平、无指针的内部内存架构驱动的增量编译模型，积极摆脱对LLVM的依赖。演讲概述了通往Zig 1.0的阶段性演进路径——从提升编译器速度和保持语言可塑性，到稳定标准库以及起草形式化规范——同时回顾了基金会的财务状况，并回答了社区关于async/await、开发者工具和企业采用等方面的疑问。 Zig 0.12标志着从固定的发布日期转向严格按问题解决情况发布，旨在成为Mach和TigerBeetle等下游项目能够可靠锁定的首个版本，并计划推出仅用于修复缺陷的0.12.1版本作为支持。 (4:03) 为清理超过1200个未解决缺陷的积压，Zig的首要战略优先级是通过摆脱LLVM依赖、实现非LLVM原生后端以及定制增量编译，从根本上大幅提高编译器速度。 (8:33) Zig软件基金会启动了2024年筹款活动，指出每月额外增加10,000美元即可让现有核心团队承包商增加工时，从而大幅加快迈向1.0版本的开发进程。 (21:11) 迈向Zig 1.0的渐进路径优先考虑编译器速度和具可塑性的语言设计，其次是稳定标准库，接着起草形式化语言规范，最终发布1.0正式版。 (24:21)

Andrew Kelley outlines the 2024 Zig roadmap, identifying compiler performance as the core bottleneck governing developer velocity and bug resolution. To establish a reliable foundation before reaching Zig 1.0, the project is prioritizing self-hosted backends, incremental compilation architectures, and downstream stability over fixed calendar deadlines. 0.12 Release Focus and Downstream Project Pinning (4:03) Rather than racing toward an arbitrary calendar date, Kelley explains that the 0.12 release prioritizes resolving outstanding blockers so production teams can comfortably pin their codebases to it. Zig tracks external dependents—such as the Mach engine and the TigerBeetle database—addressing near-term blocker issues on GitHub before tagging the release. For users requiring long-term stability, the Zig Software Foundation (ZSF) plans to support enterprise pinning via a dedicated, bugfix-only 0.12.1 release, while noting that an interim 0.11.1 release has limited utility because master has diverged too far for clean backports. To curb maintainer burnout, the release process is also being narrowed. Kelley states that 0.12 release notes will abandon exhaustive commit-by-commit listings in favor of targeted migration guidance, emphasizing syntax changes, breaking modifications, and headline features. Compiler Speed as the Engine for Bug Reduction (8:33) Addressing an issue tracker burdened by 1,227 open bugs, Kelley argues that fixing one bug per day would take more than four years without overcoming incoming reports. He frames compiler speed as the underlying economic flywheel of development, using an analogy from real-time strategy games: debugging requires a tight loop of editing, compiling, and testing. When compilation consumes the bulk of that loop, engineering velocity stalls. Kelley asserts that shrinking compilation to near-instant execution is the only viable path to eliminating bugs at scale. Once compilation overhead is minimized, developers and maintainers can iterate through tests and code modifications rapidly, unlocking the productivity needed to make significant headway on the tracker. Eliminating LLVM and Engineering Incremental Compilation (12:30) The primary operational strategy to achieve radical speed is shedding the project's dependency on LLVM for debug builds. Zig's experimental in-house x86 backend already permits certain projects to compile without LLVM. While it does not yet pass every behavior test, Kelley aims to make self-hosted code generation increasingly practical throughout the 0.12 and 0.13 cycles. True velocity gains depend on incremental compilation, which Kelley describes as Zig's unreleased killer feature. To achieve instantaneous incremental rebuilds without external tool friction, Zig eliminated internal pointers across all compiler types and values. The compiler's in-memory state is structured into flat integer arrays formatted like an on-disk database, allowing serialization directly via a single `memcpy` syscall without pointer fixups. Kelley stresses that language semantics remain intentionally malleable to accommodate this architecture: he is fully willing to break language syntax or impose new restrictions whenever necessary to guarantee that the compiler remains exceptionally fast. The Sequential Path to 1.0 and Source Versioning (24:21) Kelley outlines a strict sequential dependency required to reach Zig 1.0: first, maximize compiler speed while the language remains malleable; second, solidify the standard library, which remains an experimental playground outside of core data structures and OS layers; third, draft an official language specification; and fourth, tag 1.0. Kelley cautions developers against waiting on the sidelines for 1.0, noting that practical real-world stress testing during the pre-1.0 stabilization phase is essential to catch structural flaws before backwards compatibility freezes permanently. To prevent the ecosystem fragmentation seen during Python's multi-year 2-to-3 migration, Zig plans to explore source-level version declarations. This mechanism would allow a single compiler binary to compile and link modules targeting different language versions within the same build. Regarding `async`/`await`, Kelley clarifies that reintroducing the feature requires solving major technical barriers—including LLVM coroutine intrinsics that force hidden memory allocations, missing debugger infrastructure in DWARF/CodeView, and cancellation semantics—meaning it must wait for native backends to mature. Tooling Maintenance Taxes and Foundation Finances (21:11) Addressing developer tooling, Kelley distinguishes between compounding investments and maintenance taxes. While compiler speed compounds team productivity forever, integrating in-tree language server features (LSP) too early creates an ongoing tax, requiring maintainers to update tooling surfaces on every compiler refactor. While tools like ZLS navigate code well, complex compile-time evaluation (`comptime`) will receive deep architectural compiler support only after core designs stabilize. Financially, Kelley notes that user adoption and bug reports have surged while incoming contributions have leveled off. An additional $10,000 per month would allow ZSF to fully fund existing contractors who want to bill more hours directly to the compiler. While ZSF introduced structured donor bounties for specific milestone sponsorship, both Kelley and Loris Cro stress that unrestricted, recurring individual donations remain the foundation's preferred funding mechanism, as they preserve operational independence without administrative overhead. Zig's 2024 roadmap subordinates feature expansion and rigid release dates to architectural performance, positioning a fast, self-contained compiler as the necessary foundation for standard library stability, formal specification, and eventual 1.0 readiness.

Zig 软件基金会创始人 Andrew Kelley 在 2024 年路线图直播中指出，彻底消除对 LLVM 的依赖并实现原生增量编译以大幅提升编译速度，是解决积压缺陷、加速迈向 1.0 版本的前提条件。 0.12 版本收敛与生产锁定策略 (4:03) Andrew Kelley 明确 Zig 0.12 的发布策略有别于以往按日期强行推进的做法，核心目标是彻底解决关键阻塞问题，使下游项目能够放心固定版本。为此，Zig 官方维护了第三方依赖追踪列表，优先解决 Mach 和 TigerBeetle 等项目的短期阻碍缺陷。此外，随着 master 分支大幅分化，旧版 0.11.1 仅能挑拣少量安全提交，实用性有限；基金会将全力支持 0.12，并计划推出纯缺陷修复的 0.12.1 版本供企业使用。为了减轻维护负担并避免团队倦怠，0.12 的发布说明将大幅精炼，重点记录破坏性变更、语法调整及主要特性，不再逐条收录所有代码提交。 编译速度瓶颈与增量编译架构 (8:33) Kelley 认为追踪系统中积压的 1227 个缺陷难以快速消化的根本原因在于编译器过于缓慢，这严重拉长了“修改-编译-测试”的排错闭环。为了从根源上提升开发吞吐量，Zig 必须摆脱耗时巨大的 LLVM 依赖，推进自研的 x86 等原生代码生成后端。自研后端无需外部汇编器和链接器，为真正的增量编译铺平了道路。在底层实现上，编译器彻底清除了内部指针，将所有类型与值重构成类似磁盘数据库的平铺整数数组结构，无需指针修复或序列化逻辑，仅凭单次系统调用（memcpy）即可完成内存与磁盘状态的持久化及恢复。Kelley 强调，成熟语言如 C/C++ 受制于向后兼容而无法实施此类重构，而他愿意打破语言语义来保证编译器性能，这也构成了 Zig 尚未完全释放的核心竞争力。 迈向 1.0 的顺序与生产采纳建议 (24:21) Kelley 反驳了“语言本身无快慢之分、仅实现有快慢”的观点，强调语法和语义会给优化与内存布局带来硬性约束。因此，Zig 迈向 1.0 的路线遵循严格的递进顺序：首先通过保持语法可塑性来打造极速编译器，随后固化目前质量参差不齐的标准库，接着起草正式语言规范，最后正式发布 1.0。针对因担心破坏性变更而观望的用户，Kelley 与 Loris Cro 指出无需盲目等待 1.0 标签，Node.js 等项目长期处于 0.x 阶段同样支撑了关键业务；早期用户的实际测试有助于在兼容性彻底冻结前暴露架构缺陷。此外，Zig 计划探索源文件层级的版本声明机制，使单一编译器能够平滑混编不同主版本或 1.0 前的代码，从而避免类似 Python 2 至 3 迁移时的割裂阵痛。 异步特性受阻与工具链取舍 (30:00) 对于广受关注的 async/await 特性，Kelley 解释称其暂时搁置源于三大严峻技术瓶颈：LLVM 内置协程机制性能低下且包含隐式堆内存分配，直接违背 Zig 的零隐式分配哲学；GDB 与 LLDB 等调试器无法标准化展示异步调用栈与挂起状态；同时语言层面的任务取消语义仍需自底向上重新设计。Kelley 拒绝在工具链成熟前拼凑出权宜版本。在开发者工具方面，构建系统与交叉编译管线已足够成熟，但深入集成语言服务器协议（LSP）仍被视为一种“维护税”，因为这会显著拖慢底层编译器重构的脚步；类似 ZLS 等高级工具需等待核心架构完全稳定后再行整合。 开源运营模式与架构可重塑性 (21:11) 在财务与运营层面，ZSF 审计报告显示用户量与缺陷报告激增，但捐赠增长已趋平缓。Kelley 与 Cro 阐明，相较于附带管理开销的专项赞助（Donor Bounties），无附加条件的持续性捐赠仍是基金会最青睐的资金来源，它构成了总收入的约三分之一，能够最直接高效地资助核心开发者处理底层任务。谈及代码库的可维护性时，Kelley 以近期顺利完成的 Intern Pool 重构为例：涉及近 30000 行核心代码的底层调整仅由数人在一个月内完成，这与 LLVM 耗时约五年、数百名工程师才艰难完成的不透明指针迁移形成鲜明对比，展现了 Zig 在代码规模增长后依然具备高度的可重构性与敏捷度。 Zig 将短期重心置于确保 0.12 的稳定依赖，同时全力推进原生后端以打破 LLVM 的性能枷锁。然而，包括 async/await 的彻底重构、标准库的大规模规整以及优化管线的搭建，依然依赖有限的核心工程人力，且高度受制于无附加条件资金的增长速度。

## Background 本期视频由 YouTube 频道“Zig SHOWTIME”于 2024 年 1 月 26 日发布，由主持人 Loris Cro 主持，Zig 语言创始人兼 Zig 软件基金会主席 Andrew Kelley 担任主讲。视频描述附带了 Zig 软件基金会 2024 年财务报告与筹款链接以及 SYCL 大会官网，核心内容围绕 Zig 2024 年度路线图展开，并包含后续的观众问答环节。 ## TL;DR Andrew Kelley 详细拆解了 Zig 0.12 版本及后续通往 1.0 的演进路径，强调 0.12 的发布目标是解决阻断性问题以供下游生态长期锁定版本。为了打破修复上千个 Bug 的线性瓶颈，团队将“打造极致编译速度”确立为压倒一切的首要优先级，核心举措包括摆脱沉重的 LLVM、自研 x86 代码生成后端以及从零构建无指针架构的增量编译。在路线图顺序上，团队将按“编译器极速优化 → 固化语言特性 → 固化标准库 → 规范草案 → 1.0”分步推进，同时公布了基金会财务现状并呼吁捐赠以支持更多核心开发者全职投入。在问答中，Andrew 还就原生协程（async）遭遇的 LLVM 缺陷与调试器瓶颈、语言服务器（LSP）内置成本、三万行代码重构经验及企业落地策略给出了务实解答。 ## Atmosphere & style 整场直播洋溢着开源极客特有的真诚、幽默与毫不妥协的技术纯粹感。Andrew 与 Loris 互动默契轻松，从开场模仿其他语言作者搞怪、分享滑板趣事，到深入编译器底层时严谨冷峻地剖析 LLVM 的弊端，情绪转换自然且极具感染力。面对财务吃紧、海量 Bug 和社区对 1.0 的焦虑，Andrew 没有粉饰太平，而是以“宁可打破代码向后兼容也要把增量编译做成杀手级特性”的决绝姿态给出了硬核答复，展现出强大的工程信念感与对社区支持的由衷感激。 ## Bulletin - [05:05](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=305s) Zig 0.12 版本调整发布策略，取消死板的截止日期限制，转为以任务清零与解决 Mach、TigerBeetle 等关键下游生态项目的阻塞 Issue 为导向，旨在打造一个可供长期锁定的稳定版本。 - [08:33](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=513s) 面对累积的 1200 多个 Bug，Andrew Kelley 确定 0.12 之后的绝对优先级是提升编译速度与摆脱 LLVM 依赖，认为极速构建能成倍压缩排错反馈闭环，从根本上解决工程维护瓶颈。 - [13:14](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=794s) Zig 正在推进基于整型数组无指针布局、支持单次系统调用/memcpy 刷盘的增量编译架构，Andrew 明确表示愿意为了增量编译直接破坏语言向后兼容性。 - [21:11](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1271s) Zig 软件基金会（ZSF）发起 2024 年筹款，若每月能新增约 1 万美元预算，将能全额转化为两名核心关键开发者的合同工时，避免其被迫接商业外包以加速 1.0 稳定版落地。 ## Key takeaways - [05:05](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=305s) 0.12 版本以项目锁定（Pinning）为首要目标，侧重解决下游生态的短期阻断性 Bug，并将长期重构任务顺延至后续版本。 - [05:05](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=305s) 通过两周集中处理，Zig 官方仓库积压的历史峰值 PR 数量从 200 多个成功压缩至 94 个，清理完毕后将全力冲刺 0.12 发版。 - [08:33](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=513s) 若按每天修复 1 个 Bug 的速度需 4 年才能清空 1200+ 缺陷，唯一打破线性消耗的方式是把编译器做到极速以压缩测试闭环时间。 - [11:27](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=687s) 自研原生 x86 代码生成后端已跨越可用性门槛，在 0.12 中开发者已可在部分项目中跳过沉重的 LLVM 直接进行 Debug 构建。 - [13:14](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=794s) Zig 增量编译架构完全重构了内部内存模型，剔除运行时裸指针并采用紧凑的扁平整型数组，实现与磁盘缓存的极速直接映射。 - [13:14](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=794s) 团队将增量编译视为 Zig 无法被成熟语言复制的杀手级特性，若遭遇架构设计死胡同，团队拥有随时打破既有语言规范的决断权。 - [17:35](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1055s) 0.12 将精简 Release Notes 策略，仅聚焦语言变更、破坏性改动和重大特性，不再逐条记录海量细碎 Commit。 - [21:11](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1271s) 来自普通个人与微型捐款的网络贡献占到 ZSF 总收入的约三分之一，构成了基金会免受单一商业资本裹挟的核心底气。 - [24:21](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1461s) 通往 1.0 的路线顺序明确为：优先优化编译器性能与代码生成，再固化语言与标准库，最后发布官方语言规范草案并打标 1.0。 - [27:28](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1648s) 开发者无需盲目等待 1.0，可在高度稳定期提前介入；未来 Zig 计划通过源码内声明语言版本的方式在单个编译器中跨大版本无缝协同编译。 - [30:17](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1817s) Zig 协程（async）暂时搁置的原因是 LLVM 内置协程隐式调用 malloc 且性能极差，未来必须依赖自研后端与专用调试器才能彻底重构重启。 - [35:57](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2157s) 定向赞助悬赏（Donor Bounties）仅是满足个别捐助者特殊诉求的妥协，ZSF 最推崇的依然是没有任何附加条件的经常性捐款。 - [41:05](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2465s) 过早将语言服务器（LSP）内置到编译器会带来巨大的维护税，每次调整底层内存布局都要同步修复 LSP，因而目前需优先优化编译器性能。 - [44:25](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2665s) 三人团队历时一个月完成了近 3 万行 InternPool 核心数据结构的手工重构且未遇重大意外，展现了 Zig 代码库在深层架构改动上的极高可塑性。 - [47:56](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2876s) 团队正在调研 Sea of Nodes 等极速优化架构，并计划提前搭建优化流水线雏形以吸引外部编译专家参与贡献。 - [50:12](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=3012s) 在企业中推广尚未设立稳定规范的 Zig 时，建议采取“请求原谅而非请求许可”策略，优先从内部非主干的开发者工具和边缘链路切入。 - [55:08](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=3308s) 官方坚持以实际工业缺陷（如加法触发非法行为）为核心演进指标，拒绝盲目跟风技术社区讨论度高但实际工程危害极小的理论议题。 ## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=6s) 开场与 Zig 基金会近期动态 直播在片头音乐中拉开帷幕，主持人 Loris 开启了第 36 期 Zig SHOWTIME。在正式进入主题之前，Loris 宣布了两项重要动态：第一，Zig 软件基金会（ZSF）正式发布了 2024 年度财务报告并启动了筹款活动。观众可以在 Zig 官方网站查阅详细的资金流向，并积极参与捐赠。Loris 解释道，随着项目规模的扩大，核心贡献者数量增多，待处理的工作量也大幅攀升，充足的资金将直接助力 Zig 尽早达成 1.0 正式版目标。 第二项动态是“Software You Can Love 2024”（SYCL 2024）大会已正式定档，将于 2024 年 5 月 14 日至 17 日在意大利米兰举行。该会议欢迎各界开发者前往交流，参会者届时可以见到 Andrew Kelley、多位 Zig 核心团队成员以及活跃社区用户。大会目前已开放演讲者招募（Call for Speakers），且今年邀请到了 Roc 编程语言的创始人 Richard Feldman 等函数式编程领域的重量级嘉宾，整体议题设置相较往届也有所更新。 在介绍主讲嘉宾 Andrew Kelley 时，Loris 幽默地提到了 Andrew 的多重身份：他不仅是 Zig 语言的仁慈独裁者（BDFL）兼 Zig 软件基金会主席，还是一名竞技游戏《Killer Queen》的高手和滑板爱好者。Loris 笑着回忆几个月前在美国与 Andrew 碰面时，不仅一起去了滑板公园，Andrew 还“强迫”他品尝了一种搭配奶酪凝块、花生酱与果酱的独特薯条（Poutine 变体），给他留下了深刻印象。 - **财务报告与筹款**：可在 Zig 官网查看资金开销细节，筹款主要用于资助全职与兼职贡献者，加速 1.0 里程碑推进。 - **SYCL 2024 会议**：2024 年 5 月 14 日–17 日在米兰举行，包含 Zig 与 Roc 等语言社区的跨界交流。 --- ### [04:03](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=243s) 幽默开场与社区捐赠反馈 Andrew Kelley 接过麦克风，开场便模仿 Odin 编程语言作者 Ginger Bill 搞怪：“大家好，我是 Ginger Bill，Odin 编程语言的创造者，请尝尝我的新啤酒”，随即笑着澄清这只是个玩笑。Andrew 提到自己已经很久没有公开直播或发表演讲，也是时候向大家汇报最新进展了。 关于本次更新汇报的契机，Andrew 分享了一个来自筹款平台的趣事。在 Every.org 上进行捐赠时，支持者可以留下一段私密留言。他在阅读留言时看到有人写道：“给你打钱了，你们干得不错，但麻烦每个月多更新点动态，我们想知道到底发生了什么。”面对社区对项目透明度的渴望，Andrew 直言：“行吧，这很合理”，因此决定通过本次演讲全面梳理接下来的规划。 --- ### [05:05](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=305s) 0.12 版本的发布策略：以项目锁定与问题解决为导向 ```mermaid flowchart LR accTitle: Zig 0.12 Milestone Strategy accDescr: 流程图展示第三方项目提交问题、Zig 团队分类处理并最终实现版本锁定的过程。 subgraph Input["需求收集"] A["第三方核心项目<br/>(如 Mach, TigerBeetle)"] -->|"提交关键阻塞问题"| B["跟踪 Issue 与 Wiki 列表"] end subgraph Processing["0.12 筛选机制"] B --> C{"问题类型判断"} C -->|"短期修复 / 阻断性 Bug"| D["纳入 0.12 里程碑解决"] C -->|"长期新特性 / 架构重构"| E["顺延至后续版本"] end subgraph Goal["发布目标"] D --> F["发布 0.12.0<br/>提供稳定锁定版本"] end ``` 谈到即将到来的 0.12 版本，Andrew 打开 GitHub 上的 Milestones 页面展示进度。与以往严格受限于固定时间节点的发布不同，0.12 版本的策略发生了转变——团队的重心是彻底完成既定的任务列表，而非赶在某个死板的日期前草草发布。他希望 0.12 能够成为首个让大型下游生态项目感到安心并能够长期“锁定”（Pinning）的版本，使用户不再被频繁的破坏性改动（Breaking Changes）所困扰。 为了摸清生态的真实诉求，Zig 维护了一个跟踪 Issue 和 Wiki 页面，第三方项目可以自行评估重要性并将自身添加到列表中。例如 Mach 游戏引擎团队专门列出了阻碍其开发的重大问题清单，Zig 团队已经解决了其中一部分，并全力攻克剩余关键项；而 TigerBeetle 等项目列出的长远架构需求则被合理推迟到未来版本。Andrew 解释道，针对该里程碑的核心策略就是筛除长期重构项目、专注解决短期阻断性 Bug，从而发布一个让下游生态“用着舒坦、无需紧跟 master 分支”的稳定版本。 关于 1 月份里程碑百分比进展看似放缓的原因，Andrew 坦言是因为自己当月经历了一次搬家。繁琐的生活琐事极大地打碎了整块专注的时间，因此他将精力转向了轻量但耗时的 GitHub PR 审查。Zig 仓库的待处理 PR 历史性地首次突破了 200 个，经过两周的集中清理，他已将未结 PR 压缩至 94 个，并计划在彻底清理完 PR 堆积后全力投入 0.12 版本的发布收尾工作。 - **Milestone 策略变化**：以任务彻底清零为准绳，弱化固定截止日期，着重生态稳定性。 - **生态项目支持机制**：通过开放 Wiki 跟踪 Mach、TigerBeetle 等重度依赖 Zig 的项目痛点。 - **PR 积压清理**：两周内将历史最高峰的 200+ PR 削减至 94 个，随后集中精力冲刺 0.12。 --- ### [08:33](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=513s) 核心瓶颈：解决 1200+ 缺陷的关键是极致的编译速度 在展望 0.12 之后更长远的路线图时，Andrew 展现出了对现有 Bug 数量的极大痛苦。他在屏幕上圈出了 Issue 跟踪器中触目惊心的数字：1,227 个 Bug。他算了一笔账：哪怕自己保持极高效率每天修完 1 个 Bug，也需要花费超过 4 年的时间才能全部清空，这在工程演进中是不可接受的。 为了打破这种线性消耗，Andrew 提出了一个类似《帝国时代》等即时战略或卡牌构建游戏的“经济体投资”逻辑：“The realization that I had is that the compiler is too damn slow. That's why that's why we have bugs because it takes too long to fix them.”（我意识到的问题是，编译器实在太慢了。这就是为什么我们有这么多 Bug，因为修复它们花费的时间太长了。）在开发者的日常时间分配中，如果编译环节占据了巨大比例，留给写代码和运行测试的时间就会被严重挤压。一旦编译耗时被缩减到近乎为零，日常编码-测试的反馈闭环将被极大加速，Bug 修复率也会呈指数级上升。 Andrew 调侃这看似是一个“银河脑”（Galaxy brain）式的循环认知：初看觉得简单，深思后可能会怀疑，但推导到极致后会发现真相就是如此纯粹——将编译器提速摆在首位，一切工程效率瓶颈才会迎刃而解。因此，在确保 0.12 发布让用户能够稳定锁定之后，整个团队的绝对优先级就是：“We need to make this compiler the fastest programming language that anyone can use that's the next priority.”（我们必须把这个编译器做成所有人都能用到的、速度最快的编程语言，这就是下一个优先级。） --- ### [11:27](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=687s) 性能攻坚方向：摆脱 LLVM 依赖与自研 x86 后端进展 为实现编译器的极致吞吐，Andrew 展示了一个性能攻坚任务看板。在团队规划的众多攻击方向中，最核心的一环就是“放弃 LLVM”（Ditch LLVM）。由于 LLVM 本身庞大且沉重，在日常快速迭代与 Debug 编译场景中，它已经无可争议地成为了 Zig 编译链路中最严重的瓶颈，彻底摆脱对其依赖是不可逆转的方向。 在整个 0.12 开发周期中，Zig 团队已经在自研代码生成后端上投入了大量心血。虽然现场未能即时调出行为测试（Behavior Tests）通过率的具体百分比数据，但 Andrew 强调进展显著——团队自研的原生 x86 代码生成后端已经达到了初步可用的阶段，这标志着摆脱外部重量级编译器基础设施、实现轻量毫秒级编译的路线迈出了坚实的一大步。 ### [12:30](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=750s) 绕过 LLVM 的自研后端：迈向极速调试构建 在讨论彻底摆脱对 LLVM 依赖的愿景时，Andrew Kelley 详细介绍了 Zig 正在推进的自研代码生成后端。这一后端完全不接触 LLVM，从而大幅削减了编译开销并带来了显著的构建加速。尽管目前该后端尚未完全通过所有的行为测试（behavior tests），但它已经迈过了可用性的门槛，开发者完全可以开始上手体验。 对于部分特定的项目，开发者现在已经能够纯粹依靠自研后端完成调试构建（debug build），直接跳过沉重的 LLVM 编译流程。虽然该后端仍然有海量的完善工作要做，但这套基础能力已经合入主干并将在 0.12 版本中正式提供给社区尝鲜。Andrew 指出，随着后续版本的持续迭代，自研后端的实用性和覆盖范围将会稳步提升。 --- ### [13:14](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=794s) 增量编译：自底向上的杀手级特性与系统重构 谈到摆脱 LLVM 之后的下一步，Andrew 将增量编译（incremental compilation）定性为 Zig 正在全力打造的核心护城河。他强调，这种级别的增量编译绝不可能凭空或偶然诞生，必须从编译器立项之初就进行全盘设计。现有的其他语言根本无法在事后通过打补丁的方式获得同等能力。为了实现他们所设想的增量编译，团队不能依赖任何系统汇编器，必须从头编写专用的代码生成逻辑来与自研链接器（Linker）紧密配合。 更为根本的是编译器内部数据结构和内存布局的彻底重写。Zig 编译器流水线中的所有类型和内部值都经过了全面重构，完全剔除了运行时的裸指针（pointers），而是将整体状态组织成类似于关系数据库的结构。所有信息都紧凑存放在扁平的整型数组中，使得编译器状态可以直接映射到磁盘。序列化与反序列化过程退化为一个极其单纯的系统调用（syscall）或一次纯粹的内存拷贝（`memcpy`），中间没有任何指针修补（fix-ups）开销。这种激进的架构改造要求推倒既有的抽象层，绝不是引入某层接口适配就能达成的。 ```mermaid flowchart TD accTitle: Zig增量编译内存与持久化架构 accDescr: 展示Zig编译器将类型与值组织为无指针整型数组并通过单次系统调用实现内存与磁盘极速同步的设计 subgraph CompilerState["编译器内存架构 (类数据库结构)"] direction TB AST["抽象语法树 / IR"] DataArrays["扁平整型数组<br>(完全剔除运行时裸指针)"] TypeVal["类型与值元数据"] AST --> DataArrays TypeVal --> DataArrays end subgraph IO["单次系统调用持久化"] Syscall["单次 syscall / memcpy<br>(零修补 Fix-ups)"] end subgraph Storage["磁盘缓存"] DiskCache["磁盘增量快照<br>(与运行时内存布局完全一致)"] end CompilerState -->|"内存极速刷盘"| Syscall Syscall --> Storage Storage -->|"秒级反序列化恢复"| Syscall Syscall -->|"直接映射"| CompilerState ``` 更关键的是语言设计层面的妥协与权力。Andrew 解释了为什么最近团队将精力全面倾斜在编译器底层架构，而非频繁推进语言层面的特性提议：他完全做好了为了增量编译而随时破坏语言现有规范的准备。如果是成熟的 C 或 C++，语言规范的铁律会让增量编译的深层优化寸步难行；但对于尚未定型的 Zig 而言，一旦在推行增量编译时撞上设计死胡同，团队拥有直接打破向后兼容性的特权。 Andrew Kelley 在阐述打破语言稳定性的决心时极其明确地表示：“If we're willing to break the language, which I absolutely am, then when you run into a design dead end when trying to make incremental compilation happen, you just break everyone's code, change the language, add a new restriction: 'Sorry, you can't do this because we have to make incremental compilation work, we need to have a fast compiler, we're going to change the language.'” 关于增量编译在整个战略中的地位，Andrew 进一步总结道：“So my point here is that this is our big—this is actually Zig's killer feature, and we haven't even launched it yet.” 尽管自研链接器与自研后端耗费了难以估量的底层设计工时且目前尚未完全释放红利，但一旦它正式落地，将立刻在游戏、终端模拟器、JavaScript 引擎及数据库等所有基于 Zig 开发的领域引发生产力革命。同时，编译器自身的构建效率也会大幅提升，进而加速核心团队解决 Bug 的迭代速度。因此，在 0.12 发布之后，增量编译将是优先度最高的核心任务。 - **深度整合依赖**：自研代码生成与自研链接器绑定，彻底杜绝系统外部工具链带来的黑盒性能开销。 - **无指针序列化**：编译器状态数据全部存储于整型数组内，读写磁盘仅需单次内存拷贝。 - **排他性竞争壁垒**：现有成熟系统编程语言受制于向后兼容与外部工具链生态，几乎无法复制这套彻底推翻重来的架构。 --- ### [17:35](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1055s) 版本发布策略：0.11.1、0.12 钉选支持与精简发布说明 关于近期的版本发布安排，Andrew 回顾了此前关于是否推出 0.11.1 版本的纠结态度。尽管主干分支（master）的代码已经剧烈演进，导致许多近期的 Bug 修复无法轻易 Cherry-pick 反向移植到 0.11 分支上，但他确认仍会打出 0.11.1 的版本标签以兑现承诺。然而他坦言，0.11.1 的实际实用价值有限，哪怕是极其看重稳定性的团队，直接升级到 0.12 也会是综合体验更好的选择。 针对 0.12 发布后的规划，团队明确承诺会推出仅包含 Bug 修复的 0.12.1 次级补丁版本。这一决策是专门为了满足那些需要将工具链长期固定在特定版本（pinning）的生产用户。Andrew 特别提醒社区，如果有关键的致命问题阻碍了项目在 0.12 上线后进行版本锁定，用户应主动在对应 Issue 下直接 @ 提醒他，确保这些阻碍性问题被纳入 0.12 的里程碑（Milestone）中。 与此同时，团队决定对过去的发布说明（Release Notes）编写策略进行全面瘦身。过去 Andrew 试图遍历每一个 Commit 并将其完整体现在发布说明中的做法，在如今开发规模飞速扩张的情况下已经彻底难以为继。从 0.12 起，发布说明将采取全新的精简策略： 1. 聚焦且仅详细列出语言层面的改动（Language changes）； 2. 完整罗列所有的破坏性变更（Breaking changes），为用户从 0.11 迁移代码库提供清晰集中的一站式指导； 3. 重点概述值得大篇幅介绍的重量级特性，放弃对海量细小 Commits 的逐一记录。 这一策略调整旨在降低核心开发团队在每个发布周期所面临的写作压力与疲倦感，同时也避免让普通用户在面对冗长晦涩的更新日志时产生信息过载。 --- ### [21:11](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1271s) 基金会财务现状：呼吁捐款以释放核心开发者的全职战斗力 随后，Andrew 将话题切入 Zig 软件基金会（ZSF）的财务现状，呼应了 Loris Cro 此前发起的筹款呼吁。目前基金会官网首页已经挂上了募捐横幅。为了提供完全透明的财务公示，Andrew 亲自花了一整天翻阅基金会的全部财务账簿，并手工制作了详细的收入与支出饼图。 目前的现实矛盾在于：随着 Zig 的普及度飙升，涌入生态、需要官方支持与维护的用户呈爆发式增长，但基金会接收到的捐赠金额却进入了停滞期。Andrew 动情地透露，核心团队中目前有两位极其优秀的关键开发者正迫切希望为 Zig 贡献更多工时，但摆在他们面前的选择非常现实：要么从 ZSF 领取承包合同以维持生计，要么只能将工作时间卖给其他公司去接外部的自由职业外包（freelancing）。如果能拿到 ZSF 的合同，Zig 的核心功能就会得到实质推进；而一旦他们不得不去接商业外包，Zig 的演进步伐就会被迫放缓。 Andrew 算了一笔非常具体的账：“So my point is that if ZSF had like 10 grand more per month, we would be able to put that money to like a 100% efficient use.” 他强调，这每月额外的一万美元不会被浪费在任何行政管理或官僚流程中，而是会 100% 毫无损耗地直接转化为核心开发者的报酬，直接换取高产出。这笔额外预算能够显著缩短抵达 1.0 稳定版所需要的时间。反之，若筹款不及预期，项目也能继续向前走，但开发周期必然会被不可避免地拉长。 在展示收入结构饼图时，Andrew 进一步向现有赞助者表达了由衷的感谢，并深入拆解了资金来源： - **个人捐赠的基础支撑**：图表中的直接个人捐赠扇区、Benevity 平台捐赠（绝大部分由个人发起），以及部分第三方平台收入，合计占到了 ZSF 整体总收入的大约三分之一。 - **去中心化资金的价值**：虽然来自单个个人的资金数额有限，但成百上千名普通开发者构成的微型捐款网络，构成了基金会最珍视的收入支柱，正是这部分资金守护了 Zig 能够完全免受单一商业利益裹挟，始终忠于技术初心与开源使命。 ### [24:21](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1461s) 财务收尾与通往 1.0 的路线顺序 在结束财务部分的讨论前，Andrew Kelley 再次向所有支持者表达了诚挚的感谢。充足的资金让团队免于被繁重的行政管理杂务缠身，能够全力以赴为用户打造出色的编译器并按计划发布。他特别向小额个人捐赠者致意：“我知道你们会觉得自己捐的那点钱微不足道，但汇聚在一起后，它意义非凡（I know you feel like your amount that you donate doesn't matter, but as a whole it matters quite a bit）。”同时，他也感谢了大额资助的企业赞助商，这些资金显著加快了各项里程碑的推进速度。 谈及迈向 1.0 的路径，Andrew 指出虽然更多资金能加快进度，但无论如何 Zig 都会达到 1.0。他明确列出了通往 1.0 的先后发展顺序：编译器性能排在首位。编译器越快，开发团队自身的迭代效率就越高，从而能以更快的速度逼近 1.0。 ```mermaid flowchart LR accTitle: Zig to 1.0 Roadmap Stages accDescr: 展现从编译器性能与语言优化开始，依次经过标准库固化、语言规范草案，最终发布 1.0 的演进阶段。 subgraph S1["第一阶段：核心构建"] A["编译器性能与代码生成"] --> B["调整并固化语言特性"] end subgraph S2["第二阶段：生态与规范"] B --> C["固化标准库 (std)"] C --> D["发布语言规范草案"] end subgraph S3["最终目标"] D --> E["打上 1.0 标签"] end ``` 针对技术圈常见的一种论调——“编程语言本身没有快慢之分，只有编译器或解释器才有快慢”，Andrew 提出了反驳。他回忆起早在 2005 年左右去 Python 的 IRC 频道时，若有人问“Python 快吗”，总会有一帮学究式的人纠正说“Python 本身不分快慢，是 CPython 解释器有快慢”。在 Andrew 看来这并不准确，因为语言的设计本身就强加了代码生成与优化的极限与约束。Andrew 直言：“说到底，我完全愿意为了让语言更契合快速编译器或便于优化而修改语言本身（Anyway point being, I'm absolutely willing to bend the language to make it more amenable to a fast compiler or to automization）。”这也是必须优先解决编译速度与底层设计的原因——在确定语言能够支撑极速编译器之前，绝不能草率固化语法。 - 标准库目前仍是一个“实验场”：一部分组件（如 `ArrayList`、`ArrayHashMap` 以及部分操作系统抽象）已经相当成熟稳固，但整体质量参差不齐。只有在核心语言敲定后，标准库才会全面固化。 - 标准库固化后，团队将发布官方语言规范草案（Language Specification Draft），随后正式打上 1.0 标签。 ### [27:28](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1648s) 为何无需盲目死等 1.0 与跨版本兼容构想 对于社区中普遍存在的“我要等到 1.0 稳定了再来用 Zig”的心态，Andrew 表示理解这种情绪，但指出实际开发节奏并非非黑即白。在逐步逼近 1.0 的过程中，系统本身就会变得极其稳定。他强烈建议用户在进入高度稳定期、哪怕还没打上 1.0 标签时就尝试投入使用：“这正是当真正重度投入的真实用户开始遇到问题时，我们有机会在彻底承诺不引入破坏性变更之前修复缺陷的窗口期（That's the chance when real users who really invest in it start to have problems, we have a chance to fix something before we want to really say we're not going to do any breaking changes）。” 更进一步，Andrew 甚至认为 1.0 这个版本号或许并没有大家想象中那么至关重要。他正在构思一种源码级声明语言版本的机制。他以 Python 2 升级到 Python 3 期间长达数年的痛苦割裂为例，批评道：“我觉得事情本不必搞成那样，他们原本完全可以让源代码直接声明自己使用的是哪个版本的 Python，然后由 Python 解释器去兼容运行；我觉得他们在这方面实在太缺乏想象力了（I feel like it didn't have to be that way because they could have just had the source code say which version of python it was and then the python interpreter could have just made it work and I don't know, I feel like they really failed to exercise imagination on that）。” Andrew 认为在 Zig 中完全可以通过在源码声明语言版本，让 1.0、2.0 乃至更早时期的代码在同一个编译器中无缝协同编译，由编译器内部处理旧版本语意的微调。虽然这不能解决 100% 的兼容性变化，但能覆盖很大一部分破坏性改动。因此，与其干等 1.0，开发者或许更应该将“语言规范草案的发布”视为项目真正成熟稳定的分水岭。演讲至此结束，转入问答环节。 ### [30:17](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1817s) 问答开启：深谈 Async 的困境与重启前提 问答环节刚开始，Loris Cro 挑选了来自观众 bit Watcher 的高频提问：Zig 的 `async` 协程目前进展如何？ Andrew 坦言自己在 PPT 中遗漏了这个核心话题。他首先声明自己在心底极其热爱 `async/await`，它能精准表达意图——先并发发起多个任务，随后在需要时汇聚等待结果。他自称也是 Node.js 的资深粉丝，虽然在 Deno 和 Bun 出现后很少再写 JS，但当年用单线程事件循环搭配回调写代码的体验令人感到无比舒适。他曾试图将这套理念移植到面向 AOT（提前编译）的系统级编程中，但遭遇了数个难以逾越的底层技术大山： ```mermaid flowchart TD accTitle: Zig Async Challenges Breakdown accDescr: 分析 Zig 原生协程面临的三大核心阻碍：LLVM 缺陷、调试工具缺失与语言级取消语义。 subgraph LLVM["LLVM 底层缺陷"] L1["官方内置协程不可用（性能差）"] L2["隐式调用 malloc，违背内存可控原则"] L3["改用 Struct 降级打碎 LLVM 优化"] end subgraph Tooling["调试工具链空白"] T1["DWARF / CodeView 无法表达协程堆栈"] T2["系统级调试器彻底失效"] end subgraph Lang["语言语义设计"] C1["异步任务取消机制 (Cancellation)"] end LLVM --> R["必须构建自研代码生成后端"] Tooling --> D["必须构建专用的自研调试器"] Lang --> S["攻坚复杂的语言层设计"] ``` 在痛陈 LLVM 的现状时，Andrew 毫不客气地批评道：“如果我们想要优秀的异步代码，LLVM 根本不够格；他们虽然有自己的一套协程内置机制，我试过了，简直就是垃圾（LLVM just doesn't cut it, it's not good enough. They have their own coroutine built-ins; I tried them, they're trash）。”LLVM 的协程机制不仅代码质量糟糕、运行缓慢，而且会在底层隐式调用 `malloc`，这完全违背了 Zig 对无隐式内存分配的核心承诺。若退而求其次用结构体来模拟状态机，又会直接破坏 LLVM 的代码优化通道。因此，要实现高质量的 `async`，Zig 必须依赖自己的后端代码生成。 此外，调试工具链也是一大死穴。目前的 DWARF 和 CodeView 格式根本无法表达挂起的协程状态，系统级调试器完全抓瞎，逼得 Zig 甚至需要自研调试器。再加上异步取消（Cancellation）等高难度语言设计难题，让协程落地变得极其沉重。 - Zig 过往的 `async/await` 已经历了三次迭代，虽然被暂时移除，但作为探索性实验收集到了关于事件循环、语法融合以及 LLVM 局限性的宝贵数据。 - Andrew 明确表示绝不会为了“在功能清单上打个勾”而交付半成品，未来一定会重新引入 `async`，但必须是在彻底攻破上述技术壁垒、以最高标准实现之后。 - Loris 补充道，社区之所以对该特性高度期待，正是因为 Zig 曾展现过让同一套代码库既能以阻塞方式运行、又能以非阻塞异步方式运行的优雅潜力。 ### [34:56](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2096s) 捐赠者悬赏（Donor Bounties）机制与无约束捐赠 Loris 随后转向了官网新闻中紧随财务报告发布的另一则公告——“捐赠者悬赏”（Donor Bounties）。有观众在聊天区留言认为悬赏机制非常酷，有望为基金会带来持续的资金流。 Loris 解释了引入此举的初衷：这是 Zig 软件基金会（ZSF）尝试让特定功能特性的悬赏需求走上正轨的解决方案。不过 Loris 也着重澄清了基金会的立场：尽管悬赏模式很好，但对于 ZSF 来说，没有任何附加条件、不涉及繁重管理开销、可以直接发放到全职开发者手中的常规无约束经常性捐赠（Recurring Donation），依然是基金会最健康、最推崇的资金来源模式。 ### [35:57](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2157s) 定向赞助（Donor Bounty）与无附加条件捐款的定位 Loris Cro 解释了为何基金会尝试引入悬赏/定向赞助机制。过去 Zig 项目确实遇到过一些争议，但社区中也有一批心怀善意、极度热心的支持者，他们非常希望自己关切的某个微小功能或问题能得到哪怕稍微多一点的优先处理，并且完全愿意为此自掏腰包。基金会设立这一机制，本意是将这种并非负面的情绪以富有成效的方式引导出来，让各方皆大欢喜。但这绝不意味着 Zig 打算改变其获取资金的核心模式——最核心的契约依旧是支持者喜爱 Zig、向其捐款，并信任团队会将资金合理分配到最有价值的地方。 Andrew Kelley 随后补充并重申了这一立场。他坦言团队最推崇的依然是没有任何附加条件的纯粹捐赠，定向悬赏绝不是基金会希望所有人都去采取的新常态。它仅仅是基金会与极少数提出特定需求的捐赠者合作时达成的一种妥协与配合，核心是解决这部分人的实际痛点，而非改变整体的财务方向。 > “无附加条件的捐款仍然是我们最喜欢的捐赠形式，设立赞助悬赏并不是说‘噢，这是我们希望每个人都去跟进的新玩意’，完全不是这样；实际上只是我们和几个确实有此需求的捐赠者合作，而我们觉得‘好吧，我们可以帮你办成这件事’。” —— Andrew Kelley --- ### [37:26](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2246s) 工具链与 LSP 的路线图定位：由 PR 驱动还是官方规划 观众提出疑问：语言服务器（LSP）等周边工具在路线图里到底处于什么位置？它们会长期作为外部社区项目存在，还是被纳入官方时间表？Andrew Kelley 直言这是一个非常切中要害的好问题。他解释称，自己在幻灯片中列出的路线图属于“纸面上的路线图”，主要用来指导他个人的日常工作精力。然而，任何社区开发者其实都可以通过提交 Pull Request（PR）来重新塑造 Zig 的时间线。即便官方原本将标准库的改造排在语言特性之后，一旦有人提交了一份质量极高、能切实解决问题的 PR，核心团队也会毫不犹豫地提早合并它。 在个人精力分配方面，Andrew Kelley 明确表示自己的重心依然是增量编译。不过，他和 Zig 团队的承包商们都遵循一个极其人性化、被证明非常行之有效的工作原则：哪怕背离主计划，你也永远被允许去做自己想做的事情。编程中谁都会遇到动力衰竭、对着屏幕发呆发怔的时刻。面对这种状态，Andrew Kelley 的应对方式就是放任自己“打破规则”，换去写一些比如 `zig reduce` 或者语言服务器相关的工具代码。只要选择的事情本身依然具有生产力，哪怕偏离了主路线图，也是在推进整个项目。 > “你可以随时去做任何你想做的事情，哪怕它违背了宏大蓝图；因为说到底，我们都是凡人，我们都有情绪和动力波动……只要我挑的另一件事仍然是有产出的，那么到头来虽然路线图没有完全按计划推进，但我仍然把全部精力转化为了进展。” —— Andrew Kelley - **通过 PR 改变路线图**：社区贡献者不需要等待官方排期，高质量的 PR 实际上就是在自发推动 Zig 沿着外部开发者的时间表向前演化。 - **防止职业倦怠的弹性机制**：核心团队成员与承包商拥有在动力不足时自由切换任务的特权，这种类似应对注意力缺失（ADD）的调节手段确保了长期生产力。 - **工具链投资的双重收益**：在枯燥的硬核编译器重构间隙，偶尔改换节奏去做工具链优化，既是一口“新鲜空气”，也是一种反哺整体研发的长效投资。 --- ### [41:05](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2465s) 工具链的当前成熟度分歧与编译器层面的维护税（Maintenance Tax） ```mermaid flowchart TD accTitle: 核心编译器优化与内置 LSP 的收益与维护成本对比 accDescr: 流程图展示了提升编译器速度能带来长期无负债的收益，而将 LSP 深度耦合进编译器则会变成每次重构都必须承担的维护税。 subgraph SpeedUp["编译器性能投入 (正面收益)"] A["优化编译器内部结构"] --> B["全量编译 / 增量编译提速"] B --> C["所有开发者持续受益"] C --> D["零维护债务，长期提效"] end subgraph LspIntegration["内置 LSP 工具投入 (维护税)"] E["向编译器塞入语言服务器代码"] --> F["代码行数大幅膨胀"] F --> G["修改类型布局/内存模型"] G --> H["必须同步修补 LSP 交互逻辑"] H --> I["沦为拖慢核心重构的维护税"] end ``` Loris Cro 从整体生态现状切入，指出 Zig 的工具链呈现出两极分化的特点。一方面，与 C/C++ 编译以及构建系统（Build System）相关的工具链极为稳固且顶尖。他举例说明，自己最近开发了一个静态网站生成器，其底层完全是一组微型工具加上一段为 `build.zig` 构建图谱的脚本，全盘复用了 Zig 构建系统的能力，展示了其高度的灵活性。但另一方面，像语言服务器 ZLS 和文档生成器 autodoc 这种依赖理解代码语义的工具却时常遭人抱怨。其根本原因在于 ZLS 不是 Zig 编译器本体，无法完全理解复杂的编译期执行（`comptime`）。对于普通跳定义和查引用，ZLS 表现近乎完美；但一旦涉及重度 `comptime` 计算，工具就会脱节。团队并非不在意工具链，而是需要优先让编译器自身具备提供这类信息的能力，这是优先级先后的问题。 Andrew Kelley 随后提出深层次的技术架构考量：有些工作一旦完成就会直接提高整体研发速度（Velocity），而另一些工作则是长期的“维护税”（Tax）。将编译器做快是纯粹的正向飞轮，能永远造福所有人；但如果过早把语言服务器逻辑强行塞进编译器内核，代码量激增不说，每次调整内存布局或底层数据结构时，都必须耗费精力去修复语言服务器，从而成为拖慢演进的沉重税负。Andrew Kelley 还打趣说，自己日常编写 Zig 只用 Vim 而从不依赖 LSP，因此将 LSP 内置对他个人甚至没有任何导航层面的助益，团队必须选在一个绝对战略性的时机再去进行这项重度投资。 > “如果我们把编译器做得更快，那将让我们永远受益；但如果把语言服务器加进编译器，那就会变成一个庞大的组件，每当我们想要重构内存布局或做出调整时，它都必须被持续维护并保证能正常工作……它就像一种税。” —— Andrew Kelley --- ### [44:25](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2665s) 编译器重构硬仗：三万行 InternPool 变更的落地过程 讨论转向了编译器底层极为硬核的工程细节。观众 scoop018 提问：近期针对 `InternPool`（符号驻留池）的重构几乎是对编译器内部数据结构的一次“开膛破肚”，实际落地究竟有多艰难？期间是否遇到了意外的暗坑，还是说全靠苦力硬磨？面对这道被 Loris Cro 戏称为“最资深吃瓜群众”提出的问题，Andrew Kelley 调出了当时的 Pull Request，证实整个变更集规模接近 30,000 行。他强调这绝非引入了第三方依赖（vendoring），而是几乎每一行都由他本人亲自修改，并得到了 Jacob 和 Matthew 的协助。 令人意外的是，面对如此庞大的手术，Andrew Kelley 表示整个重构过程中“并没有发生任何出乎意料的意外”，一切基本完全按照预期推进。中间确实遇到了一些小疏忽——例如早期设计的某些类型中暗藏了“悬空指针隐患（foot gun）”，指针会在某些特定条件下失效；随后他重新修改了类型定义，彻底拔除了这个陷阱。整项工作耗时约一个月，虽然体量巨大且不可避免地带来了一些次生 Bug，但这完全在可控范围内。Andrew Kelley 认为，这次顺利推进反而强力佐证了 Zig 语言在代码可重构性（Refactorability）上的优异表现，开发者在面对近三万行的核心变更时无需抓耳挠腮，整体逻辑极其清晰直接。 - **三万行纯手工重构**：PR 涉及近 30,000 行核心编译器代码变动，全为人工逐行编写重构，由 Andrew Kelley 主导，Jacob 和 Matthew 协助完成。 - **工期约一个月**：从动手到合并历时约一个月，虽然伴随有预料之中的回归 Bug，但没有发生阻碍全局的技术意外。 - **消除类型隐患**：中途修改了容易发生指针失效的设计，将潜在的“坑”从类型系统层面彻底剔除。 - **Zig 代码的可重构性验证**：该案例展示了 Zig 在面对超大规模底层架构推倒重来时，依然能保持逻辑高度透明、易于推理和顺利落地的工程优势。 ### [46:58](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2818s) Zig 代码库的可塑性与 LLVM 的对比 Andrew Kelley 深入探讨了在不同语言项目中实施超大规模代码重构的难度差异。他提出一个设想：如果在一个成熟的项目中需要完成一个包含三万行代码变动（30,000 line diff）的改动，团队究竟要花费一个月、超过一个月，还是根本不敢尝试？他以典型的 C++ 大型项目 LLVM 为例指出，LLVM 社区内部多年来一直有许多迫切想要实施的架构改进（例如推行无类型指针 opaque/untyped pointers），但往往寸步难行。“我感觉在像 LLVM 这样的 C++ 代码库中，他们想做这类改动，却根本做不到。”针对无类型指针的落地，LLVM 社区花费了将近五年时间，动用了成百上千位开发者的参与与协作；而 Andrew 在仅有两名协助者的情况下，只用了一个月就完成了同等规模的跨越式重构。在他看来，这一鲜明对比证明了即使在积累了大量代码之后，Zig 依然保持着极高的可塑性（malleable）与可修改性（hackable）。 - 大型 C++ 项目（如 LLVM）引入深层架构调整（如 untyped pointers）往往需要数百人协作并耗时约 5 年。 - Zig 在积累庞大代码量后，仍能由三人团队在单月内完成 3 万行级别的底层架构重构。 --- ### [47:56](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2876s) 编译器优化流水线的设计规划与 Sea of Nodes 观众提问探讨了未来向 Zig 编译器贡献优化算法的可能性，询问 Zig 是否会引入独立的中间表示（IR）以及相关设计现状。Andrew 表示，为了能尽早解锁社区开发者的贡献热情，Zig 核心团队甚至可能在还没有精力全面推进之前，先搭起基础框架来让外部开发者参与。关于内部 IR 的选择，Andrew 坦言目前尚未最终定论，但他正密切关注一位代号为“negate”的开发者所做的研究。此人在开发极速编译器以及高速优化编译器方面做了大量探索，尤其是围绕“节点之海”（Sea of Nodes）架构进行了非常有价值的实践。 Andrew 坦承自己在深度优化流水线设计上的经验并非最丰富，但他非常希望能深入研究 negate 的优化策略，并亲自进行探索；如果 Zig 采纳了这种方案，也许能进一步吸引 negate 本人直接参与到 Zig 编译器的贡献中来。要在 Zig 中正式引入属于自己的自研优化流水线，还需要大量外围配套工程，例如针对各类优化 pass 的测试机制以及管道检查工具（introspection tooling）。 ```mermaid flowchart TD accTitle: Zig 优化流水线建设规划 accDescr: 展示引入新优化流水线的前置条件、核心探索方案以及预期的社区协同路径。 subgraph Research["理论与架构研究"] A["调研 negate 的方案"] --> B["评估 Sea of Nodes 概念"] B --> C["决定是否引入全新 IR"] end subgraph Tooling["配套工具与基础设施"] D["优化 Passes 测试框架"] E["流水线状态自检与透视工具 (Introspection)"] end subgraph Execution["推进路径与收益"] Research --> F["搭建初步优化流水线骨架"] Tooling --> F F --> G["解锁社区外部优化贡献"] F --> H["吸引 negate 等编译专家深度参与"] end ``` - Andrew 坦承团队可能提前搭建优化流水线的基础雏形，专门为了“解锁像提问者这样的人来参与贡献”。 - 重点探索方向为开发者 negate 提出的“Sea of Nodes”架构及快速优化理论。 - 引入优化流水线的前提是建设配套工具：Pass 单元测试框架与流水线内省监控能力。 --- ### [50:12](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=3012s) 职场策略：如何在缺乏稳定规范的前提下在企业推广 Zig 当被问及如何在 Zig 尚未确立稳定规范（stable spec）的情况下说服公司用 Zig 替代 C 语言时，Andrew 幽默地给出了 Python 社区的名言：“请求原谅，而不是请求许可”（Ask for forgiveness instead of permission）。他解释道，如果是一个年轻工程师，这其实是非常严肃且实用的建议；如果是资深工程师，更稳妥的做法则是先从开发内部工具（dev tooling）入手。在企业中，把非主干业务或不直接面向用户的辅助工具用 Zig 重构或添加功能，不仅不会引发对核心营收业务稳定性的担忧，而且只要能带来实质性能提升或新功能，同事和上级往往只会表示欢迎，而根本不在乎背后用的是什么语言。 主持人随后加入讨论，认为规范固然重要，但在日常工程实践中，很多没有严格规范的现代编程语言依然在大规模普及。至于很多人执着的“1.0 版本”，其本质“就像一个字符串，虽然理论上可以任意长，但现实中它不过是几个字节罢了，这几个字节根本不足以描述 Zig 相较于其他语言的真实状态”。 在版本号与技术选型的问题上，主持人以 Node.js 举例：在长达数年的时间里，Node.js 一直停留在 0.8.x 系列，迟迟不打 1.0 标签，甚至引发了社区的分叉（io.js），但无数企业依然义无反顾地在此基础上构建起大型商业系统，因为它的工程实现本身已经具备实际可用性。 在此环节，直播间陆续收到了多笔捐赠，包括来自 Hector Jam 和 Palmo 的 50 美元，以及来自 spear onl 的 100 美元。聊天室中出现了一位名为“Captain undefined Behavior”的观众，Andrew 借此打趣道，自己在 Zig 里面可不怕什么未定义行为，“在 Zig 里，那叫做非法行为（illegal behavior）”。 - 针对在企业中引入 Zig，Andrew Kelley 给出了由浅入深的切入路径： 1. “请求原谅，而不是请求许可”：年轻开发者可以直接通过解决具体问题来证明价值。 2. 开发者工具先行：利用非生产环境脚本、内部构建工具等边缘链路，避开主营业务审查。 3. 注重实际效益：绝不为了换语言而换语言，必须带来更快的速度或新特性。 - 关于版本号与形式规范的认识： - 1.0 标签只是几个字节的符号标识，无法代表语言真正的成熟度与工程权衡。 - 早期 Node.js 在长期处于 0.8.x 版本时便已被主流工业界大规模商用，技术选型取决于工程实测而非版本号数字。 --- ### [55:08](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=3308s) 语言理论问题与实际业务缺陷的优先级权衡 问答进入尾声，主持人转达了多个观众关于 Martin 在“Software You Can Love Vancouver”大会演讲中所提问题的后续进展。Andrew 直截了当地回应称目前没有任何更新。他明确指出，在自己看来，这个技术细节在实际编码工程中几乎不会引发实质性 bug。“在我看来，它在实际中并不是个问题，它是我们在打下 1.0 标签前需要梳理清楚的语言问题，但它在真实代码里真的没有造成什么麻烦，所以它并不是高优先级事项。” Andrew 观察到这个话题在 Zig 的技术圈子里引发了极高的热度，大家出于“万一在项目中踩雷”的焦虑而反复讨论。但他强调，核心团队不会仅仅因为一个议题成为了技术圈的热门谈资就匆忙打上补丁。他仍然相信自己能够找到一个两全其美的方案——既能彻底消除潜在的隐患（footgun），又能确保代码拥有极致的优化空间。实现这一目标需要深度实验和高度专注的精力，因此他选择暂时搁置，等待可以全神贯注时再行解决。 Andrew 调出实际重度使用 Zig 的真实用户反馈（例如 TigerBeetle 团队整理的 Zig 问题清单）进行佐证。在 TigerBeetle 的列表中，该问题排在非常靠后的位置，说明对其生产而言，排在前面的很多工程问题重要得多——例如加法运算符可能触发非法行为（illegal behavior）这一问题，在他们看来就比 Martin 演讲中讨论的问题紧迫得多。Andrew 赞同 TigerBeetle 的排序，并明确表示自己的优先级判断与技术圈舆论节奏（news cycle）完全不同，团队将继续聚焦于解决那些对实际工业生产影响最大的硬核缺陷。 - Andrew 拒绝盲目跟风技术圈的舆论热点，坚持只有彻底解决问题且不损失优化能力的方案才会被采纳。 - TigerBeetle 等深度工业级用户将该问题的优先级排在较为靠后的位置。 - 相比该理论隐患，解决加法运算符导致非法行为等直接工程痛点拥有更高的演进优先级。 ### [58:25](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=3505s) 全职投入的感激与直播尾声致谢 在问答环节接近尾声时，Andrew Kelley 表达了自己能够全身心投入 Zig 项目的由衷感激。他谈到自己已经全职开发 Zig 好几年了，能够持续全职从事这项工作让他感到非常幸运与珍惜。对他而言，为用户服务并帮助大家写出优秀的代码是最大的乐趣所在。Andrew Kelley 动情地说道：“I love serving users and I love making everyone happy and trying to make everyone's code good um and I really appreciate that people trust us with their um with their donations to make that happen for them so thank you.”（我喜欢为用户服务，喜欢让每个人都开心，并努力让每个人的代码都变得更好；我也非常感激大家信任我们，用捐款支持我们去实现这一切，非常感谢大家。） 主持人 Loris Cro 随后为本期直播画上句号。他感谢所有前来观看 2024 年 Zig 路线图发布的观众，并鼓励大家如果想继续讨论，可以加入任何 Zig 社区交流。他风趣地提到，平时自己总是号召大家加入 Zig SHOWTIME 的 Discord 服务器，但这次路线图的内容对整个 Zig 生态都意义重大，因此在任何一个 Zig 社区展开讨论都非常合适。在节目收尾之际，Loris 再次向慷慨解囊的社区成员表达了感谢，特别点名提到了在直播期间追加捐赠 50 美元的 Jam，以及 El cob 32 等众多支持者。最终，直播在轻松愉快的道别与背景音乐中圆满落幕。 - **全职开发支持**：社区捐款让核心团队得以长期全职维护 Zig，专注提升代码质量与用户体验。 - **社区互动**：官方鼓励开发者在各大 Zig 社区继续就 2024 路线图展开深度探讨。 - **实时捐助回馈**：直播期间持续收到来自 Jam（追加 50 美元）等多位开发者的资金支持，展现了社区的高度凝聚力。 ## Notable quotes > [08:33](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=513s) The realization that I had is that the compiler is too damn slow. That's why that's why we have bugs because it takes too long to fix them. — Andrew Kelley > [08:33](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=513s) We need to make this compiler the fastest programming language that anyone can use that's the next priority. — Andrew Kelley > [13:14](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=794s) So my point here is that this is our big—this is actually Zig's killer feature, and we haven't even launched it yet. — Andrew Kelley > [21:11](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1271s) So my point is that if ZSF had like 10 grand more per month, we would be able to put that money to like a 100% efficient use. — Andrew Kelley > [24:21](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1461s) Anyway point being, I'm absolutely willing to bend the language to make it more amenable to a fast compiler or to automization — Andrew Kelley > [27:28](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1648s) That's the chance when real users who really invest in it start to have problems, we have a chance to fix something before we want to really say we're not going to do any breaking changes — Andrew Kelley > [30:17](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=1817s) LLVM just doesn't cut it, it's not good enough. They have their own coroutine built-ins; I tried them, they're trash — Andrew Kelley > [35:57](https://www.youtube.com/watch?v=5eL_LcxwwHg&t=2157s) 无附加条件的捐款仍然是我们最喜欢的捐赠形式，设立赞助悬赏并不是说‘噢，这是我们希望每个人都去跟进的新玩意’，完全不是这样；实际上只是我们和几个确实有此需求的捐赠者合作，而我们觉得‘好吧，我们可以帮你办成这件事’。 — Andrew Kelley ## Mentioned Zig, Andrew Kelley, Loris Cro, Zig Software Foundation (ZSF), LLVM, Mach, TigerBeetle, Ginger Bill, Odin, Richard Feldman, Roc, SYCL 2024, Python, Node.js, Every.org, Benevity, ZLS ## Video description Links: https://ziglang.org/news/2024-financials/#2024-financial-report-and-fundraiser https://sycl.it 0:00 Intro 3:00 Talk 30:15 Q&A [Source](https://www.youtube.com/watch?v=5eL_LcxwwHg)

[8:33] Andrew Kelley: The realization that I had is that the compiler is too damn slow. That's why that's why we have bugs because it takes too long to fix them. [8:33] Andrew Kelley: We need to make this compiler the fastest programming language that anyone can use that's the next priority. [13:14] Andrew Kelley: So my point here is that this is our big—this is actually Zig's killer feature, and we haven't even launched it yet. [21:11] Andrew Kelley: So my point is that if ZSF had like 10 grand more per month, we would be able to put that money to like a 100% efficient use. [24:21] Andrew Kelley: Anyway point being, I'm absolutely willing to bend the language to make it more amenable to a fast compiler or to automization [27:28] Andrew Kelley: That's the chance when real users who really invest in it start to have problems, we have a chance to fix something before we want to really say we're not going to do any breaking changes [30:17] Andrew Kelley: LLVM just doesn't cut it, it's not good enough. They have their own coroutine built-ins; I tried them, they're trash [35:57] Andrew Kelley: 无附加条件的捐款仍然是我们最喜欢的捐赠形式，设立赞助悬赏并不是说‘噢，这是我们希望每个人都去跟进的新玩意’，完全不是这样；实际上只是我们和几个确实有此需求的捐赠者合作，而我们觉得‘好吧，我们可以帮你办成这件事’。

[239:57] Andrew Kelley: No strings attached donations is still our favorite kind of donation.

[0:06] [Music] [0:23] Rock [0:25] Rolling [0:27] Rock [0:28] rolling [0:30] this this how [0:34] roll This Is How We [0:36] Roll how [0:45] [Music] [0:54] Rock hello hello hello everybody [0:57] Showtime number 36 in yes I haven't [1:00] updated the stream title I will do that [1:03] once I'm done with the intro so hello [1:05] everybody um welcome to another Showtime [1:08] episode um and so I don't have a long [1:12] introduction so we'll get to it pretty [1:13] quickly but couple uh interesting uh [1:16] news before we get there uh number one [1:20] uh we released a 2024 financial report [1:22] and fundraiser uh you can find it on the [1:25] official Zig website and also people in [1:27] chat if they can kindly uh link to the [1:29] blog post directly that would be nice um [1:32] please do check it out so you can see [1:34] where the money goes and also so that [1:37] you can consider donating uh to the [1:38] current ongoing fundraiser because we [1:41] are asking for more money uh so that we [1:43] can pay we have we've gotten more [1:45] contributors over time and more work to [1:47] do and so more money would definitely [1:50] help us reach Zig 1.0 uh sooner uh [1:54] second [1:55] point is that we are we have officially [1:59] announced software you can love 2024 is [2:01] going to be Milan Italy from the 14th to [2:03] the 17th of May [2:05] 2024 uh so if you can be in the area [2:09] around that time please do consider [2:11] coming uh there's going to be you you [2:13] will have a chance to meet Andrew uh a [2:15] bunch of people from the zig core team [2:18] and also active community members uh so [2:22] yeah come have fun and also um if you [2:25] think you have something interesting to [2:26] share there's an open call for speakers [2:28] uh the will also going to have uh [2:31] Richard Felman join us uh Richard Felman [2:34] the creator of the rock programming [2:35] language and it's going to be probably a [2:36] few people also from uh you know that [2:40] side of the fense as in functional [2:42] programming although SRI can love it's [2:45] its own type of conference so please do [2:47] check out the front page there's going [2:49] to be an explanation of what the themes [2:50] are going to be uh but also in the call [2:52] for speakers you will find that uh it's [2:54] slightly different this year than [2:55] previous years so um thank you very much [2:59] uh and and with that I think that we can [3:03] uh go to the main content so uh I know [3:07] that Andrew doesn't really need an [3:09] introduction but since we're using the [3:11] normal Z Showtime format uh I guess I [3:13] should say a couple words about [3:16] him uh just like I normally do with [3:19] other uh speakers so um Andrew Kelly is [3:24] the [3:25] bdfl of the Z programming language he's [3:27] also the president of the zig sof [3:30] Foundation but he's also a um [3:34] competitive player of of a game called [3:36] killer queen he's also a skater uh I met [3:40] him uh in where he lives in the United [3:42] States a few months ago and we went to [3:45] skate park he made me try uh french [3:48] fries with cheese curds peanut butter [3:50] and jelly on them so that was an [3:53] experience and so without further Ado [3:55] please give a warm welcome to Andrew [3:58] Kelly [4:03] hey everyone uh my name is ginger Bill [4:06] I'm the creator of the Odin programming [4:09] language and uh please try my new beer [4:12] just kidding hey everyone uh uh that [4:16] thanks for that intro [4:18] Loris and uh it's been a while you know [4:21] I haven't done any uh streaming haven't [4:25] done any talking in a while so it's [4:26] about that time a chaps shall we uh [4:28] shall we dig into what's coming up I [4:31] think [4:32] um some one of the some when you donate [4:36] on our uh on our every. org button it [4:39] lets you put in a little private note [4:41] and uh it's been fun reading those and [4:42] one person's private note was here's [4:45] some money you're doing a good job but [4:46] please tell us more updates like every [4:49] month we want to know what's going on [4:51] like okay you know that's [4:53] fair so let's at least do that right [4:56] now uh how's my audio [4:58] doing little too compressed I think I'm [5:01] gonna keep going but uh Loris you can [5:02] step yeah it's good it's good change it [5:04] up [5:05] okay all right well let's dig in so the [5:11] first big topic is going to be the [5:13] release that's coming up and this [5:16] information is already kind of public so [5:18] uh I'm want to just show you how you can [5:19] access this information uh if you go to [5:23] zigs GitHub page and you navigate [5:26] to [5:28] milestones [5:30] and you go to the next Milestone it's [5:33] actually pretty accurate so sometimes I [5:36] do go through here and uh take stuff out [5:40] and I think you know what we're gonna [5:41] have to postpone that we're gonna have [5:42] to do that later um but for this [5:44] particular [5:46] Milestone the focus is on actually [5:49] getting these things done uh and not on [5:51] a particular due date so it's kind of a [5:53] different one this time um because I I [5:57] think this this Milestone it's going to [5:59] be the first one where I think a lot of [6:01] projects are going to feel comfortable [6:03] pinning to it and by what I mean by that [6:05] is um we have this tracking issue here [6:09] which I set up so that you can edit this [6:12] wiki page and add your project to the [6:14] list so these are our important [6:16] thirdparty projects and what decides if [6:19] they're important is just if you decide [6:21] that you're an important third-party [6:22] project and you put yourself in this [6:23] list so as an example um the mock folks [6:28] have uh handily created this issue on [6:32] their issue tracker to say hey this is [6:36] the major issues we're having right now [6:38] and we've solved some of their major [6:39] issues but uh there's still a couple [6:42] left and what I want to do for this [6:45] release is get these done um hopefully [6:48] this one [6:49] too and similarly uh other people's [6:52] things um let's see who else we have [6:55] here let's look at Tiger Beal's big [6:57] issues this is going to be probably um [7:00] more longer term things like we're not [7:02] going to get this done for this release [7:04] uh if there were bugs they would [7:05] definitely be a priority um [7:09] but oh this one we actually got done [7:12] pretty recently so anyway point being [7:13] what I want to do is go through all of [7:15] these and uh do the things that are not [7:19] long-term projects do the things that [7:20] are short-term projects uh in order to [7:24] tag a release that can then have a good [7:26] chance of having people be just set you [7:28] know they're just kind of okay on 0.12 [7:31] they don't really need to update the [7:32] latest thing until it comes out and I [7:34] think I've basically collected those [7:35] issues here uh so you might have noticed [7:40] that uh even though this is like pretty [7:42] close to being done in terms of percent [7:45] it's still hasn't had a lot of progress [7:47] down to January this month and yeah the [7:51] deal is I moved this month and that [7:53] really just sucks the concentration out [7:55] of you so it's just a bunch of little [7:57] tasks interrupting me throughout the day [7:59] so what I focused on this month was poll [8:01] requests so you might have noticed we [8:02] actually got up to over 200 for the [8:05] first time in zig's history 200 open [8:08] poll requests but um I've just been I've [8:12] been grinding away at these for two [8:13] weeks and got it down to 94 so that's [8:15] where we're at now um I'll try to get [8:17] down even a little bit more uh but then [8:20] at some point I'm gonna kind of ignore [8:22] the PLL requests for a bit and focus on [8:24] the release so that's that's what's [8:27] coming up here um [8:29] uh so let's get back into this [8:33] then now after after this release is [8:38] done what next because we all knew that [8:41] that's coming up so how about how about [8:43] the road map for the future after [8:45] that well let me skip pass all the stuff [8:49] I already just showed you on my own [8:51] screen [8:54] um bugs bugs bring me great pain so we [8:59] have too many bugs look at how many bugs [9:01] we [9:07] have 1,227 what am I if I solved one of [9:11] these per day it would take what is this [9:14] four years over four years uh to get [9:18] them all fixed that's too [9:20] long um so I need to solve more than one [9:23] per day how are we going to do that well [9:26] the realization that I had is that the [9:28] compil is too damn [9:31] slow that's [9:35] why that's why we have bugs because it [9:37] takes too long to fix them you know uh I [9:40] don't know if what the exact percents [9:42] are of of doing this stuff but uh if we [9:45] could reduce this compiling slice to you [9:49] know almost [9:50] non-existent then you can take that same [9:53] chunk of time that you have per day to [9:55] work on programming and instead it's [9:57] going to be spent more on testing and [9:59] more on editing code which is going to [10:01] let you edit bugs H sorry not edit bugs [10:04] it's going to let you fix bugs faster so [10:07] in my opinion the [10:11] the best thing like if we're playing you [10:13] know like a economy Age of Empires type [10:16] game or whatever it's called or or deck [10:18] building or anything like where you're [10:19] investing in your economy we actually [10:21] need to make the compilator fast and [10:24] then that's that's how we're going to [10:27] fix the bugs um so this may sound kind [10:30] of [10:31] like stupid or simple but [10:36] um I think it's one of [10:39] those it's one of those things where [10:41] like if you if you don't think about it [10:43] enough then you come to that conclusion [10:45] and then if you think about it more then [10:47] you realize something different happens [10:49] but then if you think about it the most [10:53] you know like Galaxy brain you go back [10:54] to the beginning and it's like yeah it [10:56] actually just needs to be a faster [10:57] compiler and then we can fix the bug [10:59] faster like it really is that simple uh [11:04] so to me that's the highest priority [11:07] actually after getting this release out [11:09] so so Priority One get people set so [11:12] that they can pin and not have [11:14] experience breaking changes all the time [11:16] with 0.12 release next priority we need [11:19] to make this [11:20] [Music] [11:21] compiler the fastest programming [11:23] language that anyone can use that's the [11:25] next [11:27] priority um so so yeah I wanted to show [11:30] this [11:31] thing so I also have this little [11:33] performance dashboard here uh this is [11:35] like a can band kind of but I don't know [11:37] it's just a way to look at just a bunch [11:38] of issues and uh this is also pretty [11:41] accurate [11:42] so the way that I'm thinking about [11:45] performance is in these kind of um [11:49] angles of attack so we have one angle of [11:51] attack which is ditch lvm and that's [11:55] it's a good strategy to make the comper [11:57] fast because lvm is the bottle of the [11:59] compiler so obviously that needs to go [12:02] um we've had a lot of work towards this [12:06] done in the 0.12 release cycle actually [12:10] and [12:11] um I forgot to grab a a [12:16] um number of behavior tests passed [12:19] percentage for you all um but it's to [12:22] the point where you can start using the [12:23] x86 back end uh oh here it is and this [12:28] is a backend that Zig provides that does [12:30] not touch lvm at all which makes it [12:33] significantly faster so it's not passing [12:36] all the behavior tests there's still [12:38] some not passing but it's to the point [12:40] where you can start playing with it and [12:42] for some projects you can actually have [12:45] a debug build of your project that does [12:48] not that just bypasses L ofm and you're [12:49] going to get faster builds faster [12:53] compilation um still a lot of work to do [12:55] on that back end but it's to the point [12:57] where you can start playing with it and [12:58] see seeing if it works for your use case [13:00] so um that's actually going to land in [13:03] 0.12 that's available to play with [13:06] now uh and obviously in the future we'll [13:10] keep making that more [13:12] practical [13:14] so come back to ditch lvm but [13:18] incremental compilation this is the big [13:22] one this this [13:25] feature is something unique to Zig [13:28] because [13:30] you just can't do [13:32] it on accident you have to design for it [13:35] since the [13:36] beginning [13:38] um in order to launch incremental [13:40] compilation the way that we're doing it [13:49] you QBE you can't use a system assembler [13:53] you have to write your own code [13:54] generation to work with your own Linker [13:57] um you have to comp completely change [13:59] the way that all the memory is organized [14:01] in the compiler throughout the whole [14:03] pipeline so that you can make this thing [14:06] work like for example we've gone through [14:09] and um and changed all of the types and [14:13] values in Zig so that there's no [14:15] pointers at all and it's organized like [14:18] a database that uh that can get flushed [14:20] to disk and and [14:24] um serialize to dis and deserialized [14:26] from disk with a single assis call [14:29] because everything is just in arrays of [14:30] integers and you can store it on disk in [14:34] the exact same memory layout as the [14:37] compiler uses it at runtime so it really [14:40] is just a mem copy to go to disk or to [14:43] go to memory like like actually just M [14:46] Copy no fix UPS or anything like that uh [14:49] and you can't get that you know as an [14:51] afterthought you have to design the [14:52] system that [14:54] way um [14:57] furthermore uh part of the the reason [14:59] that we've been focusing on the compiler [15:01] architecture lately and not so many um [15:05] language proposals or modifications is [15:09] uh that I'm willing to make the language [15:12] conform to what will make incremental [15:15] compilation feasible so uh you know if [15:19] you tried to add this to c or C++ you [15:21] just would get stuck because the [15:23] language requires you to do things a [15:25] certain way but if we're willing to [15:27] break the language which I ABS [15:29] lutely am uh then when you when you you [15:33] run into a design dead end when trying [15:35] to make incremental compilation happen [15:37] you just break everyone's code change [15:39] the language add a new restriction sorry [15:41] you can't do this because we have to [15:43] make incremental compilation work we [15:44] need to have a fast compiler we're going [15:46] to change the language that's something [15:48] that we're still able to do and you know [15:51] existing languages can't do that [15:54] so my point here is that uh this is our [15:58] big this is actually zigs killer feature [16:02] and we haven't even launched it yet [16:03] we've been investing into this one into [16:05] the Linker we've been investing into [16:07] this one into an in-house back end we've [16:09] been investing into all these things and [16:11] there's been not even that much payoff [16:14] yet but it's it's a it's it's it's a [16:18] killer feature that no one's even [16:19] experienced yet and no other project is [16:22] going to be able to catch up because [16:24] it's [16:25] just it just takes so much fundamental [16:29] design work and you you have to do [16:32] everything like you can't add an [16:34] abstraction to your project and get this [16:37] feature you have to you have to dig up [16:39] the existing abstractions and rework [16:42] them in order to get this feature so [16:44] it's going to be a thing completely [16:46] unique to Zig so this is to me after the [16:50] release this is the highest priority of [16:52] everything because when we have this [16:54] it's going to unlock uh dramatically [16:57] faster um productivity on any project in [17:01] Zig so people who use Zig to make you [17:05] know games [17:06] terminals um JavaScript engines [17:10] databases everyone's going to experience [17:12] like super increased productivity and [17:15] then also we as a z compiler team will [17:18] also in experience increased [17:20] productivity and those bug counts will [17:22] start going down real fast so this is [17:25] the next big [17:27] priority [17:29] check my notes [17:32] Here Yeah [17:35] okay uh so incremental compilation [17:38] that's the big thing and also wanted to [17:40] mention I forgot to mention this on the [17:42] other uh on the release so 0.1.1 are we [17:46] gonna do it uh I kind of wavered on this [17:49] a little bit um I think I will go ahead [17:51] and tag a 0.1.1 [17:54] release I'll just cherry pick some [17:55] commits in there make sure they pass the [17:57] CI [17:58] uh at some point the code starts [18:00] diverging too much and it's just lot a [18:02] lot of the bug fixes just can't go in [18:04] that Branch because the master Branch [18:06] changed too much but we can get some [18:08] stuff in there we'll go ahead and tag a [18:10] release um but I think it's going to be [18:12] not a very useful release I think that [18:14] most people even if your goal is bug [18:16] stability I think you're going to want [18:18] 0.12 even as preferred to this one um [18:22] but I'll go ahead and do it because I [18:23] said I would and it will be a little bit [18:25] better than 0.11 but I think 0.12 will [18:27] be even better in terms of bugs than [18:30] 0.1.1 so keep that in mind uh what about [18:33] a bug fix released for 0.12 yes [18:35] absolutely uh because I think this is [18:38] the idea is that we want people to be [18:40] able to pin to 0.12 if they want to uh [18:43] if they want stability and so 0.12.1 [18:47] with only bug fixes yes that's going to [18:49] help uh the use case of pinning and so [18:52] if you're a user of Zig and you're [18:53] interested in pitting to [18:55] 0.12 um but you feel like you want to of [18:58] your big issues is unsolved um let me [19:01] know make sure that your issue is [19:04] covered in this [19:07] Milestone because and you can ping me on [19:10] on an issue if it's important to you and [19:12] you can say hey um I want to pen to 0.12 [19:15] when it comes out but I'm having this [19:17] you know this major blocker problem for [19:20] my project and it's not it's not listed [19:22] in this Milestone so when you release [19:24] 0.12 you know I'm not going to BU able [19:26] to pin to that one because my problem [19:27] still exists so let me know if that c [19:29] that if that's the problem for you [19:30] because I want to make sure that um if [19:33] you want a PIN to 0.12 then you feel [19:34] comfortable doing that um okay and then [19:39] next [19:40] uh okay release notes our release notes [19:44] are out of control it takes too much [19:45] work and their quality is just too hard [19:48] to ensure because uh I try to go through [19:51] every commit and make sure that they get [19:53] mentioned in the release notes that's [19:55] just not feasible with how much work is [19:57] being done done on Zig so we're going to [20:01] we're going to tone it down a bit um [20:02] release notes strategy is going to [20:03] change so for this release notes uh [20:06] we're g to focus on language changes [20:09] only um breaking changes only and then [20:12] just like big stuff big stuff that feels [20:14] like it's worth mentioning and we're not [20:16] going to sweat trying to mention [20:18] everything because it's just too much [20:20] stuff so the idea is you go to the [20:23] release notes for 0.12 you're not [20:26] overwhelmed by [20:28] um too much information but you do get a [20:32] taste of what's new and most importantly [20:35] you get to see a list of all of the [20:38] relevant stuff that broke so that you [20:40] can have a One-Stop shop for updating [20:42] your code base to that version from [20:45] 0.11 um so I think that'll be a little [20:49] bit of a stress relief on the dev team [20:51] um as well as being more useful for [20:53] users but yeah let me know what you [20:55] think about that um and [20:59] then what about [21:01] 0.13 uh yeah 0.13 that's how I was going [21:05] to segue into bugs and incremental [21:07] compilation so um let's go to the next [21:11] topic which is finances so Loris [21:15] mentioned that we're doing a fundraiser [21:17] and that is indeed true we got this [21:21] little Banner here on the [21:23] homepage um if you haven't read this [21:26] article uh I'll encourage you to check [21:28] it out because I went through and spent [21:30] a whole day digging around in the [21:32] accounting books and uh charts and stuff [21:36] and I made I made this pie chart of [21:38] expenditures I made this pie chart of [21:41] where we get our income from I think [21:43] it's quite interesting to look at um and [21:46] yeah as Loris mentioned are we're [21:49] getting a lot more users of Zig a lot [21:51] more people uh wanting help a lot more [21:53] people using Zig and uh but our [21:56] donations have stagnated a bit so um I [21:59] wanted to ask for money and the thing is [22:04] um I I won't put them on the spot but [22:07] I'm thinking of two uh people on the zig [22:10] core team in particular who uh who just [22:13] want to build more hours they want to do [22:16] work on Zig and their choices are either [22:21] get that money [22:22] from uh like they're going to need to [22:25] either do freelancing with a different [22:27] party or they're going to take a zsf [22:29] contract and if they take a zsf contract [22:32] then Zig gets better and if they do [22:35] freelancing with a different company [22:36] then Zig doesn't get better by them [22:41] so my point is that if zsf had like 10 [22:47] grand more per month we would be able to [22:49] put that money to like a 100% efficient [22:53] use like that money would go directly [22:55] towards contractors who I'm thinking of [22:58] in my head right now who would do [23:00] incredible work and if we like if we [23:03] could do that that's that's like a like [23:05] a major boost in how good Zig is going [23:08] to be very quickly and if we can't do [23:10] that it's going to take longer it's just [23:11] going to take longer to get to 1.0 [23:15] so uh anyway point being if we can make [23:19] that happen that's going to be a boon if [23:20] we can't make that happen it's fine [23:22] things are going to take longer but uh [23:24] you know that's how it goes [23:26] so uh if you're already donating which I [23:29] think probably a lot of people watching [23:30] the stream are I really appreciate it um [23:34] I guess I'll I'll pull down this one [23:37] I'll P I'll go highlight this other [23:39] chart here [23:42] um a lot of these uh so let's blow this [23:47] up a [23:48] bit this blue slice here is individuals [23:52] benevity is also mostly individuals and [23:54] this green slice is mostly individuals [23:56] so actually individuals is a bigger [23:58] portion of this pie than it looks like [23:59] it's about a third I would say um and [24:04] that's our favorite kind of income [24:06] because uh individuals it's it's like [24:10] you don't get very much money from any [24:12] particular person but as a as a whole [24:15] that's that's the chunk of people who [24:17] really keep zsf true to its Mission [24:21] because you [24:23] know we we can we can really just focus [24:26] on doing uh you know making a great [24:29] compiler for our users releasing it and [24:33] not trying to you know run around doing [24:34] a bunch of admin overhead all that stuff [24:37] um so uh especially big shout outs to [24:40] the individual contributors um I know [24:43] you feel like your your amount that you [24:45] donate doesn't matter but as a whole it [24:47] matters quite a bit um but also we [24:50] really do appreciate these other [24:51] companies that have helped us to uh you [24:54] know make swifter progress towards our [24:55] goals uh with bigger chunks of money so [24:57] it's all appreciated all of it but [25:01] um I don't know that's it for finances [25:04] so [25:06] um let's move on to 1.0 which uh I [25:11] mentioned we could get to quicker with [25:13] more money but we'll get there [25:14] regardless either way and this is kind [25:17] of like what I think is going to happen [25:19] in [25:22] order so I mentioned [25:24] performance and I think that making the [25:26] compiler fast is ultimately the fastest [25:30] way to get to 1.0 because we can use [25:33] that compilation speed to speed up our [25:36] development velocity so that's just the [25:38] first thing we need to [25:40] do also as I mentioned um the language [25:44] is malleable the language can change if [25:46] it's going to help performance of a [25:48] compiler for that language um you know a [25:51] lot of people like to say languages [25:53] aren't fast or slow compilers are fast [25:56] or slow uh or they they have different [25:58] qualities like if you if you went into [26:00] like the python IRC channel in you know [26:02] 20 2005 and said it's python fast you [26:05] get a bunch of pedantic people saying [26:07] well Python's not fast or slow but the C [26:10] python interpreter is fast or slow and [26:13] it's like that's not actually accurate [26:16] because languages impose restrictions on [26:18] what is possible in uh you know in [26:21] generating code and optimizations and [26:23] all that stuff so I I think that that's [26:25] kind of like if you really want to be [26:27] truly pedantic languages do have a [26:30] fundamental uh like speed that a speed [26:34] limit that they that the the language [26:36] imposes anyway point being uh I'm [26:39] absolutely willing to bend the language [26:41] to make it more amenable to a fast [26:44] compiler or to automization so that's [26:47] why working on this comes first because [26:50] we can't we can't solidify the language [26:53] until we know that the language is good [26:55] enough to make a fast compiler [26:58] and then finally when those are done we [26:59] can start solidifying the standard [27:01] Library as of right now it's kind of [27:03] just an experimental playground some of [27:06] it's some of it's more stable you know [27:07] array list array hashmap uh some of the [27:10] OS abstractions are pretty solid um some [27:13] you know some of the standard library is [27:14] uh pretty low quality some of it's high [27:16] quality but you know once the language [27:18] is solidified then it's time to um [27:20] solidify [27:21] that uh then we can start getting a [27:23] draft of the spec out and then we can [27:25] start to tag 1.0 [27:28] but I think a lot of people are I see [27:32] this sometimes people are like waiting [27:33] around like oh I'll try Zig you know [27:35] when it's 1.0 I don't want it to be [27:37] unstable and I think that's I think [27:41] that's a reasonable emotion but I think [27:44] that in practice uh what's going to [27:46] happen is that we get closer to 1.0 and [27:50] things will just become extremely stable [27:53] and that's the point where you can start [27:54] using Zig and you should absolutely [27:57] start using it when it's stable and not [28:00] 1.0 yet because that's the chance when [28:03] you know real users who really invest in [28:06] it start to have uh problems we have a [28:10] chance to fix something before we want [28:11] to like really say we're not going to uh [28:15] do do any breaking [28:17] changes uh [28:21] so also I'm not sure 1.0 is going to [28:24] matter that much [28:26] because um I'm thinking about some ideas [28:29] where uh you can declare the language [28:33] that your that your [28:34] code uh depends on and you know the [28:38] python 2 to Python 3 [28:42] um situation was pretty pretty bleak but [28:47] I feel like it didn't have to be that [28:48] way because they could have just had the [28:50] source code say which version of python [28:52] it was and then the python interpreter [28:54] could have just made it work and I don't [28:56] know I feel like they really failed to [28:57] exercise imagination on that um and I [29:02] think it's going to be quite feasible to [29:04] have Zig source code declare the version [29:06] of Zig that it uses and actually make [29:10] uh make zig code you know on 1.0 and [29:14] maybe like 2.0 Zig code or 0 point [29:16] whatever Zig code work together no [29:18] problem because like the compiler itself [29:21] can just know that the semantics were [29:24] supposed to be different in an older [29:25] version and then just make it work it's [29:27] fine [29:28] um that works for you know a big [29:32] category of changes but not 100% of them [29:35] but anyway point being um if you're [29:37] sitting around waiting for [29:39] 1.0 uh maybe wait around for you know a [29:44] little bit longer well because things [29:45] are pretty unstable right now but maybe [29:48] 1.0 is not really what you're waiting [29:50] for maybe you're just waiting for you [29:52] know the draft of the language [29:54] specification to come out I think that's [29:55] going to be you know a stability turn [29:57] any [29:59] point uh and uh with that I think that's [30:03] pretty much all I have to say um I don't [30:04] think I have any more slides after this [30:07] and uh I'm happy to field any [30:09] questions if uh if anyone has any [30:11] questions about 1.0 or this Milestone or [30:13] the next Milestone or anything like that [30:16] thanks [30:17] Loris okay uh thank you thank you Andrew [30:21] uh so let's see if there are questions [30:23] from chat uh let's give them a moment so [30:25] that we can have some questions build up [30:29] um so oh we already have some questions [30:32] so I'll go right away um so I think this [30:37] question comes from bit Watcher but it's [30:38] probably on uh a lot more people's minds [30:42] uh couple words about [30:44] async async I should have had a slide [30:47] about that uh okay so here's what I'll [30:49] say about [30:50] async deep in my heart I love asyn A8 [30:54] because the idea is that you can [30:58] you can express your intent precisely [31:01] you can say I want to start this I want [31:03] to start this I want to start this and [31:05] then later you say now I need these [31:06] results then later I need that result um [31:09] I love that and I also will say uh I'm a [31:14] big fan of uh node.js uh I haven't done [31:18] JavaScript programming uh of that sort [31:20] in a while but like ever since like Dino [31:23] and Bun came out I haven't done it um [31:25] but I did a lot of noj back in the day [31:27] and man I got to say [31:29] single-threaded event loop with [31:32] callbacks is so cozy um just feel really [31:35] good about the way I could express that [31:37] Concept in that in that in that [31:40] framework I tried to bring that to um to [31:45] systems programming to ahead of time [31:47] compiled [31:48] programs and I still want to try and [31:50] bring it but there's there's some big [31:54] problems to solve so one of of them is [31:58] it basically is just completely [32:00] incompatible with [32:01] LM um so we need our own code generation [32:04] backends if we want good code if we want [32:07] good async code lvm just doesn't cut it [32:09] it's not good enough they have their own [32:11] code routine um built-ins I tried them [32:15] they're trash sorry to gore or whatever [32:18] his name is who made them it's just bad [32:19] code uh it doesn't work it's slow it's [32:24] uh like we had to just not use those [32:26] built-ins [32:27] um they also just implicitly call Malik [32:31] and there's nothing you can do about it [32:33] uh they're it's just untenable you just [32:34] can't do it so you have to do it with [32:36] strs which completely defeats lm's [32:39] optimizations like you you might like [32:41] you're gonna get better Cod gen writing [32:42] your own back end just because they [32:44] don't solve this problem whatsoever so [32:47] we have to do our own code genen next [32:50] problem you running your code you want [32:51] to debug it the debugger doesn't handle [32:54] Ayn weight there's no way to represent [32:56] it in dwarf there's no no way to [32:57] represent it in code view the system [32:59] debugging tooling doesn't cut it we have [33:02] to make our own [33:03] debugger [33:06] um there's also just some difficult [33:09] language problems to solve with regards [33:12] to um cancellation U that's something I [33:16] can take on it's just a big [33:19] problem so the thing is that there's [33:22] just all these problems that make it not [33:25] practical that just make it not work and [33:32] uh basically the previous version of [33:34] async a weight that Zig had was an [33:37] experiment um it's actually went through [33:39] three iterations that that was the the [33:41] most recent one was a third iteration of [33:43] async weight and uh as an experiment it [33:46] was successful I mean we collected [33:48] information about what an event Loop we [33:49] need to look like about what the [33:51] features will look like how they'll [33:52] integrate with the language what [33:53] problems we'll run into trying to lower [33:55] them with lvm um ultimately I think it [33:58] can be recovered I think we can have a s [34:01] of weight but it's just an extremely [34:04] difficult technical problem to solve and [34:07] I I'm not willing to solve it in a [34:10] half-ass way you know I don't want to [34:12] just check a asyn we box it's got to be [34:14] good um [34:16] so yeah let me let me do it on my own [34:18] time we'll get there but um there's just [34:22] there's just multiple huge technical [34:25] problems to solve to make it actually [34:27] good that's how I summarize [34:29] it thank you um yeah I think people [34:33] really care about acing because um from [34:35] my perspective as a as somebody who as a [34:38] user of async um it's really cool what [34:41] you can do like the idea that you can [34:43] have one code base be do blocking and [34:45] aying uh all at once not magically [34:47] obviously you have to design for it but [34:50] um that that's something that's really [34:52] really cool but yeah um okay so next uh [34:56] let's see next question actually there's [34:57] a comment uh that I would like to uh [35:00] address so uh there was another piece of [35:02] news posted in the news section after [35:06] the um 2024 financials and that has to [35:09] do with uh donor bounties oh yeah Andrew [35:12] is pulling it up yeah uh so the idea of [35:16] donor bounties is basically our way of [35:20] um making feature bounties work for the [35:24] zig software foundation for the zig [35:25] project um [35:27] and so the comment the comment is saying [35:29] donor bounties are pretty cool and [35:30] hopefully will contribute to recurring [35:32] flow somewhat sure although for us the [35:36] uh you know recurring donation that is [35:39] not tied to anything that doesn't have [35:41] any um you know um management overhead [35:46] like they just money that can directly [35:49] go to people doing work uh that's still [35:52] our preferred way of getting donation [35:54] money by far I would say that this uh [35:57] idea that that um we came up with is [36:01] really mainly because there are some so [36:04] while we did have issues in the past [36:06] there are some very genuinely uh [36:08] well-intentioned supporters of the zig [36:11] project who just would like you know [36:12] that tiny thing to be uh prioritized [36:15] just a little bit because it matters to [36:16] them and they're willing to uh offer [36:19] some money for for that so that's [36:22] basically a way of channeling this not [36:24] inherently negative uh feeling in a [36:28] productive manner so that we can all be [36:29] happy uh that's mainly the goal here not [36:32] really to change our main way of getting [36:35] donation money like I I really think [36:37] that the idea like the main deal I guess [36:39] is that you like the Z project you [36:41] donate uh money to the Z project you [36:43] trust us to allocate that money in a way [36:46] that makes [36:48] sense Andrew is there anything you want [36:50] to add to [36:51] this uh I'll just say what the same [36:54] thing you're saying in my own words if I [36:56] may [36:57] um which is that yeah no strings [36:59] attached donations is still our our [37:02] favorite kind of donation um and this [37:05] donor Bounty is not something that we're [37:08] saying like oh this is a new thing that [37:10] we want everyone to do not really it's [37:12] actually just uh basically us working [37:15] with a couple donors who wanted this and [37:18] we're like okay we'll make that work for [37:19] you you know we're happy to help you [37:21] out nice um okay so another question uh [37:26] um does tooling have a place in the [37:29] timeline or will things like the [37:31] language server and tooling remain [37:33] outside Community [37:36] projects oh man uh I just was thinking [37:40] about something else for a second can [37:41] you please repeat the question sure uh [37:43] so does tooling have a place in the [37:46] timeline or will things like the [37:47] language server and tooling remain [37:50] outside Community [37:52] projects Ah that's a good question where [37:54] does that fit in yeah I really should [37:55] have handled that [37:57] um so I think that here's the way I [38:00] would put it the the road map that I [38:01] outline here uh that's kind of like the [38:04] on paper road map and I think it's the [38:06] main uh guiding force from my [38:09] perspective for me [38:12] however there's a way that anyone can [38:16] influence the timeline or the road map [38:18] of Zig uh and that's with the PO request [38:21] so when someone does work um if it's [38:24] good work then that's kind of like [38:28] you suggesting a different road map [38:31] right because you know was this on the [38:33] road map I don't know I had a standard [38:36] Library listed after language stuff [38:37] right but you know what I'm going to [38:39] look at this and if it solves a problem [38:41] if it's good code I'm going to merge it [38:42] and I'm gonna merge it before you know [38:44] I'm gonna merge it pretty soon hopefully [38:46] um so so Point number one out of two is [38:50] uh if you want to influence these kinds [38:52] of things uh you can uh it's not [38:55] guaranteed but but you can you can do a [38:57] PLL request and you can push Zig down a [39:00] path you know at your own on your own [39:03] timeline uh that requires volunteer work [39:06] but you know that's a that's an option [39:07] that you have um as far as what I'm [39:10] going to work on um I want to focus on [39:14] on this road map as I've outlined it [39:16] here with you know primary focus on uh [39:18] on incremental compilation as I as I [39:21] mentioned um [39:23] however there is something that I do [39:26] which I think is smart um and it's [39:28] something that I do for myself as well [39:30] as an affordance that I offer to all of [39:32] our [39:33] contractors uh which is [39:36] that you can always work on whatever you [39:39] want even if it goes against the master [39:42] plan because uh you know in the end of [39:45] the day we're all humans and we all have [39:47] emotions and motivations and whatnot and [39:50] uh I'm sure other programmers have [39:52] experienced like a lack of motivation [39:54] like you're supposed to work on [39:55] something today and you just you just [39:56] can't do it you try and you just stare [39:58] off into space um that certainly happens [40:01] to me and the way that I deal with this [40:04] is I just allow myself to break the [40:06] rules you know I allow myself to work on [40:08] something else and as long as I pick [40:10] something else that's still productive [40:12] then at the end of the day you know the [40:14] road map doesn't go perfectly according [40:16] to plan but I'm still channeling all my [40:18] energy into making progress um I don't [40:22] know some people might call that add but [40:24] that's just uh that's just how I work [40:28] so uh in other words uh there's a fair [40:31] chance that you know I'm I'm making [40:34] progress towards this big goal but you [40:35] know ah this week I just need to I need [40:37] to change a pace maybe I'll do a little [40:39] bit of work on Zig ruce or maybe I'll do [40:41] a little bit of work on uh you know [40:42] language server or tooling that kind of [40:45] thing so uh long story short I think [40:47] there's a good chance um that tooling [40:50] improves because uh tooling is always an [40:52] investment that um that can help in [40:55] other endeavors and it's nice to have a [40:57] breath of fresh air hope that hope that [40:59] answers the [41:00] question um yeah I think so um if I can [41:05] add something uh from my side uh I would [41:08] say that in general you I guess [41:12] depending on how you look at it it's in [41:13] an interesting spot because some part of [41:16] the tooling is topnotch like everything [41:19] that deals with compilation of c and C++ [41:22] code and uh the build system these are [41:26] like even though the language is very [41:27] early these are very stable parts of the [41:30] um of the Z compiler tool chain and they [41:33] are so stable that I've recently uh [41:36] started working on a static website [41:38] generator and the entire static website [41:40] generator is just a a collection of tiny [41:44] tools and a script that basically builds [41:47] up a build graph for your build. Zig [41:50] like for for Zig build and that's how [41:52] your website gets built and it leverages [41:54] completely the zig build systems so that [41:56] it shows how flexible and um and [42:00] complete it is uh on the other hand [42:03] though it is true there are some other [42:04] parts of the like Zig ecosystem that are [42:06] still very early and incomplete uh one [42:09] example that everybody likes to complain [42:10] about in my opinion a little bit much [42:12] but it it's for example the language [42:14] server uh zls is um doing a lot of work [42:19] but it's not the Z compiler and so it [42:21] can not understand everything that comp [42:23] time can do if you will the same issue [42:26] is also present in autodoc uh the like [42:29] the documentation for the S Library [42:31] which is a project that I work um [42:33] directly myself so for zls personally uh [42:37] in my coding experience which people can [42:39] see also on Twitch I use it a lot go to [42:41] definition find references always works [42:44] flawlessly for me uh but it is true that [42:46] if you do comp time heavy stuff then [42:48] it's not going to be able to follow [42:49] along and neither will be able uh to do [42:52] that out of do so the point here is not [42:54] that we don't care about that type of [42:55] tuning it's just that that type of [42:57] tuning is complicated and requires more [42:59] work and the plan for now is to have [43:02] more help from that perspective from the [43:04] compiler itself but that in turn has to [43:07] come uh further down the line so I would [43:10] say that our perspective in terms of [43:12] tooling is not to not care about it or [43:14] just to leave it to third parties it is [43:16] to design it it's just that it's a [43:18] matter of priorities and some other [43:19] things have to come [43:23] first another thing if I might add to [43:25] that is that [43:28] um some kinds of [43:31] things when you get them done they [43:34] increase your velocity and some things [43:36] are attacks and that's an example of [43:38] attacks so um if we make the compiler [43:42] faster that just benefits us from you [43:44] know forever if we add language server [43:48] to the compiler then that's more that's [43:50] like a big component that then has to be [43:53] um maintained and kept working uh like [43:56] every time we want to rework the memory [43:58] layout or this or that um it's like a [44:01] tax on how like you know you add more [44:03] lines to the code you have to edit those [44:04] lines when you want to make a change so [44:07] um and for me I use Vim I don't use LSP [44:11] so actually like it's a pure tax it's [44:13] not actually going to help me navigate [44:15] the zig codebase anymore um so it makes [44:20] sense to choose a strategic time to make [44:22] that investment yeah um oh so this one [44:25] is a question much more in the weeds of [44:29] the compiler but I think might be [44:30] interesting uh from the perspective of a [44:32] casual Observer I don't know how casual [44:35] but okay let's say casual Observer the [44:37] intern pool changes seemed like a rough [44:40] a tough gutting of the data structures [44:43] in the compiler how difficult was it to [44:45] actually land that change were there [44:47] unexpected issues or was it just a bunch [44:49] of [44:52] drudgery [44:54] um h trying to find I'm trying to see if [44:57] I have uh the pquest like still open [45:00] because it's [45:02] uh yeah I think I do There It [45:05] Is by the way this is like a question [45:08] from the most casual Zig [45:10] [Laughter] [45:11] Observer who was it it's from scoop [45:16] 018 oh okay I didn't recognize that uh [45:19] yeah this this is the change set being [45:21] referenced and uh you can see it's uh [45:23] almost 30,000 [45:24] lines usually if you see these kinds of [45:27] changes it's because someone like [45:29] vendored something um that's not the [45:31] case here this is actually like every [45:33] line is a line that some like I edited [45:36] um or Jacob or Matthew helped me with so [45:40] yeah it was a massive [45:41] change [45:43] um what's I think it's an interesting [45:47] question because the question was did [45:48] something unexpected happen and the [45:51] answer is no um it required a rework [45:56] but it just kind of went according to [45:58] plan um there was a couple issues where [46:02] I designed some of the types in with a [46:04] little foot gun in it a little pointer [46:06] that would get invalidated in [46:08] inconvenient way and then later [46:10] mitigated that um or not mitigated later [46:13] I just changed that type so that that [46:15] foot gun didn't exist anymore um so I [46:19] made that mistake in this Branch but I [46:21] mean that wasn't really I wouldn't even [46:24] say that was like a big unexpected thing [46:26] so in other words um this took about a [46:28] month and it was a massive change and it [46:31] did create some bugs as a Fallout which [46:34] is expected for this many changes um but [46:37] ultimately I think it does show how [46:41] refactor and how reworkable Zig code is [46:44] because I mean ultimately it went pretty [46:46] smoothly and it wasn't I wasn't like [46:49] scratching my head the whole time it was [46:51] kind of [46:52] straightforward uh and then everything [46:54] everything worked so I don't know I [46:56] don't know what kind of velocity other [46:57] projects have like how long would it [46:58] take to do a 30,000 line diff would it [47:00] take a month would it take more than a [47:02] month would they just never attempt it I [47:04] feel like in a C++ code base like lvm [47:07] for example they want to do stuff like [47:09] this and they just can't I'm pretty sure [47:12] that's the case like they have all these [47:14] things that they want to do they're like [47:16] oh we should have done untyped pointers [47:19] or those type or or this or that and [47:21] they they did land the untyped pointers [47:22] change I think that took like five years [47:24] or something that was a change about I [47:27] think that's pretty comparable actually [47:29] so I feel like this this change is like [47:32] pretty comparable to L ofm trying to [47:33] land on type pointers took me a month [47:35] with two people helping me took them I [47:38] don't know five years with like hundreds [47:39] of people working on it so I don't know [47:42] I think it's a good example of what how [47:43] Zig is actually pretty hackable pretty [47:45] pretty malleable after you've even even [47:47] after you've accumulated a lot of [47:52] code um okay uh next question [47:56] question oh this one is really good uh [48:00] I'm interested in contributing [48:01] optimizations to the Z compiler [48:03] eventually uh when can I do that will [48:05] there be a separate IR is there any [48:08] design for this part of the compiler [48:09] done [48:10] already uh that's a good [48:13] question um so that's one of those [48:15] things where it might uh behoove us [48:19] to start something even though we don't [48:22] intend to follow through right away so [48:24] that we can uh un lock people like you [48:27] the person who asked the question from [48:29] contributing [48:31] so um to answer your [48:34] question uh I don't know whether there [48:37] will be a new [48:38] IR um one thing that I would like to do [48:42] is learn more about quick from [48:46] um a guy who goes by [48:50] negate so this is someone I've met in [48:52] person and [48:54] um he he's done a lot of research into [48:57] making not only a fast compiler but a [49:00] fast optimizing compiler um and he has a [49:04] lot of really interesting uh he's done a [49:06] lot of interesting work on this like sea [49:09] of nodes concept and [49:12] um uh so anyway I want to look into um [49:16] negate strategy for optimization and do [49:19] a little bit of research on my own it's [49:21] an area where I don't have a ton of [49:23] experience so I'm not giving you a super [49:25] solid answer but um this is a good lead [49:29] um uh especially because I don't know if [49:32] negates watching but if we if we do his [49:35] uh strategy he might be tempted to [49:37] contribute as well [49:39] so um anyway long story short I do think [49:44] that it could be a good investment uh [49:45] for for the zig project if we added our [49:49] first uh if we added optimization to the [49:52] pipeline got it going so that it was a [49:54] place that you could start to contribute [49:55] to um but that's going to require a lot [49:58] more tooling we're going to need to have [49:59] more testing on passes we'll need to [50:02] have more introspection on the pipeline [50:04] so it's a big project U but it's [50:06] definitely [50:09] coming okay let me see uh I think we [50:12] have let's do one last question by the [50:14] way in the meantime uh Hector uh Jam [50:17] donated $50 to the Z Foundation thank [50:19] you very [50:21] much uh so the question is um oh oh I [50:26] scrolled and I lost [50:28] it okay I found it how can I persuade um [50:32] my company for a company uh to use Zig [50:36] instead of C in production knowing that [50:38] Zig isn't doesn't have a stable spec as [50:40] of [50:41] now ask for forgiveness instead of [50:46] permission right the python way [50:50] uh uh but I'm not I'm not actually [50:52] joking but in a more um serious tent of [50:55] voice [50:57] uh I don't know how old you are in your [50:59] career but um if you're young that's a [51:01] serious advice uh if you're older and [51:03] you already knew that then uh maybe a [51:06] more nuanced answer is uh you can [51:09] perhaps start to use it for like Dev [51:11] tooling um so trying to put it in [51:14] production that's a harder thing to get [51:17] to get by but um there's a lot of code [51:19] that you use at your company that's not [51:21] running on users computers or you know [51:24] tied to the main sorts of come um and [51:27] these things typically no one really [51:29] cares what language they're written in [51:30] or how they work so if you [51:33] just uh you know you get your normal [51:35] work done for the day uh and then just [51:38] as a side project um just rewrite or [51:42] improve or just change something that's [51:44] not like you know running on the [51:46] consumers's or not running in like the [51:48] main line of what gets your company [51:49] income and you just you make a you make [51:52] an actual Improvement to the software [51:53] right you don't just change it for [51:56] uh just to change the language it's got [51:57] to be like oh now it's faster or now it [51:59] has this new feature or you know [52:02] whatever um people are gonna say oh [52:04] great you know thank you they don't even [52:06] care whether it's for n Zig or [52:09] not yeah from my perspective um you know [52:13] because people do ask me this question a [52:15] lot and they expect me to actually like [52:17] give them practical advice all the time [52:20] um if you think about it like a [52:23] uh okay having a spec directly is [52:26] important like in the long run but in [52:29] day in the day to day in from day to day [52:32] like on your daily stuff it doesn't [52:34] really matter much uh Cas in point there [52:36] are plenty of programming languages out [52:38] there that are gaining traction that do [52:40] not have a set a spec and um and people [52:44] get by um but also when you look at the [52:46] version like people also as Andrew was [52:49] saying sometimes think that they want to [52:50] wait for one version 1.0 but if you [52:52] think about it version 1.0 it's like a [52:54] stream r that so technically can be as [52:57] long as you want but in practice it's [52:58] just like a handful of bites at a time [53:01] and that many bites are not nearly [53:04] enough to describe the state of Zig [53:07] compared to the other programming [53:09] languages out there like that is more [53:11] nuanced information that you need to go [53:13] get yourself make a mental make make [53:16] your own idea of where Zig stands [53:19] compared to the Alternatives and what [53:21] the trade-offs are and usually what [53:22] helps with that is also practical [53:24] experience as in using Zig yourself uh [53:27] to do stuff and actually experiment and [53:30] try out if your things work or don't [53:32] work and whatnot um and ultimately then [53:36] in a company uh what what matters is [53:39] your ability to be able to convince [53:41] people that your mental model of where [53:43] Zig stands is is good enough uh these [53:47] are the two these are the two variables [53:49] so uh again thinking 1.0 it's like [53:53] you're over reducing the the while the [53:56] actual problem statement is um in any [53:59] case uh I think uh nodejs was on 0.8 [54:04] point something for a long time if I [54:06] remember correctly uh they had not [54:08] tagged 1.0 um and a lot of companies [54:11] were betting on it it was like massively [54:14] popular uh and it bothered people they [54:16] wanted it to tag 1.0 there was even a [54:18] fork U they felt like it was stagnating [54:20] but people built their businesses on it [54:22] because it was stable you know it's um [54:27] it's more nuanced than a number yeah [54:28] it's a good way to put it yeah uh so by [54:31] the way uh palmo donated $50 thank you [54:33] very much Captain wait Captain undefined [54:36] Behavior okay so we had an undefined [54:39] Behavior I think um that used to to [54:44] watch your streams I think Andrew now we [54:45] have Captain and theine behavior so [54:48] thank you for I'm not afraid of Captain [54:49] undefined [54:51] behavior in Zig it's called illegal [54:53] Behavior anyway [54:56] uh so thank you very much uh okay so [54:59] okay through real oh spear onl thank you [55:02] $100 to the Z Foundation thank you very [55:04] much thank you everybody so um okay [55:08] final question for real and I I decided [55:10] to ask you this because uh a few people [55:12] asked it so in various ways but people [55:16] were wondering so they have watched [55:18] Martin's talk from software you can love [55:20] Vancouver and they were wondering if [55:22] there have been any update to [55:25] uh your to the problems presented in [55:28] that [55:30] talk uh nope no update um as far as I'm [55:33] concerned it's not actually an issue in [55:36] practice like it's an issue [55:38] for uh before we tag 1.0 it's an issue [55:41] to sort out with the language but um it [55:44] just actually doesn't cause that many [55:46] problems in actual code um so it's just [55:50] not really high priority uh and I don't [55:53] want to it's been kind of [55:55] weirdly popular to talk about in like [55:57] the tech Circles of Zig uh which I mean [56:00] I get it's kind of scary it's like oh [56:02] what if I use Zig and this happens to me [56:04] um but uh I don't want to just react to [56:08] you know it being a Hot Topic and throw [56:10] some Band-Aid in there I'm gonna do it [56:12] right um and I still I still think I [56:16] have a chance to solve the problem in a [56:18] way that not only avoids the potential [56:21] foot gun but also um makes you able to [56:24] WR optimal code that can be perfectly [56:26] optimized I haven't given up on that yet [56:29] um but that's going to require a little [56:30] bit of tinkering a little bit of [56:32] experimentation um a little bit of [56:34] language work and I really want to be [56:35] able to focus on it without being [56:37] distracted by all the other stuff I'm [56:39] working on so yeah basically I've just [56:41] been putting it off until I can give it [56:43] undivided attention um but I don't know [56:47] I I be very interested to hear [56:50] from [56:52] specifically this set of people [56:55] right [56:57] here the people who've bothered to like [57:00] write down what problems they have with [57:01] Zig uh for example tiger [57:04] beetle um not that [57:08] they they do mention this actually so [57:12] that's that's actually this is an [57:13] example of what I'm saying I'm [57:14] interested to see this point here yeah [57:17] but I think for them these issues are [57:19] sorted by priority so they are [57:21] explicitly saying that everything above [57:22] that line has higher priority for them [57:25] okay yeah yeah yeah and and Matt CL has [57:28] also expressed in like Zig it.d that [57:30] actually this is like not really [57:32] affecting them too much in practice so I [57:35] don't know like it's an open issue I'm [57:37] not denying it but I'm just saying like [57:39] you know all this other stuff I agree is [57:41] more important you know um like for in [57:44] their opinion it's more important that [57:46] we deal with the fact that like the plus [57:48] operator can cause illegal Behavior Uh [57:51] and I agree with that actually so I [57:54] don't no I have a different opinion [57:55] about what the priorities are than you [57:58] know than the than the the tech uh the [58:01] tech sphere than the news [58:03] cycle okay makes sense and I think with [58:07] this we can call it a day uh Andrew is [58:12] there anything else you want to share [58:14] before we end the [58:17] show um I think I'll just say one more [58:20] thank you to everyone who's donating [58:22] because um I've been doing this for a [58:25] few years now full-time and uh I just [58:28] really appreciate being able to work on [58:31] um work on Zig fulltime and [58:34] um I I love I love serving users and I [58:37] love making everyone happy and trying to [58:39] make everyone's code good um and I [58:42] really appreciate that people trust us [58:44] with their um with their donations to [58:46] make that happen for them so thank you [58:49] awesome thank you very [58:50] much so we are at the end of the show [58:53] thank you everybody for stopping by and [58:56] uh checking out the road map uh please [58:58] if you want to continue the discussions [59:00] uh join isy Community uh normally I [59:02] would say to people join the zig [59:04] Showtime Discord server uh but in this [59:06] case the discussion is probably uh [59:08] interesting enough for everybody in an [59:10] anyy community so uh I hope you had fun [59:13] and uh thank you again for the donations [59:15] thank you also for the new people that [59:17] donated he Jam donated um $50 more uh El [59:22] cob 32 thank you everybody and uh I'll [59:25] see you soon with another Showtime [59:27] episode [59:32] [Music] [59:53] byebye [59:56] [Music] [60:21] we