Rust - Tony Bai

本文永久链接 – https://tonybai.com/2025/08/18/rust-in-2025

大家好，我是Tony Bai。

2025 年 5 月 15 日，Rust 语言迎来了其 1.0 版本发布的十周年纪念日。这是一个充满里程碑意义的时刻，不仅是对Rust过去十年辉煌成就的回顾，更是展望未来的关键节点。值此之际，Rust 语言团队负责人、核心开发者 Niko Matsakis 发表了一系列题为“Rust in 2025”的纲领性博客文章，系统性地阐述了他个人对 Rust 未来发展的深邃思考。本文将融合 Niko 在十周年庆典上的感言与“Rust 2025”系列的技术蓝图，和大家一起解读一下Niko对下一个时代Rust演进路径的擘画。

回望十年 —— 指引 Rust 航程的两大“北极星”

任何对未来的展望，都必须植根于对过去的深刻理解。在十周年庆典的感言中，Niko Matsakis 将 Rust 的非凡成功，归功于其传奇创始人 Graydon Hoare 从一开始就为这门语言设定的两个坚定不移的“北极星”。它们不仅塑造了 Rust 的技术内核，更铸就了其独特的社区文化。

技术北极星：拒绝妥协，“我们可以拥有好东西”

Graydon Hoare 最初为 Rust 设定的目标是“创建一种‘不会吃掉你衣物’的系统编程语言”。这个看似风趣的目标背后，是一种对行业“常识”的根本性挑战。Niko 将其精炼为一句充满信念的口号：“是的，我们可以拥有好东西 (Yes, we can have nice things)”。

这句话的深层含义在于，Rust 拒绝接受在软件开发中长期存在的、看似不可避免的“魔鬼交易”：

性能 vs. 安全： 传统观念认为，要获得 C/C++ 般的极致性能和底层控制力，就必须放弃内存安全，开发者需要像走钢丝一样，为每一个内存操作的正确性负全责。
抽象 vs. 效率： 高级语言如 Java 或 Go 提供了垃圾回收和丰富的抽象，带来了更高的生产力，但在性能敏感的“基础软件”领域，开发者又必须小心翼翼地规避其抽象带来的性能开销，比如 GC 停顿(STW)。

Rust 的技术北极星，就是要在这一点上实现突破。它通过借鉴 C++ 的“零成本抽象”理念，并独创性地引入所有权、借用和生命周期等概念构成的类型系统，实现了编译期的内存安全保证。这使得开发者能够像使用 OCaml 等高级语言一样，编写富有表现力、高度抽象的代码，同时又能获得媲美 C/C++ 的运行性能。这一定位，精准地命中了“基础软件”开发的核心痛点，也成为了 Rust 在过去十年中攻城略地的最强武器。

文化北极星：社区的力量与谦逊的协作

如果说技术北极星定义了 Rust 的“硬实力”，那么文化北极星则塑造了其无与伦比的“软实力”。Niko 强调，Graydon 从项目伊始就认识到构建正确文化的重要性。这份远见卓识，集中体现在由他亲自撰写的《行为准则 (Code of Conduct)》中。

“提供一个友好、安全和欢迎的环境，无论经验水平、性别认同和表达、残疾、国籍或其他类似特征如何……友善和礼貌应被优先考虑……并认识到‘很少有唯一的正确答案’，‘人们有不同意见’，‘每个设计或实现选择都带有权衡’。”

这些条款不仅仅是空洞的口号，它们已经内化为 Rust 社区的行事准则。Niko 坦言，如果没有这种真正开放、尊重的协作氛围，Rust 绝不会是今天的样子。无数伟大的想法——从 Brian Anderson 创造的、沿用至今的 #[test] 语言基础设施，到 Sophia Turner 和 Esteban Kuber 对编译器错误信息的革命性改进——都源于社区成员的自发贡献。

Niko 分享了一个极具代表性的故事，来诠释这种“集体所有”的文化。2024 年，当计算机科学顶级学术组织 ACM 将其 SIGPLAN 软件奖授予 Rust 时，一个难题出现了：获奖名单上应该写谁的名字？核心贡献者们无法达成一致，提出的名单从数千人到“空无一人”。最终，这份荣誉归于一个由领导力委员会决定的名单，并以 “所有过去与现在的 Rust 贡献者” 结尾。

这个故事完美地诠释了 Rust 的成功之道：它是一场由全球成千上万开发者共同参与的、去中心化的伟大协作。这种文化，是 Rust 能够持续进化、不断吸纳新思想的根本保障。

2025 使命 —— 聚焦基础软件，深化语言哲学

在“两大北极星”的持续指引下，Niko Matsakis 在其“Rust in 2025”系列中，为 Rust 的下一个发展阶段确立了更加聚焦的核心使命：显著降低编写和维护“基础软件 (Foundational Software)”的门槛。

所谓基础软件，即“构成其他一切软件基石的部分”。Rust 如今已在这一领域遍地开花：

云原生基础设施： AWS 的几乎所有服务背后都有 Rust 的身影，其 Firecracker 微型虚拟机更是完全由 Rust 构建。
开发者工具链： 从命令行工具到大型构建系统，Rust 正在重塑开发者的工作流。
终端应用与嵌入式： 亚马逊 PrimeVideo 在 Web 端使用 Rust 编译的 WebAssembly 播放视频；在嵌入式领域，Rust 的应用也已“上天入海”。
操作系统内核： Windows 和 Linux 两大主流操作系统内核，都已开始集成 Rust 代码。

为了让 Rust 在这条道路上走得更远，Niko 提出了几个关键的指导原则，它们可以被看作是 Rust 核心设计哲学的深化与具体化。

原则一：人体工程学飞轮 —— 用“拉伸目标”驱动普适性改进

一个有趣的观点是，Niko 认为尽管 GUI（如 Dioxus, Tauri）或 Web 前端（如 Leptos）可能永远不会是 Rust 的“最佳应用场景”，但这些高层应用的探索对 Rust 而言至关重要。

他将此称为“拉伸目标 (Stretch Goals)”。这些项目试图将 Rust 推向其舒适区之外，必然会对其人体工程学 (ergonomics) 提出更高的要求。为了在这些领域与 JavaScript/TypeScript 等语言竞争，Rust 必须变得更简洁、更方便。而这些为了满足高层应用而进行的改进——无论是更强大的宏系统、更灵活的类型系统，还是更智能的编译器——最终会“涓滴”下来，惠及所有 Rust 开发者，包括那些专注于编写内核模块或网络服务的底层系统工程师。这是一个正向的“人体工程学飞轮”。

原则二：全栈覆盖 —— 单一技术栈的生产力红利

Niko 观察到一个趋势：许多团队最初只打算在某个对延迟敏感的特定服务（如 Discord 的数据平面）中使用 Rust，但最终却将其扩展到整个技术栈。原因在于，一旦团队跨过了最初的学习曲线，Rust 的生产力相当可观。使用单一语言可以共享库、工具和知识，从而极大地降低了维护成本和认知负荷。正如 Niko 所说：“简单的代码，无论用何种语言编写，都是简单的。” 确保 Rust 在高层应用中也“足够好用”，是在为用户提供构建全栈应用的能力，这本身就是一个巨大的价值主张。

原则三：“平滑的迭代式深化 (Smooth, iterative deepening)”

这是 Niko 提出的一个核心设计哲学，也是对 Rust 学习曲线问题的直接回应。他理想中的用户体验应该是：

上手简单： 用户可以快速启动并运行一个简单的项目。
渐进深入： 当项目变得复杂，用户需要更多控制权时，他们应该能够以一种局部化的方式进行优化或重构，而无需一次性学习大量复杂的背景知识。

这个过程应该是“平滑”的，像走在一个缓坡上，而不是面对一面“悬崖”。许多技术要么上手极难，要么从“简单模式”切换到“专家模式”时需要彻底重写或学习一套全新的概念。Rust 并非总是能完美做到这一点，但这是其持续努力的方向。

技术蓝图 —— 以“可扩展编译器”实现“丝滑互操作”

如果说“赋能基础软件”是战略目标，那么 Niko 提出的技术蓝图就是实现这一目标的具体战术。其核心可以概括为一句话：通过构建一个“可扩展的编译器”，实现“丝滑流畅的语言互操作 (silky smooth language interop)”。

核心问题：基础软件生于一个多语言世界

Niko 清醒地认识到，基础软件的世界是异构的。C 语言长期以来是计算世界的“通用语 (lingua franca)”，而 C++ 则构建了庞大的软件帝国。Rust 若想在这些领域取得成功，就不能成为一个孤岛，而必须成为一个优秀的“连接者”。

注：在成为一个优秀“连接者”的道路上，Go恰恰是做的不够好的那一个！

他将语言互操作的需求分为两大场景：

