2025年十一月月 发布的文章

为什么 Go 在悄悄地做 Rust 做不到的事:保持简单

本文永久链接 – https://tonybai.com/2025/11/21/why-go-is-quietly-doing-what-rust-couldnt-staying-simple

大家好,我是Tony Bai。

近日,一篇题为《为什么 Zig 在悄悄地做 Rust 做不到的事:保持简单》的文章在开发者社区引发了热议。文章以其辛辣、富有煽动性的文风,将 Zig 描绘成 Rust 复杂性的“解毒剂”,是“一个终于接受了心理治疗的 C 项目”,并引发了关于“简单性”与“安全性”的深刻辩论。

这不禁让我们——作为 Go 社区的观察者——产生了一个有趣的想法:如果我们将文中的主角 Zig,完全替换为 Go,这篇文章的论点是否依然成立?

Go 语言,在其诞生之初,同样被视为对 C++ 等语言复杂性的“反叛”。它与 Zig 在追求编译速度、二进制简洁性以及“显式优于隐式”的哲学上,有着惊人的相似之处。

于是,我们进行了一次大胆的“思想实验”:在保留原文犀利风格和核心论证结构的前提下,将所有关于 Zig 的部分都替换为 Go,并将代码示例“翻译”为地道的 Go 代码。

这并非意在挑起 Go 与 Rust 之间的“战争”,而是希望通过这样一次“角色扮演”,从一个全新的、极具张力的视角,来重新审视 Go 语言的设计哲学,以及它在现代编程语言光谱中所占据的那个独特、宝贵且时常被误解的位置。

以下,便是这次思想实验的成果。各位小伙伴儿品一品,这样替换后,是不是不仅完美地道出了 Go 在“简单”与“显式”上的坚持,更说出了许多 Gopher 心里想说,却又不好意思直接对 Rust 爱好者说出口的‘真心话’?


Rust 对安全性大声疾呼。Go 只是把它构建了进去——没有那些仪式感、没有那些说教、也没有那 15 分钟的编译时间。

引子

我第一次写 Go 代码的时候,忍不住笑出声来。不是因为它好笑——而是因为我不敢相信,在现代编程世界里,还存在着如此……安静的东西。

在与 Rust “搏斗”多年之后——那门承诺将我们从 C 的苦海中拯救出来,却不知怎的变成了一场性格测试的语言——Go 感觉就像是 Rust 霓虹闪烁的都市中心里,一间温暖、极简的小木屋。

而这,正是关键所在。

Go 并非试图成为未来。它只是想保持理智。


Rust 承诺了天堂,却给了我们一堆文书工作

还记得那股炒作的热潮吗?Rust 是“C 语言杀手”,是内存安全的“弥赛亚”,是系统编程的“救世主”。

平心而论,Rust 确实……算是兑现了。你可以写出快如闪电的安全代码——在你向借用检查器献祭了三只山羊和整个周末的心智健全之后

你看着这样的代码:

// Rust
fn main() {
    let mut data = vec![1, 2, 3];
    let ref1 = &data;
    data.push(4); // 借用检查器:“凡人,你不能这么做。”
    println!("{:?}", ref1);
}

你会想,为什么?为什么我的编译器听起来像我的前任在解释情感边界?

Rust 像一个严厉的治疗师一样教你所有权。而 Go 呢,只是耸耸肩说:“你搞坏了,你修好它。”

这就是哲学的分水岭。Rust 假设你不可信。Go 假设你是个成年人。

Rust 的才华毋庸置疑——安全、并发、无畏的重构。但它也……让人筋疲力尽。那些仪式感。那些工具链。那种将过度工程伪装成纯粹性的文化。

而 Go 呢,穿着连帽衫,拿着半个三明治出现,说:“嘿,想不想直接把该死的二进制文件构建出来?”


无聊之美

这是大多数人忽略的一点:简单不是一个特性。它是一种反叛。

