本文永久链接 – https://tonybai.com/2026/02/26/rust-complexity-go-minimalism-vs-zig-ultimate-answer

大家好，我是Tony Bai。

在当前的后端与系统级编程领域，开发者似乎总是面临着一种“非此即彼”的艰难抉择：要么选择 Go 语言，拥抱其极致的极简主义、高效的并发模型和无处不在的垃圾回收（GC），但往往需要在底层内存控制上做出妥协；要么投向 Rust 的怀抱，追求绝对的内存安全和零成本抽象，却不得不常年与“借用检查器（Borrow Checker）”搏斗，忍受陡峭得令人绝望的学习曲线。

然而，在这两大巨头的光环之外，一门名为 Zig 的语言正在悄然崛起。它没有隐式的控制流，没有隐藏的内存分配，甚至没有预处理器和宏，却提供了无与伦比的 C 语言互操作性和强大的编译期计算能力。近日，在Reddit技术社区 r/Zig 上，一位资深 Go 开发者分享了他将一个核心项目从 Go 迁移到即将发布的 Zig 0.16 版本的全过程。他的经历既是一次跨越语言壁垒的技术冒险，更为我们揭示了一个深刻的问题：在拒绝了 Rust 的复杂、看透了 Go 的局限之后，Zig 会是我们苦苦寻找的那个系统级编程的最终答案吗？

在本文中，我们将跟随这位开发者的脚步，深度剖析这次从 Go 到 Zig 的“系统级”降维打击，探讨内存管理、并发演进以及新兴语言的生态阵痛。

语言选择的罗曼史：为什么是 Zig？

对于任何一位有着丰富经验的开发者来说，选择一门新的编程语言绝非心血来潮。在这位开发者长长的技术履历中，我们看到了一条清晰的“硬核化”演进路线：Python -> Rust -> Go -> Odin -> Zig。

这条路线背后，折射出的是当代开发者对“开发效率”与“系统控制力”双重渴望的矛盾与挣扎：

1. 逃离 Python 的脆弱：动态类型的 Python 常常伴随着难以预料的运行时错误，加上令人抓狂的虚拟环境（venv/pip）管理，促使他开始向底层探索。
2. 被 Rust 劝退的恐惧：开发者坦言，“Rust 是我尝试过的最复杂的语言”。尽管他勉强写出了 Rust 代码，但他自知那是“糟糕的 Rust”。面对陡峭的学习曲线和心智负担，他的结论异常真实：“Rust 可能很容易学，但我不想再哭一次了（don’t want to cry again）”。
3. Go 语言的温柔乡：在众多高级语言中，Go 成了他最钟爱的归宿。他将 Go 评价为“最低级别的高级语言（lowest of the high level languages）”。对于 Web 服务和后端开发，Go 的极简语法、成熟的生态和开箱即用的特性，使其成为默认的终极选择。他甚至感慨：“我真希望我一开始就是用 Go 学编程的。”
4. Odin 的中道崩殂：在追求比 Go 更底层的控制力时，他曾短暂尝试过 Odin（一门常与 Zig 齐名的面向数据设计的系统级语言）。Odin 在语法上介于 Go 和 Zig 之间，看似完美的平衡却被糟糕的工具链打破。频繁崩溃的 LSP（Language Server Protocol）、不完善的文档以及诡异的编译器指令，最终将他推开了。
5. 情定 Zig：最终，Zig 成为了他的驻足之地。Zig 既提供了不输于 C 语言的底层掌控力，又通过创新的语法和工具链，避开了 Rust 复杂的生命周期管理。

从中我们也可以看出当下系统级编程领域的一道缩影：开发者们渴望获得底层控制权，但不想为此付出丧失开发体验的代价。

移植实战：从 1 周到 2 个月的“阵痛与重塑”

纸上得来终觉浅。这位开发者决定动真格：将一个由 Go 编写的基于内存互斥锁（Mutex）的键值对存储（Key/Value Store）及配套的通道预写日志（channel WAL）项目，完整地移植到 Zig 0.16 中（包括使用 LZ4 压缩和导出 Parquet 格式的功能）。

原计划只需要 1 周的迁移工作，最终演变成了一场长达 1.5 到 2 个月的持久战。为什么会这么耗时？

代码规模与表达力：意外的对等

