本文永久链接 – https://tonybai.com/2026/05/08/bun-founder-abandons-zig-for-rust-ai-rewrite

大家好，我是Tony Bai。

在过去的两年里，Bun 以其闪电般的速度，成为了前端世界挑战 Node.js 霸权的“重量级选手”。

而它成功的秘诀之一，就是其创始人 Jarred Sumner 极其激进、甚至有些“偏执”的技术选型——全面押注 Zig 语言。

当全世界都在用 C++、Go、Rust 这些“主流”语言构建底层基础设施时，Bun 却像一个孤独的叛逆者，将自己的身家性命，全部压在了小众但优雅的 Zig 身上。

但就在前几天，这位“叛逆者”似乎也“背叛”了自己的信仰。

X 平台上的开发者 Luke Parker 突然发现，Bun 的官方 GitHub 仓库里，出现了一个名为 claude/phase-a-port 的神秘分支。点进去一看，所有人都惊呆了：Bun 的创始人 Jarred Sumner，正在将 Bun 的核心代码，从 Zig 迁移到 Rust！

更令人震撼的是，这次迁移的主导者，似乎并不是 Jarred 本人，而是一个 AI Agent。

仓库里一份名为 PORTING.md 的文件，赫然写着给 AI 的指令：

“你正在将一个 Zig 文件翻译成 Rust。在写任何代码之前，请先读完这份文档。A 阶段的目标，是生成一份能忠实捕捉原始逻辑的 .rs 草稿文件——它甚至不需要能编译通过。”

这条消息瞬间引爆了整个技术圈。

• Zig 社区感到被“背叛”和抛弃。
• Rust 社区则一片欢腾，迎来了“又一位巨星的加盟”。
• 而更多的开发者则在问：这背后到底发生了什么？为什么连 Zig 最忠实的信徒，也投向了 Rust 的怀抱？

今天，我们就来深度扒开这场顶级项目的“技术叛逃”，看看在 AI 编程席卷一切的时代，编程语言的选择标准，正在发生怎样翻天覆地的变化。

铁证如山：从 CLAUDE.md 到 2.8 万行代码变更

起初，很多人以为这只是一个愚人节玩笑。

但随着 Simon Willison 等社区大佬的深挖，越来越多的“铁证”浮出水面：

1. 巨大的代码量：这个实验性的分支，在一次提交中就变更了 12 个文件，新增了 2.8 万行代码，这绝不是小打小闹。
2. 写给 AI 的“说明书”：那份长达 622 行的 PORTING.md，极其详细地将 Zig 的指针、分配器、错误处理等核心概念，一一映射到了 Rust 的等价物上。这显然是一份给 AI Agent（很可能是 Anthropic 的 Claude Code）看的“操作手册”。
3. 创始人的亲自下场：所有的提交，都来自于 Jarred Sumner 本人。

种种迹象表明：Bun 真的在严肃地考虑，或者至少是在深度探索，用 Rust 来重写自己的 Zig 内核。

动机拆解：我们为什么要背叛“全世界最好的语言”？

这就引出了所有人都想问的那个问题：为什么？

Zig 语言以其简单的语法、对 C 语言的无缝兼容、以及对底层内存的精准控制而著称。Jarred Sumner 本人也曾是 Zig 最狂热的布道者。

但在 X 平台的激烈讨论中，社区大佬们给出了几个推测：

1. 生态的贫瘠 vs Rust 的(相对)富饶

这是最核心的原因。Zig 虽然优雅，但它的社区生态，相比于已经“枝繁叶茂”的 Rust 来说，依然是一片“荒漠”。

当你需要一个成熟的异步运行时、一个功能完备的 HTTP 客户端、或者一个高性能的序列化库时，在 Rust 的 crates.io 上有很多个经过生产环境检验的“轮子”可用。

而在 Zig 的世界里，很多时候你都不得不“从零手搓”。

2. 人才的稀缺 vs 社区的规模