Go 看起来很无聊。感觉也很无聊。读起来就像一个终于接受了心理治疗的 C 项目。

// Go
package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

就是这样。没有宏。没有 build.rs。没有 Cargo 尖叫着说哪个 crate 过期了。

仅仅。一个。编译器。

其底层呢?一个能让你团队喜极而泣的设计:

  • 没有隐藏的控制流。
  • 没有未定义行为。
  • ** 没有运行时的“惊吓” (No runtime surprises)**。(即,没有像 JIT 或复杂后台进程那样,会产生不可预测行为的“魔法”运行时)
  • 一个像钟表一样精确工作的确定性构建系统。

你可以去读 Go 编译器的源码,并且真的能读懂它。你去试试读 Rust 的编译器源码,那你需要咖啡因、心理治疗和一个祈祷小组。

Go 不性感。它很实用。它是那种你会忘记你正在使用的语言——而这,是最高的赞美。


Rust 扩展了代码库,Go 扩展了人类

说实话吧——Rust 最大的优点也是它最大的诅咒:它迫使你思考。不停地思考。

每一行代码都是一场关于生命周期、可变性和宇宙正义的哲学辩论。

Go 呢?Go 就像是说:“嘿,这是内存。别把自己捅了就行。” (笔者注:Go是GC语言,这句直接替换zig后的表达可能不是很契合)

这很重要。尤其是在团队中。

Rust 感觉像学术界——人们在 Slack 上辩论着 monad,而功能的截止日期却在悄悄溜走。Go 感觉像那个穿着脏兮兮运动鞋、代码却能跑起来的初创公司工程师。

在 Swiggy 这样的规模下,Go 取代了 Java 后端,因为它扩展了开发团队。Go 也许正在悄悄地为系统编程做同样的事情——不是因为它“更好”,而是因为它更人性化。 (笔者注:由于有特定背景局限,这里将zig替换为Go后可能也不是很契合了)

你不需要一块精神白板来在脑中记住 12 条借用规则。你只需要……写。


讽刺的转折:Go 才是 Rust 假装要成为的样子

Rust 将自己营销为“安全的系统编程”。但它实际上是——一个系统框架

Cargo、crates、宏、过程魔法——这是一个生态系统,而不是一门语言。华丽,但沉重。

Go 把所有这些都剥离了。

没有依赖爆炸。没有语言版本混乱。没有每夜构建的轮盘赌。

最关键的是——Go 的构建系统是如此集成,如此具有确定性,以至于整个 CI/CD 的设置都感觉更清爽了。

Rust 像一座现代大教堂一样构建。Go 像一条工具腰带一样构建。

“Go 不试图保护你。它试图赋予你力量。”

这就是那场安静的反叛。Go 相信你知道自己在做什么——它只给你足够的绳子让你把事情绑在一起,而不是让你上吊。

而讽刺的是什么?Go 中那些“不安全”的部分,在实践中往往最终更安全,因为你能看到一切。没有魔法。没有语法糖。只有原始的意图。


当炒作退去,简单性胜出

每个技术周期都以同样的方式结束。

炒作机器火力全开。Medium 上的文章成倍增加。Meme 如潮水般涌来。然后有一天——凌晨两点,生产环境着火了,你只想知道为什么该死的二进制文件崩溃了。

Rust 给了你安全。但 Go 给了你清晰。

// Go
package main

import (
    "fmt"
    "os"
)

func main() {
    file, err := os.Create("output.txt")
    if err != nil {
        // 你能清晰地看到错误处理
        panic(err)
    }
    defer file.Close()

    _, err = file.WriteString("Explicit is better than implicit.")
    if err != nil {
        panic(err)
    }
}

你简直可以追踪到每一个字节。没有隐藏的分配器。没有神秘之处。

这正是老派 C 开发者所怀念的那种控制感——但现代开发者却忘记了自己也需要这种感觉。