令人惊讶的是，尽管 Zig 需要手动管理内存，但迁移后的代码量（约 750 行）与原先的 Go 代码几乎持平。开发者指出，虽然 Zig 的代码在视觉上“更宽”（得益于其极其丰富的表达能力），但行数并没有膨胀。这归功于 Zig 中 Unions（联合体）、Enums（枚举）、Errors（错误处理）和 Structs（结构体）的完美组合。

拥抱 Comptime：降维打击的“超能力”

在 Go 语言中，泛型（Generics）直到 1.18 版本才姗姗来迟，且其能力受到诸多限制。而在 Zig 中，开发者体验到了真正的震撼——Comptime（编译期执行）。

他将处理结构体类型的泛型能力称为“疯狂的超能力”。在编译期间执行任意 Zig 代码的能力，使得开发者能够以极低的运行时开销，实现高度动态和灵活的类型处理。这种对类型的编译期反射和操作，是 Go 语言开发者难以想象的体验。

代码组织方式的颠覆

Go 语言习惯于将不同的接口、结构体分散在多个文件中，利用包（Package）级别来进行组织。但在 Zig 中，开发者发现了一种全新的心智模型：将所有想法放入一个文件中，并通过结构体（Struct）进行分组。当代码在编辑器中折叠后，这种高度内聚的设计显得极其清晰且易于导航。

内存管理的洗礼：脱离 GC 后的生存法则

从自带垃圾回收（GC）的 Go 语言跨越到需要显式传递分配器（Allocator）的 Zig，是此次移植中最痛苦，也是收获最大的部分。

没有了 Go 运行时的庇护，开发者必须直面内存的生与死。在经历了无数次内存泄漏后，他总结出了针对 Go 开发者转战 Zig 的七条黄金生存法则：

1. 返回内存的函数，必须接收 Allocator：在 Go 中，函数可以随意返回指针或切片，GC 会负责善后。在 Zig 中，任何产生新内存分配的函数，其签名中必须显式包含一个 Allocator 参数。

2. 严格区分不可变与可变：[]const u8 表示你绝不会修改这块内存（只读切片），而 []u8 则意味着你承诺你会去修改这块内存。这种显式的意图声明，在 Go 的 []byte 中是缺失的，Go 开发者往往需要通过文档或约定来判断切片是否会被修改。而在 Zig 中，类型系统替你守住了这道防线。

3. 所有权与复制 (allocator.dupe)：在 Go 中，传递指针或切片非常廉价，垃圾回收器（GC）会处理共享引用的生命周期。但在 Zig 中，如果你需要保留传入的数据并在函数返回后继续使用，你必须使用 allocator.dupe 进行深拷贝。

4. 内存分配失败是常态：任何分配都可能失败。在 Zig 中，这意味着你必须处理 Error Union。而在 Go 中，make 或 new 失败通常意味着程序崩溃（panic），大多数业务代码从不处理 OOM（内存溢出）。

5. 测试即救赎 (std.testing.allocator)：“不写测试，就等着受苦”。Zig 的标准库测试运行器内置了内存泄漏检测功能。使用 std.testing.allocator 运行测试，如果你的代码有泄漏，测试会直接失败并报告。这对于习惯了“分配后即遗忘”的 Go 开发者来说，简直是当头棒喝，但也是养成良好习惯的最佳工具。

6. 源码即文档：遇到疑问时，直接读标准库源码 (std)。Go 的标准库以清晰著称，但 Zig 的标准库源码同样展示了惊人的可读性。由于没有隐藏的控制流和宏，你看到的即是实际发生的。

并发模型之争：Goroutine 的舒适区 vs Zig 的显式控制

Go 语言最大的护城河无疑是 Goroutine 和 Channel。这种 CSP（通信顺序进程）模型的极简实现，让并发编程变得唾手可得。然而，当这位开发者试图在 Zig 中复刻这一模式时，遭遇了不小的挑战。

误用 std.Thread 的代价

在移植过程中，他试图使用 Zig 的 std.Thread 配合 std.Thread.RwLock 来模拟 Go 的并发模式。然而，一位社区专家指出，这种做法在 Zig 的异步 I/O 体系下是危险且低效的。

Zig 的并发哲学与 Go 不同。Go 将同步（阻塞）代码在运行时自动调度到异步执行，而 Zig 则提供了显式的 async/await（注：Zig 的异步机制在不同版本间变动较大，0.16 预览版中正在重构）和基于事件循环的 IO 模型。