Bun 作为一个商业项目，需要不断地招聘顶尖的系统程序员。但现实是，精通 Zig 的开发者凤毛麟角，而 Rust 开发者社区的规模，则要大上几个数量级。

选择 Rust，就是选择了一个更庞大、更多元的人才库。

3. 工具链的成熟度

从强大的 rust-analyzer (LSP)，到无所不能的 cargo，再到各种静态分析、模糊测试工具……Rust 的工具链生态，在过去几年里已经达到了一个相当高的成熟度。

而 Zig，在这方面依然还有很长的路要走。

4. 对 AI 的“友好度”

这是一个极其微妙、却又越来越重要的因素。

Rust 强大的类型系统、详尽的错误信息、以及海量的开源代码（作为训练数据），使得 AI Agent 在生成和修复 Rust 代码时，表现得异常出色。
AI 就像一个不知疲倦的实习生，而 Rust 严苛的编译器，就是那个最完美的、能 24 小时进行 Code Review 的“导师”。

AI 作案现场：当“代码重构”成为一种“指令集”

这次事件中最具未来感的，是 Jarred Sumner 选择的重构方式。

他没有去组建一个庞大的“重写小组”，而是把自己的架构思想，沉淀成了一份给 AI 看的“技术规范”。

A 阶段：AI 只管“翻译”，不管对错。
目标是快速地将 Zig 的逻辑，“像素级”地平移到 Rust 文件中。这个阶段的代码，甚至不需要能编译。

B 阶段：AI 负责“修复”，直到编译通过。
在这个阶段，AI 将扮演一个“修复工”的角色，不断地与 Rust 编译器搏斗，修复所有权、生命周期等各种编译错误。

看懂了吗？

这是一种全新的、堪称“流水线”式的 AI 协同开发模式。人类架构师负责定义“做什么（What）”和“怎么做（How）”，而 AI Agent 负责具体的“执行（Execution）”。

反思：在 AI 时代，我们该如何选择技术栈？

Bun 与 Zig 的这次“决裂”，像一面镜子，照出了 AI 时代技术选型的新法则。

法则一：生态的“引力”，正在变得比语法本身更重要

一门语言的语法再优美，如果它的生态里没有足够多的“轮子”，那么在追求快速迭代的今天，它就必然会被边缘化。AI 加速了代码的生成，也同样加速了对“成熟生态”的依赖。

法则二：“对 AI 的友好度”，正在成为一门语言的核心竞争力

一门语言的文档是否完善、错误信息是否清晰、社区代码风格是否统一……这些在过去被认为是“软实力”的因素，在今天，直接决定了 AI 在这门语言上的生产力上限。

法则三：没有永恒的“信仰”，只有永恒的“取舍（Trade-offs）”

Jarred Sumner 对 Zig 的热爱毋庸置疑。但作为一个顶级项目的负责人，他必须在“个人技术品味”与“项目长期发展”之间，做出最理性的、甚至是痛苦的权衡。

在工程的世界里，从来没有“最好的”语言，只有“最合适的”工具。

小结：一场没有硝烟的“换核”战争

Bun 的这次实验性“叛逃”，无论最终是否会合并到主干，都已经为我们揭示了未来十年技术演进的残酷真相：

在 AI 这头“效率巨兽”的面前，所有的技术壁垒、社区信仰、甚至是个人情感，都可能被无情地碾碎。

当你的第三个员工是一个名叫 Claude Code 的 AI 时，选择一个它最擅长、能让它发挥最大威力的语言，似乎成了一个无可辩驳的“最优解”。

这场从 Zig 到 Rust 的“换核”战争，或许只是未来无数场“AI 驱动的技术栈重构”的第一次预演。

下一个，会是谁？

资料链接：

• https://x.com/i/trending/2051505180647227556
• https://github.com/oven-sh/bun/blob/46d3bc29f270fa881dd5730ef1549e88407701a5/docs/PORTING.md
• https://github.com/oven-sh/bun/tree/claude/phase-a-port

今日互动探讨：