这场安静革命的教训

  • 简单是一种权力。你的语言越可预测,你付出的认知税就越少。
  • 安全不是舒适。Rust 让你感到安全,但筋疲力尽。Go 让你感到暴露,但一切尽在掌握。
  • 你不需要另一个抽象。你需要更少的抽象。
  • 有时,无聊会赢。因为无聊的东西能扩展、能调试、能交付。

最后的思考

Rust 将继续演进。它配得上它的王座。但在某个地方,有一支小团队正在用 Go 构建——没有炒作,没有技术大会演讲,没有花哨的市场营销。

只是在悄悄地编写着那些永不崩溃、编译只需几秒、在生产环境中如幽灵般运行的干净的二进制文件。

这就是没人预见到的转折。Go 并非在与 Rust 的未来竞争。它在复活编程的过去——我们早已遗忘的那些美好部分。

而且,也许,仅仅是也许,这就是它最终获胜的方式。

资料链接:https://freedium-mirror.cfd/@daxx5/why-zig-is-quietly-doing-what-rust-couldnt-staying-simple-a47f86b3a58a


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

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

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


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


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

Goroutine 栈增长机制新提案:用缺页中断替代栈检查?Rob Pike 亲自下场“劝退”

本文永久链接 – https://tonybai.com/2025/11/20/proposal-improve-goroutine-stack-using-page-faults

大家好,我是Tony Bai。

Go 语言的 goroutine 以其轻量和高效著称,而其背后一个关键的“魔法”便是可动态增长的栈 (Resizable Stacks)。然而,支撑这个魔法的机制——在几乎每个函数入口处插入的“栈检查”指令——也并非毫无代价。

近日,在 golang-nuts 邮件组,一位名叫 Arseny Samoylov 的年轻开发者发起了一场引人深思的讨论,提出了一个颇具“革命性”的提案:我们能否借鉴 Linux 内核管理线程栈的方式,用“缺页中断”(Page Faults) 机制来取代 Go 现有的“栈检查”?

这个旨在挑战 Go 运行时基石的大胆设想,引来了 Go 语言联合创始人 Rob Pike 的亲自下场。本文中,我们就来简单看看这个看似优雅的提案,为何会引来社区的质疑,并最终被 Rob Pike 本人以“实现过于复杂”为由,泼上一盆“冷水”。

现状的“痛点”——无处不在的“栈检查”

在深入新提案之前,我们必须先理解 Go 当前的栈增长机制及其代价。

当前,Go 编译器会在几乎每一个非叶子函数的序言 (prologue) 部分,插入几条特殊的指令。这些指令的作用是在函数开始执行前,检查当前 goroutine 的剩余栈空间是否足够。如果不足,运行时 (runtime.morestack) 就会介入:分配一个更大的新栈,将旧栈的内容复制过去,调整所有指向栈上变量的指针,然后才继续执行函数。

提案者指出的当前机制的两大痛点

  1. CPU 开销:频繁的栈检查本身就是一种 CPU 开销,尤其是在调用链很深或存在大量无法内联的间接调用(如接口方法调用)时。
  2. 代码体积膨胀:每个函数都增加了额外的序言指令(提案者估计约 10 条指令),这会增加 L1 指令缓存 (L1i Cache) 的压力,对计算密集型任务的性能产生负面影响。

基于此,提案者估计,消除栈检查可能会为真实的 Go 应用带来 3% – 5% 的性能提升。

“革命”的设想——通过“缺页中断”实现栈增长

Arseny Samoylov 的提案,其灵感源自现代操作系统(如 Linux)管理原生线程栈的方式。

核心思想

  1. 在创建一个 goroutine 时,不再只分配一个很小的物理内存(当前为 2KB),而是为其预留 (reserve) 一大块虚拟地址空间(例如 8MB),但不立即分配物理内存。
  2. 在这块虚拟地址空间的末尾,设置一个“警戒页”(Guard Page),标记为不可访问。
  3. 移除编译器插入的所有“栈检查”指令。
  4. 当 goroutine 的栈增长,触及到未分配的内存页时,会触发一次缺页中断 (Page Fault)。操作系统内核会捕获这个中断,并“懒惰地”为其分配一页新的物理内存。
  5. 当 goroutine 的栈增长到极致,最终触及到那个“警戒页”时,Go 运行时捕获这个特定的信号,此时才执行现有的栈扩容逻辑。