io.Queue 与 Channel 的缺失

为了实现类似 Go Channel 的功能，开发者不得不自己实现了一套基于 Mutex 的通知机制，或者使用第三方库。他坦言：“我不仅想念 Go 的 GC，也想念它的 Channel。”

虽然 Zig 提供了强大的底层原语，但在构建像 Go 那样开箱即用的高并发 Web 服务时，Zig 目前仍缺乏统一且成熟的标准范式（Standard Pattern）。对于习惯了 go func() 的开发者来说，这需要巨大的心智转换。

工具链与生态的阵痛：先行者的代价

如果你已经被 Zig 的性能和控制力打动，那么接下来的内容可能是你需要冷静思考的“劝退”环节。

版本的混沌：0.15 vs 0.16

Zig 尚未发布 1.0 版本，这意味着破坏性更新（Breaking Changes）是家常便饭。该开发者在尝试迁移到 Zig 0.16（开发版）时，遇到了 ZLS（Zig Language Server）的版本兼容性问题。编辑器报错、高亮失效、自动补全崩溃，这些在 Go 这种成熟语言中几乎不存在的问题，在 Zig 的日常开发中却是必须忍受的噪音。

文档的匮乏

“当有疑问时，请检查 Zig 的内置函数（Builtin functions），那里有很多东西。”这句话的潜台词是：不要指望有详尽的官方文档网站。与 Go 丰富且结构化的 pkg.go.dev 相比，Zig 目前更多依赖于阅读源码和社区碎片化的教程。对于习惯了 StackOverflow 复制粘贴的开发者，这无疑是一个巨大的门槛。

“Segmentation Fault” 的回归

正如社区评论所言：“你必须爱上 Segfaults（段错误）。”

Go 语言的运行时捕获了绝大多数底层错误，将其转化为 Panic。而在 Zig 中，尽管有安全模式（ReleaseSafe），但在处理底层指针操作时，你依然可能遇到这一古老的梦魇。开发者回忆道：“我在 2008 年写 C 语言时经常遇到这些，现在我必须重新学会如何调试它们。”

小结：Go 依然是王者，但 Zig 代表了未来？

回到最初的问题：Zig 会是系统级编程的最终答案吗？

通过这次深刻的迁移实战，我们可以得出以下结论：

1. Go 的地位难以撼动：对于绝大多数 Web 后端、微服务和云原生应用，Go 依然是“性价比之王”。它在开发效率、运行时性能和维护成本之间找到了完美的平衡点。正如作者所说，“Go 是最高级语言中的最底层”，这个定位极其精准。
2. Rust 并非唯一解：对于那些需要更高性能、更低内存占用，却被 Rust 陡峭的学习曲线和复杂的借用检查器劝退的开发者，Zig 提供了一个极具吸引力的第三选项。它证明了不引入复杂的生命周期注解，依然可以写出安全且高效的系统级代码。
3. Zig 的甜点区：如果你的项目涉及大量的内存密集型操作、需要极致的启动速度、或者需要与 C 库进行深度交互，Zig 可能比 Go 更合适，也比 Rust 更易上手。

给 Go 开发者的建议：

如果你仅仅是对 Go 的某些性能瓶颈感到不满，不妨先通过 FFI 调用 Zig 编写的库来解决关键路径的性能问题，而不是全面重写。Zig 极其优秀的 C 互操作性，使其成为 Go 语言的最佳“外挂”。

随着 Zig 0.16 及后续版本的发布，特别是异步 IO 模型和包管理器的成熟，我们有理由相信，Zig 将在系统编程领域占据一席之地。它不会取代 Go，但它可能会成为那些追求极致掌控力的极客们手中的那把“光剑”。

资料链接：https://www.reddit.com/r/Zig/comments/1rd0fsz/thoughts_after_porting_a_project_from_go_to_zig/

聊聊你的选择

你会因为 Go 的 GC 开销而考虑尝试 Zig 吗？还是你宁愿忍受 Rust 的编译器也不愿自己管理内存？欢迎在评论区分享你的看法！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2026/02/25/rust-crossing-the-chasm-ubuntu-embrace

大家好，我是Tony Bai。

在技术世界里，一门编程语言的成功往往分为两个阶段：第一阶段是赢得“极客”和“先驱者”的狂热追捧；第二阶段则是说服那些保守、务实的“早期大众”将其投入到枯燥却庞大的企业级生产中。这两个阶段之间，横亘着一条深不见底的“鸿沟”。

