Tony Bai - 一个程序员的心路历程

AWS 大神发文炮轰：Go 的并发就是个“笑话”，JVM 的方案要更优越

五月 7, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/07/aws-guru-slams-go-concurrency-as-a-joke-vs-jvm

大家好，我是Tony Bai。

过去十年，如果要在后端技术圈选出一个“金字招牌”，那无疑是 Go 语言的并发。

凭借其极简的 go 关键字和优雅的 channel，Go 将并发编程的门槛从“博士级”拉到了“入门级”。在云原生和微服务的浪潮中，Go 几乎就是“高并发”的代名词。

但就在前几天，AWS 的资深布道师 James Ward，在 X 平台上突然向 Go 语言的这个“优势高地”发起了猛烈炮轰：

“开发者普遍认为 Go 在并发方面很出色。但事实并非如此。JVM 的方案要优越得多。当你把虚拟线程、结构化并发和 Effects 加进来时，它甚至是全行业最好的方案之一。”

为了证明自己的观点，他还引用了前 Google 工程师 Ahmetb（以其在 K8s 社区的贡献而闻名）设计的一道极其刁钻的并发编程“考题”——实现一个工业级的、线程安全的网络连接池。

这道题，像一块试金石，炸出了 Go 并发模型背后那些被“易用性”所掩盖的无数“天坑”。

这场由大神发起的“语言战争”，瞬间引爆了技术圈。从前 Uber 工程师到 Victoria Metrics 的核心开发者，无数 Gopher 下场“护驾”。

今天，我们就来复盘这场神仙打架，看看当 Go 的“平民法拉利”遭遇现代 JVM 的“德系重装甲”时，到底谁才是真正的并发之王？

战火的点燃：一道价值千金的“并发考题”

让我们先来看看点燃这场战争的导火索，Ahmetb 设计的这道“连接池”考题：

你需要实现一个线程安全的、有界连接池。
1. Acquire()：当池中无可用连接时，必须阻塞。必须响应 context 的超时和取消。
2. Release()：归还连接。如果池已满或连接已损坏，则关闭连接而不是泄漏。
3. Close()：必须干净利落地关闭整个池。停止接受新请求，立即关闭所有空闲连接，并等待所有正在被使用的连接被归还后，再关闭它们。
4. IdleTimeout：自动清理超过空闲时长的连接。

这道题，看似简单，实则布满了“杀机”。

它几乎涵盖了并发编程中所有最令人头疼的场景：资源限制、优雅启停、生命周期管理、超时与取消、后台清理……

Ahmetb 坦言：

“如果你享受 Go 的并发原语，那就挑战一下自己去实现它。这里面的边缘情况，比我最初想象的要多得多。”

而 James Ward 正是借着这道题，打出了他的第一炮：用 Go 的原生 channel 和 select 去完美地解决所有这些问题，其代码量和心智负担，将远超现代 JVM 的解决方案。

两派的交锋：Go 的“野路子” vs JVM 的“正规军”

面对 James 的炮轰，评论区迅速分裂成两大阵营。

Go 阵营（以实战派为首）的反击：

前 Uber 工程师 Ovais Tariq 现身说法：

“Go 在高并发工作负载下更优越——这是我在 Uber 运营大规模 Go 服务的实践经验。”

另一位开发者则指出了 Go 的核心优势：

“我完全同意（Go 更优）。这个工具（Go）被创造出来，就是为了无缝处理成千上万个大部分时间都在‘等待’I/O 的任务。在这个角色上，Go 至今仍然表现卓越。”

Go 阵营的核心观点是：Go 的并发模型（Goroutine + Channel），就像一把简单、锋利的匕首。它足够轻、足够快，虽然需要使用者自己具备高超的技巧，但在真实的、海量的 I/O 密集型场景下，它的实战表现就是最好的证明。

JVM 阵营（以理论派为首）的降维打击：

James Ward 则对这些“实践经验”嗤之以鼻：