这个设计的精妙之处在于,它将持续的、遍布每个函数的“栈检查”开销,转变成了仅在栈空间真正耗尽时才发生的一次性、代价较高的“异常处理”

社区的讨论——一场关于性能、复杂性与可行性的权衡

这个看似优雅的方案,立刻引发了社区开发者的辩论。经验丰富的工程师们很快指出了这个方案背后隐藏的巨大挑战:

  1. 中断处理的巨大开销:Jason E. Aten 指出,处理一次缺页中断并由信号处理器接管,其过程极其缓慢。它涉及至少 4 次昂贵的上下文切换(用户态 -> 内核态 -> 信号处理器 -> 内核态 -> 用户态)。这个开销,可能远高于 Go 运行时目前高效的内存分配器。
  2. 区分“好”与“坏”的中断:Go 运行时如何能精确地区分出,一次缺页中断是因为“栈需要正常增长”,还是因为一个真正的 Bug(如 nil 指针解引用)?这是一个极其棘手的问题。
  3. 虚拟地址空间的消耗:虽然 64 位系统的虚拟地址空间极其巨大,但为每一个 goroutine 都预留 8MB,依然是一个不小的负担。10 万个 goroutine 将消耗 800GB 的虚拟地址空间。
  4. 最小栈的增加:最小的物理内存分配单位是一个页(通常是 4KB)。这意味着 goroutine 的最小栈大小将从 2KB 翻倍到 4KB,对于那些拥有数百万个小 goroutine 的应用,这可能会导致物理内存消耗翻倍

Rob Pike 的“劝退”——来自创始人的最终裁决

当讨论进入白热化时,Go 语言的联合创始人 Rob Pike 亲自下场,给出了他的最终点评。他的观点,冷静而深刻,几乎为这场辩论画上了句号。

首先,他认为提案者夸大了“栈检查”的成本

“我相信你夸大了(栈检查的)成本。它是可测量的,但并没有你说的那么严重。并且,随着函数内联越来越普遍,函数的体积变大,摊销后的实际成本都在降低。”

更重要的是,他指出了这个提案在工程上的历史困境,这正是“劝退”的核心理由:

“此外,在过去,使用内核traps 来实现栈增长一直都问题重重。我曾见过其他系统尝试这样做,但最终都因为无法预见的复杂性而放弃了。我不是说这做不到,但这绝非易事。而且,由于细节依赖于架构和操作系统,要做到可移植性非常困难。”

最后,他给出了一个简洁而有力的结论:

“这事不归我管,但我不会这么做。”
(It’s not up to me, but I wouldn’t do this.)

小结:永不停歇的探索,Go 演进的生命力

这场关于 goroutine 栈的“革命”提案,最终在创始人的“劝退”中似乎逐渐平息。然而,将此视为一次简单的“失败”,或许会错失其更深远的意义。

Rob Pike 的点评,以其数十年的工程经验和对复杂性的深刻洞察,为这个提案的技术路径亮起了警示的红灯。他指出的“无法预见的复杂性”“难以解决的可移植性”,是任何试图修改语言运行时的工程师都必须敬畏的“冰山”。

然而,无论这位提案者 Arseny Samoylov 最终是选择接受劝告,还是不顾一切地继续探索并拿出概念验证 (PoC),这场讨论本身,对 Go 社区而言,都是一件弥足珍贵的好事,它完美地体现了 Go 社区的生命力所在。

Go 语言的演进,正是在这种“大胆设想”与“审慎权衡”的持续张力中,稳步前行的。

资料链接:https://groups.google.com/g/golang-nuts/c/q3iZk0phN9E


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

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

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


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

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats