Zig 创始人直言不讳，Anthropic 虚张声势

# Zig 创始人直言不讳，Anthropic 故弄玄虚 来源：https://raymyers.org/post/zed-creator-calls-spade-a-spade/ > 我用小船骚扰大海，被称为海盗；你用舰队兴风作浪，却被尊为国王。 **Anthropic 正在积极推动终结软件工程**。他们需要你相信他们能做到这一点。嗯，也许他们需要说服的不是你，而是你的高管、各国的领导人，或者你的养老基金管理人。他们已筹集 1320 亿美元投资，并正以超过 1 万亿美元的估值筹备 IPO。由于无法展示盈利能力（https://www.wheresyoured.at/anthropics-profitability-swindle/），这一切都依赖于兜售他们假设的未来影响力。 用文学术语来说，Anthropic 是一个*不可靠的叙述者*。 他们的关键叙事之一：编码正在消失，然后是软件工程的其余部分（https://youtu.be/02YLwsCKUww?si=NCcT1_VEm4g4NjZw&t=97），最终是大多数其他人类劳动（https://www.cfr.org/event/ceo-speaker-series-dario-amodei-anthropic）。这种故事背后有如此巨额的资金，无论我们认为这个故事有多真实，它都会产生影响。 人们会根据这些事件做出架构、产品和人员配置决策。许多决策将基于恐惧——对裁员的恐惧，对被“抛在后面”的末日预言式警告（https://www.nytimes.com/2026/06/17/opinion/ai-dangerous-openai-anthropic.html?eafs_enabled=false）等等…… 要做出正确决策，我们需要清醒思考，而当下这很难。戴上你的怀疑之帽吧。 观点仅代表我个人。我与 Zig 没有任何历史渊源。我从未与 Andrew Kelley 交谈过，但他最近的JetBrains 访谈（https://www.youtube.com/watch?v=iqddnwKF8HQ）非常值得一看。 我关注的是公众对 AI 在软件领域应用的理解。这是我三年来职业生涯的重点，同时也在改进技术本身。其中一半时间我担任一家编码代理初创公司的首席架构师——既是 Anthropic 模型的客户，也是其代理 Claude Code 的竞争对手。我当前的项目是The Coding Agency（https://www.thecodingagency.org/）。 ## 我们说到哪了？ 本周，Anthropic / Bun 发布了关于将 Bun 从 Zig 移植到 Rust 这一决定的解释（https://bun.com/blog/bun-in-rust）。这份解释是在合并迁移到主线两个月后发布的。在像这样的基础设施项目中，事先解释方向本应是更传统的做法，但延迟却巧妙地让这个故事被诸如《The Register》的标题“Anthropic 的 Bun Rust 重写以 AI 速度合并”（https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381）这样的性感头条所传递。大量投资。非常精彩。 Zig 的创始人 Andrew Kelley 现在发布了一份回应（https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html），分享了他自己的想法。它直言不讳，达到了不寻常的程度。这在观感上是有问题的。一般来说，你不会希望当你切换编程语言时，第二天早上醒来却发现旧语言的领导者正在数落你的个人缺陷。正如 Dax 搞笑地（https://www.linkedin.com/posts/thdxr_guys-we-have-a-pretty-substantial-opensource-share-7481579102622216192-E4-Q/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAB7o1UBSVk_MWfFO9AbldIjAI4xeROkC8k）所说： > 伙计们，我们有一个相当庞大的开源 Zig 代码库，我好害怕他会来看它。 尽管如此，当我阅读 Andrew 的文章时，我发现自己*大声欢呼*。我可能还在房间里跳了一会儿。有些人称他的观点是“崩溃”，我只能说他今天又赢得了一位新粉丝。 有时候有些事需要被指出来。 ## 什么是模范行为？ 在我状态最好的时候，我会追求类似佛教的“正语”（https://tasshin.com/blog/reflections-on-buddhist-right-speech/），这是一个高标准，要求我们说的每句话都要满足以下所有五条标准： - 是真实的吗？ - 是有帮助的吗？ - 是合时的吗？ - 是友善的吗？ - 是否*源于*善意？ 我们有点打破常规，涉足了“真实，但不友善”的领域。我在为某个人选择这样做辩护。我并非轻率地这样做，并希望这能有所帮助。 ## 背景 简要更新一下…… - Bun 是一个 TypeScript 运行时，类似于更快的 NodeJS。 - Zig 是一种系统编程语言，类似于现代的 C。 - Bun 之前是用 Zig 编写的——是最大的 Zig 代码库之一。 - Bun 声称近 100%（https://x.com/jarredsumner/status/2054525268296118363）的代码由 AI 贡献。 - Zig 允许 0%（https://ziglang.org/code-of-conduct/）的 AI 贡献。 - Bun 被领先的 AI 模型实验室 Anthropic 收购。 - Bun 的创始人尝试了大规模的智能体驱动重写，从 Zig 到不安全的 Rust。 - 这个实验几天后就被合并，现在已是官方版本。 这种情况在多个方面都存在争议，尽管显然相关方实际上并不希望 Bun 继续留在 Zig。戏剧性完全存在于元讨论之中。迁移过程本身相当有趣，在合适的情况下我也会考虑做类似的事情。 ## 该相信谁 当人们在项目中面临 Zig 和 Rust 的选择时，自然会视 Bun 的情况为一个数据点。最大的 Zig 用户之一最终改变了决定，这一事实感觉相关，无论原因如何。人们会试图理解发生了什么，并判断哪个更真实： > **Anthropic/Bun 的故事**：Bun 尝试了一切合理的方法，但仍然被内存错误所困扰，因为 Zig 无法胜任任务。 > **Andrew 的故事**：Bun 的代码是一团糟，因为他们的工程决策，包括过度使用 AI 代理来编写和审查所有内容。 我倾向于后者，但我怀疑主导因素更无聊： > **Ray 的故事**：面对内存错误的合理挑战，有几种可行的方案。管理层热切批准了 Rust 重写的选项，因为这是一个绝佳的营销机会，可以展示他们新的 Fable 模型，Anthropic 已经在使用 Rust（https://www.anthropic.com/careers/jobs），而且 Zig 公开反对使用 Anthropic 的产品。 这在商业上完全合理，只是不是一个营销故事。营销需要侧重于他们的 AI 如何强大到足以完成这次重写（尽管它甚至不够强大到能捕获一个 use-after-free 错误）。 无论好坏，这个包袱现在在 Rust 与 Zig 的问题上占据了首要位置。这种情况往往让社区在评判 Jarred 的判断与 Andrew 的判断之间产生对立。通过 Anthropic 的扩音器播出的任何挽回面子的夸张言论，都可能无意中影响 Zig 的声誉。 我能理解为什么 Andrew 会决定“补充一些背景”，而不是任由事态发展。 ## 这是诽谤吗？ 从我的角度来看，Anthropic 是我们需要追究责任的一方。这才是关键所在。Bun 创始人 Jarred Sumner 在某种意义上成了夹在中间的人。Zig 也是如此。 如果这件事能严格在技术层面讨论，那会很好，我们也会谈到。然而，我认为 Anthropic 并不是在做技术论证，他们是在制造奇观。 Anthropic 利用 Jarred 的可信度来帮助兜售他们的叙事。作为回应，我们也在评论他的可信度。这很混乱。我不喜欢这样。 尽管如此，如果报道某人所说所做的一切看起来像诽谤，那么也许那些行为本身也是问题的一部分。 ## 绞肉机 我对 Bun 项目的第一印象来自 2022 年的公告，其中包含对求职者的警告： > Oven 将是一场艰苦的战斗，尤其是最初的九个月左右。如果工作与生活的平衡意味着大量时间不工作，那可能不太适合。 当我看到潜在经理说出这样的话时，它说明了若干问题，其中之一就是“这个人完全不知道自己在做什么”。很多相当不错的程序员从未见过好经理的榜样，并且对管理抱有一些奇怪的想法。 一直处于“冲刺”状态对健康和生产效率都是有害的。这是关于知识工作的一个已被充分证实的事实。一些参考资料，请参见 Hillel 的实证软件工程（https://www.hillelwayne.com/talks/ese/）中的人为因素部分。 我的建议？不要为那些吹嘘每周 90 小时工作（https://x.com/jarredsumner/status/1544821137128927232）的人工作。要为那些会捍卫你睡眠能力的人工作。 在 Andrew 的文章中，他总结了自己从小道消息听到的 Bun 团队的经历： > 沟通不畅、期望不切实际、缺乏同理心、没有经验。简直就是一团糟。 我的意思是……当然是这样。这些道听途说基本上在重复公开宣布的内容。他们的招聘信息上还不如写着：“现招募浑水摸鱼者”。我们公开这样说是不礼貌的。我们本该让那些科技兄弟继续吹嘘抄近路是某种天才生产力技巧。然后那些听信他们的人最终可以请我们来收拾烂摊子。如果我不那么在乎结果，这将是一个很棒的安排。这非常有利可图。 顺便说一句，我用过 Bun 几次，感觉还不错。酷炫的技术往往是在糟糕的工作环境中诞生的。并不是我说他们的环境导致了糟糕且难以维护的混乱，*Bun 自己说的*。 ## 说点好听的 关于迁移过程的文章非常酷，其中包含可复用的细节。没有抱怨，我认为这才是真正的贡献。我特别喜欢他们诚实地解释这是一次移植到不安全（https://bun.com/bun-unsafe-audit）Rust，允许逐文件迁移以最小化风险，为未来步骤的重新设计铺平道路。这是一个明智之举，解释得很好。 语言选择正在变得更容易逆转，这个观点有一定道理。这种方法将在其他类型的重写自动化中占有一席之地，各有优缺点（https://tomassetti.me/ai-rpg-migration-semantic-gap/）。这些技术可以组合起来，并通过形式化方法进一步强化。Darpa 的TRACTOR（https://www.darpa.mil/research/programs/translating-all-c-to-rust）（将全部 C 翻译为 Rust）研究项目今年发布了一份报告（https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/First_TRACTOR_Evaluation_Report.pdf），其中应涵盖当前技术水平。 我最喜欢的关于软件现代化项目的书是 Marianne Bellotti 的《用火杀死它》（https://nostarch.com/kill-it-fire）。随着智能体让我们可以对旧代码执行更多操作，我们仍然需要良好的判断力和沟通来决定方向。接下来我们来谈谈这个。 ## 重写的理由是空话 解释技术决策的基本要素包括： - 动机是什么？ - 你考虑了哪些选项？ - 优缺点是什么？ 这里有一个 Richard Feldman 关于将 Roc 编译器从 Rust 迁移到 Zig 的决定的优秀示例（https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a3992532f）。我最初对这个举动感到震惊（我对语言安全性有些狂热），但最终他的观点是有道理的，这开始引起我对 Zig 的好奇。 当 Bun 的重写被合并时，我曾希望看到类似的处理方式。但我们得到的却是迟来两个月的这个： - ✅ 动机是什么？ - ⚠️ 你考虑了哪些选项？ - 🚫 优缺点是什么？ 给那些有抱负的技术负责人：当你省略这些要素，尤其是“优缺点”时，你可能会给人一种印象：你在思考之前已经有了答案，并且只是在事后找理由。也许你有理由，只是没说。 这感觉不诚实。 ## 只有优点，没有缺点 我们没有看到真正的权衡比较，而是看到了一节“Bun 在 Rust 中更好”，只涵盖了优点。像这样的改变总是涉及权衡，一个明显的权衡就是构建时间。 通常，当你使用 Rust 处理大型代码库时，你用安全性换取更慢的编译速度。这没什么可羞愧的，这可能是一笔划算的交易。过去，这个因素对 Bun 足够重要，以至于他们分支了 Zig 编译器（https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19）试图改进它。如果我们认为 Rust 移植增加了贡献者的构建时间，为什么不披露呢？公开承认影响以及使其成为正确举措的优先级，会显得更可信。 他们似乎还通过混入重写后的其他不相关改进来扩充列表。 ## 他们没有尝试风格指南？ 回想一下，动机是内存错误。这肯定不是 Bun 唯一的错误来源，但很频繁，据我统计每周导致四次修复提交。很痛苦。 理论上，每个内存错误都代表违反了某种约定——关于如何处理这类对象的预期。因此，我们应该建立对每种情况下预期的清晰概念。我们应该努力有效地使用任何语言，Rust 风格指南（https://rust-lang.github.io/api-guidelines/）也是如此，但手动内存管理增加了我们需要满足的预期范围。 其他人是如何解决这个问题的？另一个旗舰 Zig 代码库是 TigerBeetle，一个金融交易数据库。它并没有受到内存错误的困扰，事实上它似乎是现存最可靠的数据库之一。他们会很乐意告诉你，这归功于他们的 TigerStyle（https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md）方法和一些创新的测试策略（https://tigerbeetle.com/blog/2023-07-06-simulation-testing-for-liveness/）。值得一看！“风格”这个词可能低估了它，这是一套完整的工程哲学，Zig 编码指导方针只是其中一个要素。 这里摘取 TigerStyle 的一点。并非每个应用程序都能原样复制这个策略，但它说明了内存分配与其他设计决策之间的关系。 > 所有内存必须在启动时静态分配。**初始化后不得动态分配（或释放并重新分配）内存。** 这避免了可能显著影响性能的不可预测行为，并避免了 use-after-free。作为二阶效应，我们的经验是，与那些在设计中未提前考虑所有可能内存使用模式的设计相比，这也产生了更高效、更简单的设计，更容易维护和推理。 显然，如果我们在权衡是否用 Rust 重写，我们首先应该考虑是否以不同的方式使用当前语言。下面是 Bun 的写作文本如何呈现这个选项的。 > 许多项目选择通过风格指南来回答这类问题。TigerBeetle 的 TigerStyle（https://tigerstyle.dev/）是 Zig 中的一个例子，Google 的 31,000 字 C++ 风格指南（https://google.github.io/styleguide/cppguide.html）是另一个例子。风格指南的挑战在于执行。你如何确保风格指南得到遵循？历史上，代码审查是答案，并通过 linter 和静态分析器进行尽力而为的执行。 我原以为下一句会讨论 Bun 的风格指南，为什么它不起作用，也许它如何随时间演变……结果没有。他们似乎只是对口头上承认社区解决这个问题的主要方式，耸耸肩就继续了。我错过了什么吗？在这样一个规模的项目上花费四年多时间，如果他们经历过这些问题，却从未认真尝试过风格指南，这令人惊讶。这几乎就像一个试图把所有上下文都记在自己脑子里的人运行的项目——我们之前提到过。