你如何看待 Bun 创始人“抛弃”Zig 的行为？是理性的商业决策，还是对开源精神的背叛？在 AI 时代，你认为 Go、Rust、Zig 这三门语言，谁的未来更光明？

欢迎在评论区分享你的看法！

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/03/27/function-type-inference-should-work-in-all-assignment-contexts

大家好，我是Tony Bai。

在这个大模型（AI）写代码如喝水一般简单的时代，你有没有遇到过一种极其憋屈的场景：

你让 Claude Code 或者 Codex 帮你写了一段 Go 语言代码，逻辑清晰，结构优雅，连它自己都觉得这波操作满分。但当你满怀期待地按下 go run 时，Go 编译器却无情地丢给你一个红色报错：

cannot use generic function g without instantiation
（不能在未实例化的情况下使用泛型函数 g）

AI 沉默了，它不明白自己错在哪；如果你是个习惯了 Rust 那种“地表最强类型推断”的开发者，你可能会当场流下心酸的眼泪—— 在 Rust 里闭着眼睛都能推断出来的泛型参数，怎么到了 Go 里，它就突然变成了“残疾”？

如果你曾经被这个“诡异”的泛型报错折磨过，甚至因此怀疑过自己的智商，不要怪 AI 不懂 Go 语言。

因为就在最近，连“Go 语言之父之一” 的 Robert Griesemer 都亲自在官方 GitHub 上提了一个 Issue，承认这个语法限制不仅反直觉，甚至一度被认为是一个编译器 Bug！Griesemer 本人随即在 Issue 中自我更正，明确这需要语言规范(spec)层面的修改，而不只是修编译器。

今天，我们就来扒开这个在 Go 官方仓库引发热议的 Issue #77245，看看这个即将改变Go工程师日常编码的“底层规范级修补”，到底是怎么回事。

“薛定谔”式的类型推断

自从 Go 1.18 引入泛型以来，“不够聪明”的类型推断（Type Inference）就一直被开发者诟病。直到 Go 1.21 发布，官方宣称大幅增强了这部分能力：只要在赋值上下文中，目标类型是明确的，Go 就可以帮你自动推断出泛型函数的参数类型，不需要你手动写 g[int] 了。

这听起来很美好，对吧？

但现实是极其骨感的。我们来看看 Robert Griesemer 亲自给出的这个“薛定谔式的推断”的例子：

type S struct{ f func(int) }

func g[T any](T) {} // 这是一个简单的泛型函数

func _(s S) {
    s.f = g          // ✅ 没问题！Go 编译器智商在线，完美推断出 T 是 int

    s = S{f: g}      // ❌ 报错：不能在没有实例化的情况下使用泛型函数 g

    s = S{f: g[int]} // ✅ 没问题！必须手动写死 g[int]
}

看懂这个坑在哪里了吗？

当你写 s.f = g 的时候，编译器智商在线，它知道 s.f 需要一个 func(int)，所以它机智地把泛型函数 g 实例化成了 g[int]。

但是（最气人的但是）！

当你使用结构体字面量 S{f: g} 进行初始化时，编译器却突然“智力下线”了。它死活推断不出 g 需要被实例化为 int，非逼着你极其啰嗦地写上 g[int]！

这种“一半聪明，一半智障”的表现，不仅存在于结构体里。在切片（Slice）、数组、Map，甚至是 Channel 的发送操作中：

type F func(int)
type A [10]F
type S []F
type M map[string]F
type C chan F

func g[T any](T) {}

func _() {
    var a A
    a[0] = g      // ok
    a = A{g}      // error: cannot use generic function g without instantiation
    a = A{g[int]} // ok

    var s S
    s[0] = g      // ok
    s = S{g}      // error: cannot use generic function g without instantiation
    s = S{g[int]} // ok

    var m M
    m["foo"] = g         // ok
    m = M{"foo": g}      // error: cannot use generic function g without instantiation
    m = M{"foo": g[int]} // ok

    var c C
    c <- g      // error: cannot use generic function g without instantiation
    c <- g[int] // ok
}

