源代码可用性该由谁买单？
Zig 语言作者 Loris Cro 用自身项目经历指出 GitHub/Codeberg 宕机会导致构建失败，提出 Radicle 去中心化 P2P 网络可作为替代方案——通过节点种子机制让代码可靠可用，同时讨论成本分摊问题。文章对比了 forking/vendoring、Codeberg/Forgejo 与 Radicle 的架构差异，并建议 Zig 包管理器支持 Radicle。 
评论
点赞
收藏你必须修复你的断言（assert）
软件工程中一个普遍但有害的做法：在生产环境禁用断言（assert）。本文以 Zig 语言为例深入剖析断言机制，指出关闭断言会让你对自己编写的代码产生错误的安全感——错误的断言未被发现，后续代码继续在错误假设上叠加，最终埋下可利用的安全漏洞。作者结合 Ghostty 两个无需内存破坏即可远程执行命令的真实 CVE、TigerBeetle 始终开启断言、自己的 Zine 和 Awebo 项目等案例，论证了比禁用断言更好的选择是修复断言本身，并在不同构建模式间切换以获得性能或安全收益。核心观点清晰有力：断言不是可以随意开关的调试工具，而是编译器可以信赖的代码公理。对关注软件正确性、系统安全与编程实践的中高级开发者而言，这篇有个人立场、有技术细节、有真实案例的文章极具讨论价值。
Zig与LLVM的新关系（2020）
Zig语言正迎来里程碑式转变：从依赖LLVM后端的C++编译器，迈向纯Zig实现的自托管编译器，使LLVM成为可选依赖。核心亮点是专为调试构建设计的增量编译+原地二进制补丁（in-place binary patching），能将当前占编译时间70%以上的LLVM步骤几乎降为零。文章详细解释了这项罕见技术的设计思路——位置无关代码、全局偏移表、DWARF调试信息分配方案，并指出这套机制已能覆盖90%的热代码替换能力。自托管后端将在Zig 0.7.0中作为可选功能发布，目标在0.8.0完全取代C++实现。对编译器设计、系统编程、Zig语言感兴趣的读者，这是一篇难得的深度技术解析，信息密度和原创性俱佳。
在 Zig Days 上，请少谈 LLM
Zig 语言社区核心成员 Loris Cro 发文呼吁，在社区协作编程活动 Zig Days 上应主动限制关于大语言模型（LLM）的讨论和使用。Zig Days 是每月一次的线下协作编程活动，参与者自发组队或独立完成项目。作者认为，当下 LLM 相关话题正在"吸走房间里所有的空气"，挤占了数据结构和算法、问题求解方法等更值得深入交流的内容。同时，他建议参与者遇到问题先问身边的人，尽量手写代码，不要用 AI 代劳，以免浪费宝贵的学习机会。即便未来商业软件完全由 AI 驱动，Zig Days 依然是为享受编程本身的人而存在的。他提醒组织者应在活动开始时明确传达这一理念，但不必极端禁止，让大家自觉珍惜这个难以替代的面对面交流场景。
如何写出更多博客文章（2024）
一位资深软件工程师分享自己克服写作障碍的"心智热力学三定律"：第一，必须内心真正相信写作有价值，捷径是把"为获得关注而写"作为策略，借助社交反馈校准内在动力；第二，技术文章走红的关键是教会读者新东西，找到读者当前认知位置（X）并帮他们推进到X+1，太浅或太深都无效；第三，好文章需要把握时代精神并超出平均水平一点点，但越是专家，受众越窄，需要更努力找到让更广人群真正获益的新视角。作者还给出了具体战术建议：自建独立博客（推荐自己写的Zine SSG）、控制篇幅在1000–1600词、多渠道主动推广，并直言LinkedIn的写作风气是"地狱级别"，鼓励脱离平台依赖。文章有鲜明的个人立场、反直觉的观点和真实行业观察，适合想提升技术写作动力的开发者阅读。
Scripty：极简嵌入式脚本语言的设计与反思
作者分享了自己亲手打造的一门极简脚本语言 Scripty——故意没有循环、没有 if、没有变量赋值，整个程序只是一个单一表达式，专为嵌入字符串和模板充当查询语言而设计。作者在静态站点生成器 Zine 中长期实际使用它，最近才认真优化使其对他人可用。文章深入交代了设计动机（痛恨花括号宏模板语言，认为模板应分离表达式层与文档层）、VM 实现细节（栈式解释器 + MultiArrayList 优化）、以及同一语言在 SuperHTML 和 SuperMD 中两种截然不同的用法（导航式 vs 构造器式）。结尾展望了静态分析、语言服务端自动补全、编译到 Zig 等方向。全文有明确技术立场（"I hate macros"）、一手踩坑经验、以及可复用的嵌入式 DSL 设计思路，适合对模板引擎和领域特定语言感兴趣的读者。
在SQLite查询中实现编译时列名安全检查
一位Zig开发者分享了用约20行代码为SQLite查询添加编译时列名安全校验的实战方案。核心做法是利用Zig的comptime机制，在编译期解析SELECT语句提取列名并构建哈希映射，让(.id)替代容易出错的(0)。作者明确承认这并非完整的SQL解析器，但对自己的项目"足够好"——失败模式（如遇到SQL函数）会直接产生编译错误而非运行时诡异行为。文章更宝贵的价值在于末尾的反思：复杂度和抽象总是有代价，一个简单但恰如其分的解决方案，往往优于庞大完备的方案，前提是你清楚自己的需求。文中还对比了zig-sqlite（完整SQL解析但comptime重）和zqlite.zig（薄封装、自由度更高）的取舍，并讨论了构建时生成代码、调试模式未使用列检查等替代思路。
用 Zig 维护 C/C++ 基础设施
本文提出一个反主流的观点：与其追随「Rewrite It in Rust」风潮重写 C/C++ 基础设施，不如用 Zig 作为工具链来改善旧有生态的开发者体验。作者是 Zig 核心贡献者 Loris Cro，他认为系统编程门槛高、构建工具混乱（Make/CMake/Autotools）、交叉编译困难才是新人却步的根源，而不是 C/C++ 本身不可救药。Zig 提供 zig cc/zig c++ 替代编译器、ZLD 链接器和 zig build 构建系统，无需 Xcode/MSVC/build-essential 即可跨平台编译。以 Redis 为例，展示从替换编译器到加入 Zig 编译单元实现新功能的完整路径。文章有明确的个人立场、具体的工程案例和可操作的技术路径，不是空洞的生态文章。
Zig 新异步 I/O 设计解析
核心看点：Zig 核心贡献者 Loris Cro 详解下一代异步 I/O 重大重构，宣布"彻底击败函数着色问题"。新引入 Io 接口让调用方注入具体 I/O 实现，如同 Allocator 模式，从此一个库无需维护同步/异步两套代码。代码示例逐步展示如何通过 io.async + Future.await 表达并发，并原生支持取消操作。标准库将提供四种实现：阻塞式（生成等价于 C 的机器码）、线程池（多线程并行）、绿色线程（基于 io_uring 的栈式协程，首批支持 x86_64 Linux）、无栈协程（兼容 WASM，依赖新的函数调用约定重写）。设计上关键突破：运行时不再强制无栈协程，io.async 可用任意执行模型；Writer 接口新增 sendFile 和向量化写入 + splat 语义，链式传递时仍能利用 sendfile 等内核零拷贝能力。部分变更进入 Zig 0.15，完整落地需等到下一发布周期。文末附 FAQ 澄清：普通顺序代码无需改造即可兼容新系统，asyncConcurrent 在单线程阻塞实现中会 panic 属于编程错误。适合对系统编程、语言设计、异步 I/O 演进感兴趣的技术读者。
Zig 的编译期执行（Comptime）详解
Zig 语言的 comptime 机制远超传统宏和泛型——作者用大量可运行代码示例，逐步展示编译期函数调用、编译期代码块、循环展开与分支消除、泛型函数与泛型结构体、以及基于类型反射的返回值推导等高级用法。文章还引用标准库中 parseInt、sqrt 等实际实现，说明 comptime 如何让开发者写出既高效又易维护的底层代码。来自 Zig 编译器作者团队的 Loris Cro，内容扎实、逻辑清晰，是理解 Zig 元编程能力的优质技术文章。
Zig Day 协作网站正式上线
Zig 语言核心开发者 Loris Cro 分享了如何用纯静态网站 + GitHub CODEOWNERS + iCalendar 模板，零后端零 FaaS 实现全球 Zig Day 活动的分布式协作管理。核心思路：利用 GitHub 分支保护和 CODEOWNERS 文件，让各地组织者通过 PR 自主创建和更新活动，无需中央后端或管理员手动合并。每个 Zig Day 自动生成 RSS 和可订阅的 iCalendar 日历文件，再通过 Buttondown 实现邮件通知。文章有完整的实现细节和源码链接，对静态站点技术、去中心化活动管理或 Zig 社区感兴趣的读者值得一读。米兰首届 Zig Day 即将举办，也欢迎在其他城市发起本地活动。
用 Zig 实现超级简单的快照测试
本文作者分享了自己在 Zig 静态站点生成器 Zine 中实现快照测试的实战经验。核心思路极简：用 git diff 做测试断言，自动生成并更新预期输出文件。作者给出了完整的 build.zig 代码、目录结构和工作流示例——当输出变化时，git diff 自动比较，空 diff 即通过，否则开发者需确认变更意图后提交新快照。文章强调快照测试有效性的关键：diff 必须易于人工审计。这套方案不依赖额外库或工具，仅需 git，适合以文件为输入/输出的项目。对于关注 Zig 开发、测试实践或静态站点生成的技术读者，这是一篇有真实代码、能直接参考的一手经验分享。
你的全部代码库
个人项目 AYC（allyourcodebase）为 C/C++ 项目收集 build.zig 构建脚本，让你只用 zig build 一条命令就能编译运行原本构建复杂的 C/C++ 项目。作者以经典游戏 VVVVVV 为例展示效果：仓库里只有 build.zig 和 build.zig.zon 两个文件，依赖自动下载。Zig 构建系统本身也是包管理器，可暴露模块、可执行文件、库和头文件。项目目标一是方便 Zig 用户，二是向 C/C++ 维护者展示 Zig 构建替代方案。欢迎带着可迁移 C/C++ 仓库的贡献者加入组织。作者还特别指出创建 AYC 的另一原因：避免 C/C++ 项目维护者被过度施压添加 Zig 支持，希望以温和方式共建生态。
用 Zig 挑战 Advent of Code 实战指南
Loris Cro 为想借 Advent of Code 尝试 Zig 的开发者写了一篇非常接地气的实战指南。从开发环境（Zig 0.13.0、ZLS 配置、zig fmt 自动格式化）到具体编码技巧：使用 @embedFile 编译时嵌入输入数据、用 tokenize/split/window 高效解析文本、字符串比较与整数解析、自定义位宽整数与哈希表选型等，每个要点都附有可直接复用的代码片段。文章最有价值的部分是末尾的坦诚提醒——AoC 本质是一次性脚本解题，输入不会出错、不需要考虑错误处理与内存布局，而这些恰恰是 Zig 真正的优势所在。作者直言把 AoC 当作学习 Zig 的唯一途径会错过 Zig 在系统工程、错误处理和资源管理上的亮点，建议找更具体的工程项目来真正体会 Zig 为何是 game changer。整篇有实践经验、有明确立场、有可复制代码，不是空洞教程。
RAII 与 Rust/Linux 内核之争
Rust/Linux 内核之争的核心不只有情绪冲突，更藏着一个深层技术分歧：RAII（资源获取即初始化）。作者从 Asahi Lina 等一线 Rust 内核开发者的抱怨切入，指出他们推动的 RAII 模式恰恰是 Linux 内核多年来刻意回避的编程范式——当年 Linus 封杀 C++ 进入内核，理由之一就是这类抽象带来的性能与复杂度代价。文章引用 Casey Muratori（批处理 vs 单对象管理）、Mike Acton（面向数据设计）等多场经典演讲，论证 RAII 在批量操作、内存竞技场等高性能场景下的固有劣势，并类比美国大使误以为丹麦人骑车是因买不起车，暗指 Rust 一方可能并不真正理解内核社区为何拒绝 RAII。作者本人正在将 C/C++ 构建脚本移植到 Zig，有切身观察，立场鲜明但不失论证层次，适合对编程语言设计、系统编程、内核开发有興趣的读者引发讨论。
写给还不信的人：Go 确实有异常机制
对不承认 Go 有异常（exception）的开发者，本文用真实代码证明 panic/recover 就是异常机制：doA panic 后 foo.b 保持未赋值，但 Go HTTP server 会 recover，导致损坏的对象状态残留。解决方案是像 Java 一样防御性编程——先算局部变量再统一提交赋值。作者还指出 Go 在栈展开时执行 defer 的设计不完整，反而让人放松对 panic 的警惕。全文有立场、有可复现代码、有实际工程影响，不是空谈理论，是值得 Go 开发者阅读和讨论的技术观点文。
是的，Go 语言确实有异常机制
Go 社区常声称 Go 没有异常，但本文作者尖锐指出：Go 的 panic/recover 本质上就是 throw/catch 异常。作者直接引用 Go 标准库中 regexp 解析器用 panic/recover 作为控制流的实际代码，并分享在 GoLab 2022 上当面询问 Go 核心团队成员得到的答复——你必须假设所依赖的代码（包括标准库）可能尝试 recover。更微妙的是，即使你自己从不调用 recover，依赖代码（如 net/http）也可能在回调上层代你 recover。作者认为 Go 用户普遍意识不到自己语言有异常，这是 Go 营销与学习体系的缺陷。文章来自 Zig 社区成员，有现场一手交流、具体代码证据和明确个人立场，是一篇能引发讨论的技术观点文。
Zig 社区的关键社交基础设施
Zig 社区核心成员 Loris Cro 直言：商业社交平台不断恶化（从 Andrew Kelley 因广告将编译器讨论迁至 Zulip，到 Stephen Gutekanst 离开 Twitter 痛惜技术短内容流失），正在割裂原本分散但需要协作的 Zig 社区。他提出一套可立即落地的方案——鼓励每个 Zig 项目创建自有 devlog（微型博客），维护者自主掌控内容，通过 RSS 订阅和 Simplex 等工具自动分发到主流平台，兼顾内容主权与曝光。文中给出 和 作为参考案例，并指出 devlog 的条目可精选、可包含 commit message 装不下的洞察、可被 RSS 拉取到 Discord 等社区空间。作者坦言这只是第一步，后续还需自托管的 RSS 聚合方案。文字真诚有个人观察，有具体行动建议，不是泛泛而谈的趋势文章，适合关心开源社区治理和 Zig 生态的读者。