-
作者：Jack Huey（代表 Vision Doc 工作组）
「Rust 难学，但学会了就好了。」
这句话在 Rust 社区流传已久，几乎成了一种安慰新人的口头禅。但 Rust 官方 Vision Doc 工作组在对大量开发者进行系统访谈后，得出了一个更复杂的结论：
挑战不会因为你学会了 Rust 就消失，它们只是换了一张脸。
新手被借用检查器绊倒，资深开发者被 async 的复杂性困住，嵌入式开发者面对稀缺的 no-std 生态，安全关键系统团队担忧认证工具的空白。不同人群在不同阶段面对的是完全不同的墙。
这篇博客，是 Rust 团队罕见地把这些问题摆到台面上公开讨论的一次尝试。
编译速度：唯一一个折磨所有人的问题
访谈涵盖了从初学者到专家、从嵌入式到 Web 的所有群体。在所有挑战中，只有一个被每一个群体都提到了：
编译太慢。
"Java 大概 100 毫秒，Rust 视改动量从 5 秒到 1 分钟不等。" ------ 大型公司后端系统资深工程师
"改一下 UI 里盒子的 padding，要等 10 秒以上的迭代周期......这是我们默默接受的痛苦。" ------ GUI 开发团队
这不只是「等待几秒」的问题，博客用「开发速度税」来形容它：每一次改动都要缴这笔税，时间长了会严重打击迭代意愿。对于 GUI 开发者来说，视觉反馈本来就需要高频迭代，10 秒的等待足以让思路断掉；对于安全关键系统团队来说，有人提到一次完整构建需要 25~30 分钟，「等半小时才知道自己写错了」是真实存在的工作流。
好消息是，社区已经有一些值得关注的尝试：
-
subsecond：Dioxus 团队开发的热重载 crate，目标是让 GUI 开发不再需要每次都全量编译；
-
Wild linker：面向 Linux 的高速链接器，计划支持增量链接。
官方的建议是，应当把编译性能作为语言层面的一等公民来对待，而不是一个可以等待的「实现细节」。
借用检查器：先苦后甜，但苦的时间因人而异
借用检查器是 Rust 最具辨识度的设计，也是新手遇到的第一道坎。
"第一次读那一章的时候，我真的觉得，这是什么东西？" ------ 把 Rust 作为第一门编程语言学习的开发者
"我真正理解借用检查器，是在花了大量时间写 Rust 之后。" ------ 某开发者工具公司高管
访谈数据支持了一个有些「残忍」的事实：借用检查器的学习曲线确实主要影响新手，资深 Rust 开发者基本不再把它当作痛点。但「资深」的门槛并不低，即使是已经能流畅写 Rust 的开发者，偶尔还是会被借用检查器卡住。
这里面还有一个背景差异：有 C/C++ 经验的开发者需要「忘掉」一些指针相关的直觉；而从高级语言（Python、TypeScript）转来的开发者则需要从零建立对底层内存模型的认知，两条路的难点完全不同。
async：Rust 的另一道深坑
如果说借用检查器的问题会随时间消退，那 async 是一个完全不同性质的挑战------它是一个持续影响有经验开发者的问题。
"我对 Rust 最大的抱怨就是 async。如果要用某个工具，就被迫进入那个模型......不只是换了一门语言，而是换了一种编程模型......我完全没有经验，我一直在回避它。" ------ 在大型公司做安全 agent 的开发者
"当 Rust 同时用了 async、泛型和生命周期，那些类型就变得极其复杂，你基本上得是某种 Rust 神。" ------ 有生产 Rust 经验的软件工程师
"总体印象其实相当负面。感觉没做完......需要大量晦涩的知识。" ------ 研究软件工程师
博客把 async 的问题概括为三个层面，并戏称其为「三骑士」：
语言层面的不完整感。 async 在某些语言特性上落后于同步 Rust，例如在 dyn trait 中使用 async 函数，至今仍未稳定。
生态碎片化。 生态中存在多个异步运行时，tokio 是事实标准，但并非唯一选择。一旦依赖了某个库，往往就隐性绑定了它的运行时，这种锁定会影响整个项目的架构决策。
"还是有很多情况，你找到一个看起来有用的库，然后发现它立刻把你锁进了 tokio 或其他某个运行时。" ------ 社区开发者
文档与学习资料的缺位。 《Rust 程序设计语言》这本官方书主要聚焦于同步代码，async 的系统性教程至今稀缺，形成了博客所说的「悲伤鸿沟」------基础 Rust 和 async 编程之间存在巨大的学习断层，需要投入大量精力才能跨越。
生态导航：选择困难与默会知识
Rust 的 crates.io 上有大量库，但这反而成了一个问题。
"人们不用 Rust 的最大原因，是他们进入的生态圈和预期不符。既没有 C++ 那样的工具链，也没有相应的库。" ------ 大型科技公司开发者
"crates 基本上是不可被发现的......你用哪些 crate 来做具体的事，这是一种通过经验积累的默会知识。" ------ Web 开发者
问题不是库不够多，而是选对库需要一种新手并不具备的专业判断力。哪个 crate 在生产环境经过验证？哪个已经停止维护？哪两个 crate 在运行时会冲突？这些知识散落在社区讨论里，没有系统性的入口。
Rust 团队坦承，这个局面有一部分是官方有意为之的结果：为了不扼杀创新，官方刻意不对特定 crate 给予背书，但这个取舍是否仍然合适，团队认为值得重新评估。
不同领域各有各的难题
除了上述普遍问题，不同使用场景还叠加了专属挑战：
嵌入式开发者 面临资源双重约束：debug 构建体积往往超出小型控制器的存储上限，被迫使用优化构建，而优化构建又让调试变得困难；no-std 生态虽然在成长，但缺口依然显著。
安全关键系统团队 需要 Rust 的内存安全保证，却苦于缺乏与 C++ 同等成熟度的认证工具链。加之 Rust 版本迭代快，与安全关键领域对稳定性的严苛要求之间存在天然张力，即便技术优势明显，管理层的信任也难以快速建立。
GUI 开发团队 将编译速度的痛苦放大到极致------视觉调整本来就需要高频反馈，等待 10 秒才能看到一个 padding 改动的效果，是对开发体验的持续消耗。
官方给出的四条建议
基于访谈数据，Rust 官方工作组提出了以下方向：
一、将编译性能作为一等公民
增量编译改进、构建系统创新、减少迭代周期------这是覆盖所有用户群体的最高优先级改进方向。
二、加强生态引导与跨 crate 兼容性
帮助用户找到适合的 crate，同时推动生态中更好的兼容性，减少因库选择导致的架构锁定。
三、针对不同背景提供差异化学习路径
来自 C++ 的开发者和来自 Python 的开发者，需要的不是同一份教程。直接对比「引用 vs 指针」、提供领域专属的学习材料（如《嵌入式 Rust 指南》已经做到了），比通用教程更有效。
四、弥合 sync 与 async 之间的鸿沟
短期内可稳定 dyn trait 中的 async 函数等已久等的特性，改善编译器对 async + 生命周期问题的错误提示；中期可将基础 async 特征和函数纳入标准库，从根本上改善生态碎片化。
一句话的底色
博客最后引用了一位工程师的话，某种程度上也代表了大多数 Rust 用户的心态：
"如果这些问题都解决了，我会是一个快乐的 Rust 程序员。如果没有，我还是会是一个 Rust 程序员。"
挑战存在，但 Rust 解决的问题是真实的，这是它至今仍被广泛需要的原因。承认挑战，是改进的起点。
参考资料：
- 原文：blog.rust-lang.org/2026/03/20/...
- Rust 安全关键系统专题：blog.rust-lang.org/2026/01/14/...
- subsecond 热重载 crate：crates.io/crates/subs...
- Wild 链接器：github.com/davidlattim...
- Rust 生态中的 async 追踪：github.com/rust-lang/r...