2026 年初，Rust 核心团队成员、语言设计的灵魂人物 Niko Matsakis 在参加完 Rust Nation 大会后，发表了一篇引人深思的文章——《What it means that Ubuntu is using Rust》。在这篇随笔中，Niko 借由 Canonical（Ubuntu 的母公司）全面拥抱 Rust 这一标志性事件，极其坦诚地剖析了 Rust 当前在行业接纳生命周期中所处的位置、面临的阵痛，以及为了走向真正的“工业标准”，Rust 社区必须在技术和心理上做出的巨大改变。

本文将深度解读 Niko 的这篇文章，带你透视 Rust 在“后狂热时代”的商业化演进路线、标准库之争、开源商业模式，以及为何“同理心”成了这门硬核语言最大的护城河。

无处不在的“鸿沟”——Rust 到底走到哪了？

如果你熟悉硅谷营销大师杰弗里·摩尔（Geoffrey Moore）的经典理论《跨越鸿沟》（Crossing the Chasm），就会知道任何一项高科技产品在市场推广时，都会经历创新者（Innovators）、早期采用者（Early Adopters）、早期大众（Early Majority）、后期大众（Late Majority）和落后者（Laggards）五个阶段。而在“早期采用者”与“早期大众”之间，存在着一个巨大的断层，这就是“鸿沟”。

Rust 跨过这条鸿沟了吗？

Niko 给出的答案是：这取决于你问的是谁。

• 在某些互联网巨头（大厂）中：答案是“已经跨越了一大半”。比如在亚马逊云（AWS）这样对性能和资源有着极致苛求的地方，Rust 已经被牢牢确立为构建大规模数据平面（Data Planes）和资源感知代理（Agents）的“正确选择”。它甚至正在向设备端和机器人领域的底层代码渗透。
• 在普通企业应用中：依然存在一种根深蒂固的刻板印象——“Rust 是给 S3（亚马逊云存储）那些穿西装打领带的高级工程师用的，对于我们普通的 CRUD（增删改查）业务来说，完全是杀鸡用牛刀。”
• 在安全关键软件（Safety Critical Software）领域：比如汽车的转向柱控制系统或航空航天系统，Rust 依然在艰难地寻找立足点。大多数传统工业巨头仍处于“观望”状态，他们希望让早期采用者先去铺路、踩坑。

这揭示了一个残酷的现实：技术上的优越性并不等同于市场上的普遍接受度。

当技术走向“早期大众”时，受众的心态发生了根本性变化。

早期采用者买的是“变革”，他们愿意容忍不成熟的生态，只为获得降维打击的竞争优势；而“早期大众”买的是“生产力提升”，他们极度厌恶风险，追求的是业务连续性——他们想要的是进化，而不是革命。

寻找“标杆客户”——Ubuntu 搭建的跨越之桥

如何说服那些极度厌恶风险的“早期大众”尝试新事物？唯一的答案是：让他们看到与他们相似的成功案例。

这就是为什么 Canonical（Ubuntu 背后的公司）的入局对 Rust 生态具有决定性的历史意义。在 Rust Nation 大会上，Canonical 的工程副总裁 Jon Seager 发表了题为《在 Ubuntu 中大规模采用 Rust》的闭幕演讲。这场演讲完美诠释了什么是“既有远见，又极其务实”。

Canonical 明确表示，他们已将公司内部开发的语言收敛为一个极小的集合：Python、C/C++ 和 Go。

而现在，Rust 被正式引入，并被确立为编写新底层基础工具的首选语言，逐步取代 C、C++ 以及部分 Python 的使用场景。

更令人振奋的是，Canonical 不仅仅是自己“用”，他们还在“反哺”生态，充当桥梁。

Jon Seager 谈到了 Ubuntu 作为操作系统发行版的责任——通过支持内存安全的基础设施库来“向前支付（Pay it forward）”。Canonical 正在提供财务和声誉上的双重支持：
1. 赞助 Trifecta Tech 基金会开发 sudo-rs 和 ntpd-rs（用 Rust 重写关键的系统组件）。
2. 赞助 uutils 组织开发 Rust 版的 coreutils（Linux 核心命令集）。

为什么说 Ubuntu 是完美的“标杆客户”？