场景一：最小公分母 (Least Common Denominator, LCD)
- 目标： “一次编写，多处使用”。比如，用 Rust 编写一个核心业务逻辑库，然后将其打包成 SDK，供 Android (Kotlin)、iOS (Swift)、Web (WASM) 和桌面端调用。
- 特点： 调用方向主要是单向的（从其他语言到 Rust），暴露的 API 相对简单，易于在不同语言中惯用地表达。
- 愿景：“语言互操作领域的 serde”。 Niko 提出了一个极具启发性的构想。正如 serde 库定义了一套通用的序列化/反序列化 Trait (Serialize, Deserialize)，而具体的数据格式（JSON, YAML 等）则由社区以独立的 crate 实现一样。他也期望能有一个核心的互操作框架，定义通用的 API 规范，然后由社区为不同的目标语言（Python, Java, Swift 等）开发具体的“后端”实现。
场景二：深度互操作 (Deep Interop)
- 目标： 与某一特定语言进行深度、双向的集成。
- 特点： 通常发生在用 Rust 逐步替换大型 C++ 或 Java 应用的模块时，或者在像 Linux 内核这样的 C 项目中嵌入 Rust 代码。这需要处理复杂的类型、内存模型和调用约定。
- 重点：C 和 C++ 是重中之重。 由于历史原因，这两个语言构成了现有基础软件的最大存量。Niko 对 cxx、crubit 等项目以及 Rust 基金会的“Rust-C++ 互操作性倡议”给予了高度评价。

核心解决方案：“可扩展编译器 (The Extensible Compiler)”

如何实现上述宏大的互操作目标？其他语言（如 Swift/Zig 对 C/C++）的做法是，将对特定语言的支持“烘焙 (bake it in)”进编译器。Niko 认为 Rust 应该走一条更具自身特色的道路——构建一个可扩展的编译器。

这个构想的本质，是对现有的过程宏（procedural macros）机制进行一次彻底的“超级充电”。目前的过程宏非常强大，但其接口极其简单：“输入一堆 Token，输出一堆 Token”。它对编译器的内部状态一无所知。Niko 设想的未来过程宏（或者说编译器插件）将拥有前所未有的能力：

检查类型信息： 这是最大的突破。宏将能够查询编译器已经推断出的类型信息，从而做出更智能的代码生成决策。这将彻底改变 ORM、RPC 框架和 FFI 绑定的编写方式。
按需生成代码： 宏将能够在编译的更后期阶段（如单态化 monomorphization）被调用，根据具体的类型实例化请求来生成代码。这意味着可以避免编译大量永远不会被使用的模板代码，同时能与编译器的优化过程更紧密地集成。
影响诊断信息和 Lint： 宏将能向编译器提供信息，以生成更贴近用户原始代码的、高质量的错误和警告信息，而不是目前常常出现的、令人困惑的宏展开后代码的错误。
定制语言规则： 在更遥远的未来，甚至可能允许宏在一定程度上定制方法分发等语言核心行为，为领域特定语言（DSL）的嵌入提供无限可能。

这个“可扩展编译器”的愿景，其影响远不止于语言互操作。它将赋能社区，以 crate 的形式创造出今天难以想象的各种工具和库。Niko 以 F# 的类型提供者 (Type Providers) 为例，展示了这种能力可以如何彻底改变开发者与外部数据源（如数据库、Web API）的交互方式。