“真的吗？像 Scala ZIO 这样的 Effect 调度器和虚拟线程，在安全处理非阻塞任务时，看起来比 Goroutine 要容易得多。”

JVM 阵营的核心观点是：Go 的并发原语太“低级”了。 它把所有关于取消、超时、错误传播、资源清理的复杂性，全部甩给了开发者。而现代 JVM 生态，通过虚拟线程、结构化并发（Structured Concurrency）和函数式 Effect 系统（如 ZIO, Arrow Fx），已经从语言和框架层面，为你提供了一套“三位一体”的、体系化的解决方案。

虚拟线程：让 JVM 拥有了和 Goroutine 一样廉价的“百万级”并发能力。
结构化并发：强制所有并发任务拥有清晰的父子关系和生命周期，彻底消灭“野 Goroutine”和资源泄漏。
Effect 系统：用类型系统来管理异步任务的副作用，让并发代码像写同步代码一样清晰和安全。

这场争论的本质，是“游击队”与“正规军”的对决。Go 提供了最灵活的单兵作战武器，而 JVM 则提供了一整套陆海空协同作战的军事体系。

Go 的“平民化”哲学 vs JVM 的“专家级”哲学

在这场混乱的口水战中，Victoria Metrics 的工程师 Phuong Le 的一篇复盘长文，将整个讨论提升到了哲学的高度。

他没有去争论谁快谁慢，而是深刻地剖析了两种技术路线背后的设计哲学差异：

“Go 在并发方面并不差。一个更真实的说法是：Go 擅长让并发变得廉价、显式和易于上手，尤其是在常见的后端模式中。”

Phuong Le 指出，Go 的核心优势在于“平民化（Approachable）”。

它用极其简单的原语，让一个普通的开发者，也能快速地写出“看起来能用”的并发代码。但这种“简单”的代价是，它把大量的“正确性”责任，下放给了开发者自己。

“Go 给了你相对低级的原语。大量关于取消、任务生命周期、清理、错误传播和背压的正确性保证，都留给了我们程序员自己去处理。”

而现代 JVM 生态，则走向了另一个极端——“专家系统”。

它试图在框架和语言层面，构建一个极其复杂、但理论上绝对安全的“象牙塔”。开发者需要学习大量的概念（Monad, Functor, Fiber…），但一旦学会，就能获得极高的安全性保障。

Phuong Le 的结论是：

“所以，公平的比较不是‘Go vs JVM，谁赢？’，而是：Go 优化的是简单的、实用的并发；而现代 JVM 生态，拥有更强大的工具来处理结构化的、资源安全的并发。 到底哪个更好，取决于你面临的并发问题有多复杂。”

你的团队，需要匕首还是航母？

这场神仙打架，最终没有赢家。但它为我们所有后端架构师，提供了一次极其宝贵的“架构选型”公开课。

1. 承认 Go 的“天花板”

我们必须承认，Go 的原生并发原语，在处理极其复杂的、需要精细化资源管理的场景时，确实存在“天花板”。Ahmetb 的那道“连接池”考题，就是一个完美的试金石。如果你团队的业务复杂到这种程度，直接引入一个成熟的第三方库（或者评估 JVM 生态），可能比自己手搓 Channel 要明智得多。

2. 警惕 JVM 的“学习曲线”

虚拟线程虽然抹平了 JVM 在并发“数量”上与 Go 的差距，但结构化并发和 Effect 系统，依然是较为陡峭的学习曲线。在一个追求快速迭代、人员流动频繁的团队里，引入这些“重型武器”的培训成本和心智负担，是必须被严肃评估的。(注：不知道有多少Java开发至今也没有使用过虚拟线程)

3. “足够好”也许就是最好的

评论区里，Jacob Voytko 的观点极具代表性：

“Go 的并发原语并非在所有方面都理想，但对于终端用户（业务开发者）大多数时候写的那些东西来说，它们是完美的。管理 fan-in/fan-out、处理带超时的异步任务……对于这些 80% 的场景，Go 的‘足够好’方案已经足够了。”

小结：没有银弹，只有权衡