在 Linux 用户态领域，Ubuntu 的体量和权威性毋庸置疑。当 Ubuntu 愿意承担尝试新事物的风险，并证明“用 Rust 重写 sudo 是可行的且更安全的”时，这种示范效应是巨大的。

那些“早期大众”企业看到这一幕时会想：“如果连 Ubuntu 这样对稳定性要求极其变态的操作系统底层都在用 Rust，那我们的业务系统用 Rust 应该也是安全的。”

这正是《跨越鸿沟》中破局的核心策略：利用标杆客户的背书，提供能无缝融入现有工作流的“即插即用”方案，从而最小化系统的不连续性。

成长的阵痛——为了壮大，Rust 必须改变“人设”

当目标受众从追求极致的“极客”变成追求稳定的“务实派”时，Rust 面临着一种极其尴尬的转型痛点。

Niko 在文中引用了《跨越鸿沟》里的一段话：

“在任何两个采用群体之间的过渡通常都是极度令人尴尬的，因为你必须在你对旧策略感到最舒服的时候采用新策略……当务实派想听到‘行业标准（Industry Standard）’时，科技公司可能还在向他们推销‘最先进的技术（State-of-the-art）’。”

这精准地命中了 Rust 当下的软肋。

在过去的十年里，Rust 社区的营销口号是“零成本抽象”、“无畏并发”、“最先进的内存安全所有权模型”。这套说辞成功吸引了早期的系统工程师。

但如今，当 Rust 走向大众时，普通开发者更关心的是：“有没有现成的库？”、“编译能不能快点？”和“能不能开箱即用？”

核心冲突爆发点：标准库的规模之争。

在闭门晚宴上，Canonical 的 Jon Seager 提出了一个极具挑衅性的观点：Rust 需要重新审视其维持“极小标准库（Small Standard Library）”的政策。

长期以来，Rust 奉行“标准库只包含最核心的类型和原语，其余全部交给社区（Crates.io）”的哲学。比如，Rust 的标准库里甚至没有随机数生成、正则表达式或 HTTP 客户端。这种设计在早期非常受极客欢迎，因为它保证了核心库的轻量级，并允许社区自由竞争出最好的第三方库（如 serde、tokio）。

但对于“早期大众”来说，这简直是个噩梦。他们不明白为什么解析一个 JSON 或发起一个 HTTP 请求都需要在数以万计的第三方包中去筛选、评估安全性、担心供应链投毒。他们想要的是像 Go 语言或 Python 那样“内置电池（Batteries Included）”的开箱即用体验。

实际上，Rust 社区在 2016 年曾推出过一个名为“Rust 平台（Rust Platform）”的提案，试图官方“钦定”一批高质量的第三方包作为“扩展标准库”。但当时遭到了早期采用者的强烈抵制，理由是“直接改 Cargo.toml 很容易，没必要官方下场干预”。

Niko 反思道：当年早期采用者讨厌的东西，恰恰可能是如今“早期大众”最渴望的东西。

Rust 必须面对现实：过去引导其成功的信条，正在阻碍其向更广阔的市场迈进。

Niko 透露，他正在构思一个名为“电池包（Battery packs）”的新项目，试图在不搞庞大标准库的前提下，为企业级用户提供一种官方背书的、开箱即用的库集合方案。这标志着 Rust 正在从“追求它能成为什么样（What it could be）”向“承认它实际是什么样（What it actually is）”的务实转变。

商业与开源的闭环——如何将“采用率”转化为“真金白银”？

任何一门编程语言生态的长远发展，都离不开雄厚的资金支持。随着 Rust 采用率的爆炸式增长，对 Rust 开源项目和生态系统的维护压力也与日俱增。钱从哪来？

Niko 分享了几个关于开源投资的深刻洞见，这不仅适用于 Rust，对所有开源项目（包括 Go、Node.js 生态）都有极大的启发。

洞见一：投资不一定只是“砸钱”，更是“下场共建”。

对于像 Canonical 这样的纯粹开源组织，最宝贵的投资是“建立深度的组织间关系”。

在“Rust for Linux”项目中，早期都是 Rust 核心维护者在帮 Linux 内核开发者修 Bug。但随着时间推移，现在越来越多的 Linux 内核开发者开始自己动手修复 Rust 编译器或工具链的问题，而 Rust 维护者则退居幕后扮演导师的角色。这种“授人以渔”的贡献，比单纯的捐款更有价值。