注：感叹一下！过程宏如今已经足够复杂了！按这个思路下去，未来将可能更复杂:(，心疼一下过程宏的开发者！不过，对于过程宏的最终用户，也许这能够提供更强大、更智能、更用户友好的功能。

结论 —— 稳定性与进化，无畏地创造未来

“没有停滞的稳定性 (Stability without stagnation)”是 Rust 最重要的价值观。在我看来，一种语言一旦停止进化，它就开始死亡。

Niko Matsakis 的这句话，为整个“Rust 2025”愿景提供了最终的注脚。这份蓝图，正是 Rust 践行“稳定性与进化”并存理念的生动体现。

它同样展现了一种成熟和自信的姿态。Niko 明确表示，我们不需要“Rust 福音派特别行动队 (Rust Evangelism Task Force)”。Rust 的目标不是说服全世界放弃其他语言，而是让 Rust 与其他语言更好地协同工作。当向现有项目添加 Rust 变得异常简单时，它的价值自然会吸引开发者。这是一种基于实力的吸引，而非基于宣传的推广。

在十周年的感言结尾，Niko 也分享了他的个人感悟。作为 Rust 的核心开发者，他们每天面对的是无尽的 Bug、不符合人体工程学的设计和永无休止的 RFC 讨论。有时，这会让人感到沮丧。但他发现，唯一的“解药”，就是走出去和真实的用户交流，去看看大家正在用 Rust 构建的那些令人惊叹的东西。

那一刻，他们会再次记起，这一切的最终目的，是赋能人们去构建和重构我们赖以生存的基础软件。或者，用 Felix Klock 的经典名言来说，就是去“无畏地创造 (hack without fear)”。

Rust 的第一个十年，已经证明了其“北极星”的正确性。而“Rust 2025”愿景，则为第二个十年的航程，设定了清晰、务实且激动人心的航向。这场关于 Rust 未来的对话，不仅关乎一门编程语言，更关乎我们如何构建一个更可靠、更高效、更安全的数字世界。

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/08/16/brand-new-os-impossible

大家好，我是Tony Bai。

对于许多心怀浪漫主义的开发者来说，“从零开始编写一个属于自己的操作系统”，或许是技术生涯中最终极、最性感的梦想。这几乎是现代编程世界的“创世纪”，是掌控计算机每一个比特的至高权力。

然而，最近一位名为 Wildan M 的工程师，在他的一篇博文中，用一次亲身参与 Redox OS 项目的经历，给我们所有人泼了一盆冷水。他的结论简单而又颠覆：

现在，从零开始编写一个全新的、能被广泛采用的操作系统，已几乎是一项不可能完成的任务。

而其真正的难点，并非我们想象中那个神秘而复杂的内核，而在于内核之外，那座看不见的、庞大到令人绝望的“冰山”。

冰山一角：内核，那个“最简单”的部分

故事的主角是 Redox OS，一个雄心勃勃的项目。它旨在用内存安全的 Rust 语言，构建一个现代的、基于微内核架构的、可以替代 Linux 和 BSD 的完整操作系统。

当我们谈论“写一个 OS”时，我们通常指的是编写内核。那么 Redox OS 的内核有多复杂呢？文章给出了惊人的数据：
* 代码量： 约 3 万行 (30k LoC)。
* 启动速度： 大多数情况下，不到 1 秒。

在短短十年间，Redox 团队已经完成了动态链接、Unix 套接字等核心功能。这无疑是令人敬佩的工程壮举。但 Wildan 指出，这仅仅是浮出水面的冰山一角。一个能启动的内核，距离一个“能用”的操作系统，还有着遥远的距离。

冰山之下：生态移植的“五层地狱”

当作者兴致勃勃地想为 Redox OS 贡献力量，尝试将一些现代程序（如 Go, Node.js, Rust 编译器）移植上去时，他才真正撞上了那座隐藏在水面之下的巨大冰山。

一个现代操作系统之所以“能用”，是因为它能运行我们日常使用的所有软件。而将这些软件“搬”到一个全新的操作系统上，需要闯过一重又一重难关。

第一层：系统调用 (Syscall) 的鸿沟

这是最底层的障碍。每个操作系统都有自己的一套与硬件和内核交互的“语言”，即系统调用。Redox OS 的 syscall 与我们熟知的 Linux 完全不同。这意味着，任何需要与内核打交道的程序（几乎是所有程序），都必须重写这部分逻辑，告诉它如何在新世界里“说话”。

第二层：libc 的重担

为了不让每个程序都去痛苦地学习 syscall 这门“方言”，操作系统通常会提供一个标准的“翻译官”——C 标准库 (libc)。它将复杂的 syscall 封装成开发者熟悉的函数（如 printf, open, read）。因此，一个新 OS 的核心任务之一，就是自己实现一个兼容的 libc。Redox 为此用 Rust 实现了一个名为 relibc 的项目，其工程量之浩大可想而知。

第三层：POSIX 的“几乎兼容”陷阱

即便新 OS 像 Redox 一样，努力兼容 POSIX 这个通用标准，噩梦也远未结束。因为无数现有的软件，早已深度依赖于 Linux 特有的、非 POSIX 的功能，比如解析 /proc 文件系统、操作 cgroups 等。结果就是，即使有了 relibc，你依然需要为这些软件挨个打上无数的“补丁”。文章提到，仅 Redox OS 的官方“软件食谱 (Cookbook)”中，就包含了约 70 个这样的补丁。

第四层：编译器的“先有鸡还是先有蛋”

你想在新 OS 上原生编译软件吗？那你首先需要一个能在这个 OS 上运行的编译器，比如 GCC、Rustc 或 Go 编译器。但问题是，移植编译器本身，就是所有软件移植任务中最复杂、最艰巨的一种。它需要处理极其底层的二进制格式、链接方式和系统调用。这形成了一个经典的“鸡生蛋还是蛋生鸡”的困局。

第五层：语言生态的“次元壁”

如果说移植 C 语言程序还只是“困难模式”，那么移植那些拥有自己庞大生态的现代语言程序（如 Rust, Go, Node.js），则是“地狱模式”。这些语言的包管理器（如 Cargo, Go Modules）会从中央仓库下载海量依赖，你很难像修改 C 代码一样，通过一个简单的 .patch 文件来修复所有问题。唯一的办法，往往是去 fork 无数个核心依赖库，然后逐一修改，这几乎是一项不可能完成的任务。