这场由 James Ward 发起的“Go 并发之战”，最终以一场关于“架构权衡（Trade-offs）”的深刻反思而告终。

它像一面镜子，照出了我们这个行业最真实的底色：从来没有“最好的”语言，只有“最适合的”场景。

Go 的成功，在于它用最简单的武器，解决了云原生时代最大多数的并发问题。它的哲学，是牺牲一部分理论上的“完美”，去换取工程上的“极致效率”。

而现代 JVM 的进化，则代表了另一种可能：通过不断叠加更高级的抽象，去追求一个理论上“绝对安全”的并发乌托邦。

作为架构师，我们的终极使命，不是去争论哪条路更高贵，而是在理解了所有路径的代价之后，为我们的团队、我们的业务，选择那条最务实的、能活着走到终点的路。

资料链接：

https://x.com/JamesWard/status/2049498133013344285
https://x.com/func25/status/2050243999123009662
https://x.com/ahmetb/status/2049341220707844340

今日互动探讨：

你如何看待 James Ward“Go 并发不行”的观点？在你的实战中，Goroutine+Channel 是否真的“够用”？或者你更期待 Go 能引入类似 JVM 的“结构化并发”？

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

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

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

Robert Griesemer 亲述：只解决 90% 问题的“箭头函数”该长什么样？

五月 6, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/06/robert-griesemer-on-go-arrow-functions

大家好，我是Tony Bai。

在 Go 语言的演进史上，很少有一个 Issue 能像 #21498 这样，跨越 9 年时光，累积近千条评论，却依然让官方核心团队如履薄冰。

这个 Issue 的目标很单纯：为 Go 提供一种更简洁的匿名函数语法（Short Function Literals）。或者用大白话说，大家想要一个像 JavaScript 或 Rust 那样的“箭头函数”。

每当一个 Gopher 在代码里写下：

slices.SortFunc(users, func(a, b User) int { return cmp.Compare(a.Age, b.Age) })

他大概率会在心里暗骂一句：“这代码真够笨重的。”

然而，Go 团队对此的回应一直是：“我们不想要魔法，我们只想要清晰。” 这种坚持让社区陷入了长达数年的僵局。

但就在最近，这场僵局似乎正在被化解。

Go 语言之父之一的Robert Griesemer 亲自下场发表了一段重量级评论。他没有给出一个试图满足所有人的复杂方案，而是抛出了一个充满工程智慧的诠释：

“也许试图为任何函数解决这个语法问题是误导性的。我们应该只为那些本来就很短的函数提供支持。”

今天，我们就来看看 Robert 最新诠释中的这个“只解决 90% 问题”的箭头函数，到底长什么样？应该如何用？

底层觉醒：放弃对“全能语法”的执念

Robert Griesemer 的这段话，实际上是对过去 9 年社区争论的一次“终极复盘”。

在这 9 年里，无数天才开发者试图设计出一种“完美”的缩写语法：有的想省掉括号，有的想省掉类型声明，有的甚至想通过 $1, $2 这样的占位符来彻底消灭参数列表。

但这些方案无一例外都让 Go 编译器头疼，更让代码的可读性变得支离破碎。

Robert 意识到，真正的问题不在于匿名函数太长，而在于我们试图让“箭头函数”承载它本不该承载的重量。

如果一个匿名函数里包含了 if 逻辑、for 循环、甚至是一个 switch 分支，那么它本质上就是一个多行逻辑块。对于这种逻辑，写出完整的 func() 语法，带上明确的参数名和结果类型，不仅不是负担，反而是对读者的仁慈。

于是，Robert 划定了一条冷酷的边界线：短函数语法，只服务于单表达式或单语句。

蓝图拆解：Robert 亲自执笔的语法模型

在 Robert 的设想中，Go 的短函数（箭头函数）应该由两个核心部分组成。

第一部分：针对“有返回值”的场景（单表达式）

这是高阶函数（如 Map、Filter、Sort）最常用的场景。Robert 提议采用 (args) -> expr 的符号：