只要你使用了复合字面量（Composite Literals），这套“残疾”的类型推断就会集体失效。

为什么 Rust 和 AI 看了会沉默？

如果你去问一个 Rust 开发者：“目标结构体的字段类型 f func(int) 明明就摆在那里，Go 编译器为什么会看不见？”

Rust 开发者可能会拍着你的肩膀叹气。在 Rust 强大的类型推断系统面前，这种上下文推导简直是基本操作，根本不需要开发者操心。

而在如今 AI 辅助编程大行其道的时代，这个问题更加被无限放大。

大模型在学习了海量代码后，它的“直觉（Next-token prediction）”告诉它，这里上下文极其明确，根本不需要写死类型参数。于是 AI 开心地生成了 S{f: g}，结果却被 Go 编译器无情打脸。你不得不停止思考，手动去把 AI 生成的代码一行行加上 [int]、[string]……

这根本不是 AI 的幻觉，而是 Go 语言规范（Spec）在当年设计时，由于过于严谨，给自己留下的思维盲区。

在最初的 Go Spec 中，关于泛型函数实例化生效的上下文规定得极其死板（只在某些直接赋值的场景生效）。当时的 Go 团队并没有抽象出一个统一的 “赋值上下文（Assignment Context）” 概念。这导致散落在各个角落的复合字面量操作，全都成了漏网之鱼。

官方的修补：一场牵一发而动全身的“规范手术”

起初，Robert Griesemer 以为这只是个单纯的编译器 Bug，只要改改代码就行了。

但随着讨论的深入，核心成员们（如 Austin Clements）发现，这事儿没那么简单。要从根本上解决这个问题，必须对 Go 语言规范（Spec）动刀子！

在随后的内部评审中，Go 团队做出了一个决策：

他们没有选择“头痛医头，脚痛医脚”地去给结构体、Map、切片分别打补丁。而是选择在 Go 语言最底层的定义——“可赋值性（Assignability）” 上做文章。

他们提出了一个新的 CL ，只要一个表达式符合“可赋值性”的校验（无论是等号赋值、结构体初始化、还是 Channel 发送），Go 编译器就必须启动泛型函数的自动类型推断。

这就好比给整个 Go 语言的类型推断系统，彻底打通了奇经八脉。

小结

到这里，可能有开发者会问：“不就是少写几个 [int] 吗？至于这么大惊小怪吗？”

在几行代码的 Demo 里，这确实不是事。

但在大厂动辄十几万或几十万行的微服务源码中，当我们使用泛型去实现高阶的“工厂模式”、“回调注册”、“依赖注入”时，代码中会充斥着大量的结构体初始化和泛型函数传递。

如果没有统一的类型推断，原本极其优雅的代码，就会变成被各种中括号 [T, K, V] 塞满的“乱码”。

更少的手动类型标记，意味着更低的人类认知负荷（Cognitive Load），以及对 AI 代码生成工具更友好的兼容性。

Go 语言之所以能在一众花里胡哨的新语言中稳坐云原生霸主的交椅，靠的绝不仅是并发，更是这种对“代码清爽度”和“心智负担”极其克制、甚至有些偏执的追求。

好消息是，这个被开发者诟病已久的痛点，已经被 Go 官方提案评审委员会 “正式接受（Accepted）”。

我们极有可能在即将到来的后续版本(比如Go 1.27)中，看到这段啰嗦的泛型代码彻底消失。

资料链接：

• https://github.com/golang/go/issues/77245
• https://go.dev/cl/751312

今日互动探讨：

在日常写 Go 泛型的时候，你还遇到过哪些让你觉得“Go 编译器简直是个智障”的奇葩场景？或者在对比 Rust/TS 时，你觉得 Go 的类型系统最需要补齐哪个短板？

欢迎在评论区疯狂吐槽与分享!

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

• 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
• 前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
• 星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
• 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
• 独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。