洞见二：钱往往在公司“采用 Rust 之前”到来，而不是之后。

我们通常认为，企业是在大量使用某个开源软件后，出于反哺或维护自身利益的目的才会掏钱赞助。

但 Niko 观察到了一个完全不同的趋势：更容易获取的资金，来自于那些“正在考虑但尚未采用” Rust 的公司。

在这些公司内部，通常有一批“早期采用者”（内推者），他们试图说服保守的公司管理层采用 Rust。为了促成此事，他们往往需要拿着一份“准入条件清单”——比如，Rust 必须支持某种特定的芯片架构，或者必须具备某个安全认证组件。

更关键的是，这些内推者手里往往握有预算。为了让这门技术顺利落地公司，他们愿意花钱去填补 Rust 生态中的这些空白。

Rust 基金会的 Alexandru Radovici 证实了这一点：许多对安全性要求极高的公司，手里攥着钱想帮 Rust 补齐短板，却“不知道该怎么花这笔钱”。Canonical 赞助 sudo-rs 本质上也是一样的——他们是在花钱扫除阻碍 Ubuntu 更大规模采用 Rust 的障碍。

开源社区需要建立一种机制，精准对接这些带着预算的“潜在采用者”，将他们的痛点转化为开源项目的开发资金。

社区的终极考验——同理心是最大的护城河

在文章的最后，Niko 抛出了一个直击灵魂的观点，这不仅是给 Rust 社区的警钟，也是所有程序员的必修课：

“如果我们在其中表现得太像‘中学生（Middle School）’，那开源跨越鸿沟的愿景就会彻底破灭。”

什么是“中学生”行为？

当你深度参与一个开源社区时，你会觉得这里充满阳光，欢迎所有人。但对于外部的“早期大众”来说，开源社区往往看起来像一个充满小圈子、潜规则和“口口相传的规矩（Oral traditions）”的排外组织。

一个企业级的保守开发者，带着一个务实的业务问题来到社区提问。他可能只是用错了一个术语，或者没有遵循某种隐形的“社区政治正确”，结果就遭到了一群激进贡献者的群嘲、冷嘲热讽，甚至因为提出不同的设计理念而被强硬关闭 Issue。

这位企业开发者根本分不清哪些是喷子，哪些代表官方立场。他只会觉得：“这个语言的社区太有毒了，我们公司还是用 Java 吧。”

只需要一次粗鲁的回复，就能彻底赶走一个潜在的企业级标杆客户。

Niko 强调，帮助 Rust 最终取得成功的，绝不是更快的编译速度或更完美的类型系统，而是“开源中的同理心”。

“早期大众”并不想参与编程语言的“宗教战争”，他们不关心“纯粹性”，他们只是想按时下班，安全地把产品发布出去。Rust 社区必须学会倾听这群人的声音，理解他们的价值观，用温和、包容和同理心去服务他们，而不是用技术傲慢去居高临下地教训他们。

小结：语言的进化，更是心智的成熟

从 2015 年发布 1.0 版本至今，Rust 用了十余年的时间，证明了自己在技术和理论上的卓越。如今，借由 Ubuntu 这样的重磅标杆客户的背书，它正式站在了跨越主流企业级市场鸿沟的跳板上。

Niko Matsakis 的这篇文章，不仅是对 Rust 现状的一份清醒诊断，更是对整个技术生态演进规律的深刻洞察，也非常值得其他主流编程语言的掌舵者和社区学习借鉴。

无论是标准库的扩展、商业投资机制的完善，还是社区同理心的建设，都表明 Rust 正在经历一场脱胎换骨的“成年礼”。它正在从一个由极客驱动的“炫酷玩具”，蜕变为一个能够承载人类核心数字基础设施的“工业巨兽”。

也许属于 Rust 的激荡时代，才刚刚开始。

资料链接：https://smallcultfollowing.com/babysteps/blog/2026/02/23/ubuntu-rustnation/

你认为 Rust 该“扩充”标准库吗？

Rust 坚持“极小标准库”让极客疯狂，却让企业用户头大。你是支持 Go 这种“内置电池”的开箱即用，还是支持 Rust 这种“社区竞争”的极简主义？你在项目中是否也曾因为 Rust 缺乏某个基础库（如随机数、正则）而感到沮丧？

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

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

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

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

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

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

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

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

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

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