ShortFunctionLit = “(” [ IdentifierList ] “)” “->” ( Expression | “(” ExpressionList “)” ) .

这意味着你可以写出如下的代码：

() -> 42                         // 无参数，返回常数
(x) -> math.Sin(x)               // 单参数，返回计算结果
(x, y) -> x < y                  // 多参数，返回布尔值
(x, y) -> (x + y, x * y)         // 多返回值（需括号包裹）

这里的精髓在于两点：

彻底消灭 return 关键字：如果右侧是一个表达式，结果会自动返回。
极简的类型推断：由于它是作为参数传递给某个已知签名的函数（赋值上下文），编译器可以 100% 确定 x 和 y 的类型。你不再需要写 (a int, b int) int 这种啰嗦的废话。

第二部分：针对“无返回值”的场景（单语句）

除了返回值，还有一种场景是“简单回调”：执行一个动作，但不返回结果。

为了严格区分这两种场景，Robert 引入了一个极其精妙的设计：利用大括号 {} 来作为“不返回结果”的视觉信号。

ShortFunctionLit = … | “{” SimpleStmt “}” ) .

例子如下：

() -> { /* do nothing */ }
(x) -> { fmt.Printf("log: %v\n", x) } // 执行打印，无返回
(x) -> { ch <- x }                    // 往通道发数据，无返回
(p) -> { (*p)++ }                     // 修改指针值，无返回

Robert 的设计逻辑非常清晰：

没有 {}：必须返回一个值（表达式）。
有 {}：必须不返回值（语句）。

这个视觉区分，让任何一个读者在扫过代码的一瞬间，就能理解这个匿名函数的副作用。

架构师的必修课：为什么“只解决 90%”才是最佳答案？

Robert 在评论中提到：

“这能解决 90% 的常见案例，就像短变量声明（:=）一样。”

这正是这篇文章最值得我们升维思考的地方。

一个平庸的语言设计者，会试图通过复杂的规则去覆盖 100% 的场景，最终让语言变得像 C++ 一样臃肿。而一个顶级的语言设计者（如 Robert），懂得利用“帕累托法则（二八定律）”。

:= 并不完美，它在某些特定的作用域重叠情况下会引发困惑。但它解决了 90% 的声明问题，让 Go 代码变得极其清爽。

同样，Robert 提出的这个“箭头函数”蓝图：

它不能写多行逻辑？ 没关系，剩下的 10% 复杂场景，写 func() 更有助于维护。
它不能省掉参数括号？ 没关系，强制带上 () 可以避免解析歧义，保持 Go 一贯的“明确”风格。

*这种“克制”的艺术，正是 Go 语言在云原生时代能够取得成功的重要原因之一。** 它不追求在每一行代码上都胜过别人，它追求的是在大规模协作、在百万行代码库的维护上，保持最低的认知负荷。

未来的模样：现代化的代码重构

Robert 在文章末尾甚至已经想好了如何推广这个特性：

“如果我们引入了这个短格式，我们可以一键使用现代工具（modernizer）将现有的所有旧代码重写。”

想象一下，当你把你的项目升级到未来的 Go 版本，运行一下格式化命令。原本满屏的：

users.Map(func(u User) string {
    return u.Name
})

会瞬间收缩为：

users.Map((u) -> u.Name)

这既是字符的缩减，更是一场视觉的解放。

小结：在万变中，寻找最地道的“Go 味儿”

看完 Robert Griesemer 的这份亲述，你是否感受到了一种跨越时空的工程美学？

箭头函数在其他语言里早就不是新闻了。但 Go 团队为了把它设计得“更地道、更不容易出错、更符合长期维护利益”，足足纠结了 9 年。

这种对语法的敬畏，才是我们作为开发者真正应该学习的财富。最好的技术方案，往往不是那个功能最全的，而是那个能以最小的代价，解决最普遍痛点的。

只解决 90% 的问题，剩下的 10% 留给严谨与克制。

这，就是 Go 语言的“中庸之道”，也是它最强大的地方。