本文永久链接 – https://tonybai.com/2026/08/22/rust-official-learning-rust-journey

大家好，我是Tony Bai。

【导读】

Rust 官方用半年时间，向 4200 名开发者发放问卷、对 70 多人进行深度访谈，试图回答一个老问题：学 Rust 到底难在哪？答案和很多人的直觉不一样——真正卡住大家的不是语法，而是"忘不掉"旧语言的思维习惯；编译器本身就是最好的老师；而 LLM 正在悄悄改写"谁能成为 Rust 工程师"这件事的门槛。

【文章要点】

  • Rust 官方 Vision Doc 项目组历时近一年，完成 4200+ 份问卷调研与 70+ 场深度访谈，是目前罕见的、大规模、官方主导的开发者学习体验研究。
  • 调研方法本身值得借鉴：用“非引导性提问”避免受访者说场面话，例如不问“你觉得借用检查器很难吗”，而问“你上次被报错信息搞懵是什么时候”。
  • 新手最大的坎不是语法，而是“卸载”旧语言（C++/Java）留下的思维惯性，尤其是面向对象习惯和“零 clone 洁癖”。
  • 编译器报错信息本身就是最有效的学习资源之一，多位受访者表示是靠报错“自学”会了生命周期。
  • LLM 正在成为学习工具而非仅是效率工具，一家咨询公司甚至靠“LLM + Rust 编译器”把无编程背景的高中毕业生培养成 Rust 工程师。
  • 存在明显的“静默流失”现象：很多人学不会 Rust 就默默放弃，从不在 Rust 社区发声抱怨，导致这部分声音在官方调研里几乎缺失。
  • 社区氛围直接影响留存：被 maintainer 耐心解答的学生对 Rust 印象深刻，被说“这是你水平问题”的人则悄悄消失。
  • 企业规模化培养 Rust 团队的路径高度一致：Rust 官方教材 + Rustlings + 低风险任务练手 + 内部答疑群。

Rust以难学著称，这几乎是编程语言圈的“政治正确”。

但难在哪里？是语法太怪、借用检查器（borrow checker）太严，还是别的什么原因？大部分讨论都停留在“感觉”层面，很少有人真正系统地问过Rust学习者本人。

Rust 官方这次不一样。今年，Rust项目组内部成立了一个叫Vision Doc的工作组，花了近一年时间，先后完成了一份4200多份回复的问卷调查，又对70多位来自不同背景的Rust用户做了每次约45分钟的深度访谈。他们把访谈过程和发现整理成了一个系列博客，其中一篇专门聚焦“人们是怎么学会Rust的”，干货密度非常高。

这篇文章，就带大家梳理这份调研到底挖出了什么。

一场“非典型”的官方调研

先说说这次调研是怎么做的，因为方法本身就值得借鉴。

项目组请来了一位专业的用户研究顾问Holly Ellis，学习了一套标准的用户研究方法论。团队很快意识到一件事：不能直接问受访者“你觉得借用检查器难吗”，因为这种问法会诱导对方给出一个“应该说”的答案，而不是真实感受。

于是他们改用侧面提问的方式，比如不问"你最大的痛点是什么"，而是问：

“你上一次被一条报错信息搞懵是什么时候？”

然后顺着这个具体场景继续追问下去。这种非引导性的提问方式虽然操作起来更麻烦，但往往能挖出更真实、更意外的信息。

调研也暴露了一个有意思的局限：讨厌Rust的人，普遍不愿意站出来说话。问卷里，49%的受访者给自己的Rust使用体验打了4分或5分（满分5分），只有18.5%打了1分或2分，而这部分人里愿意留联系方式接受进一步访谈的少之又少。用项目组自己的话说：

“不喜欢Rust的人，大多不会去读Rust官方博客，也不太想和一群Rust’粉丝’聊这个话题。”

这也是为什么后续的访谈样本，本质上是“留下来的人”的视角——这一点在后文的“静默流失”部分还会再提到。

进入Rust的人，路径五花八门

调研发现，真正因为“我要学一门新语言”而主动选择Rust的人，只是众多路径中的一种。更常见的情况是：好奇心驱动、因为要做嵌入式项目、就业市场压力、公司整体转型采用Rust、或者干脆是团队重组后“被分配”去写Rust。

最后一种路径尤其值得注意，因为这意味着很多学习者根本不是从零开始“评估”要不要学Rust，而是Rust已经先落地了，人要去追赶。一位身兼多职的CTO这样描述自己的经历：

“说来好笑，我以前推荐过比Rust还小众的语言。现在Rust已经不算小众语言了，但它也还不是Java。”

学习资料够用吗：官方书“过时”了？

大部分受访者的第一站是官方教材《The Rust Programming Language》（俗称“the book”），配合编译器给出的提示边学边练：

“我从官方文档开始学，因为里面有很多例子，能讲清楚借用检查器这类特性到底是怎么工作的。” —— 一家汽车零部件供应商的软件工程师

但也有相当一部分人需要反复“过几遍”，并借助社区资源，比如Rustlings、《The Little Book of Rust Macros》、《Learn Rust With Entirely Too Many Linked Lists》：

“官方书、Rustlings、《Zero to Production in Rust》、Jon Gjengset的教程……看了一堆书。这不是一遍就能读完的东西，我都记不清自己翻了多少遍了。” —— 一位从事视频流媒体与存储的工程师

值得关注的是，不止一位受访者提到，觉得官方教材“跟不上语言的迭代速度”：

“我们本来想用官方那本书，但发现它有点过时了。我们去看了GitHub仓库，发现里面堆了很多没解决的issue和没合并的PR。” —— 某受监管行业里负责Rust落地的首席工程师

这个感受是否“属实”其实没那么重要——重要的是，随着越来越多公司认真评估是否采用Rust，会有越来越多“新用户”用挑剔的眼光去审视这些学习材料，任何看起来“没人打理”的迹象都会被放大解读。

新手最大的坎：不是语法，是“戒不掉”旧习惯

这大概是整篇调研里最反直觉、也最值得国内团队参考的一条结论：Rust学习曲线的真正难点，往往不是语法本身，而是“卸载”此前语言留下的思维定式。

对绝大多数人来说，Rust不是他们的第一门语言，而是第二门、第三门甚至第N门。他们往往会先用最熟悉的方式——C++思维、Java思维、Go思维——把Rust“翻译”一遍，写上几个月甚至几年，才慢慢过渡到符合Rust习惯的写法。

“如果你本来就很熟C，那用Rust确实会有一段生产力下降期，因为你在学新规则、新语法。” —— 一位移动机器人领域的首席固件工程师

“刚开始的时候，我基本就是到处摸索，加加减减&和*这些符号，试图搞明白mut和不mut到底是怎么回事。” —— 一位拥有20年Java经验、现从事云和物联网开发的资深工程师

更有意思的是，有受访者提到，完全没有编程背景的人，反而可能更容易学会Rust：

“我们团队有个人以前几乎没怎么写过程序，直接上手负责我们Rust项目的内部实现，她适应得很好。反倒是资深工程师更容易挣扎，因为他们得先’忘掉’那些在别的语言里行得通、但不是’Rust方式’的做法。” —— 某汽车OEM研发实验室的研究员

这条线索很有价值：没有“磨出旧习惯的沟槽”，或许本身就是一种优势，值得进一步研究。

借用检查器是怎么学会的：三条路径

关于最让人头疼的borrow checker，调研归纳出了几条比较典型的学习路径。

路径一：编译器就是老师。 多位受访者表示，Rust的报错信息本身承担了大量教学功能，尤其是关于生命周期（lifetime）的部分：

“如果你手写代码时把生命周期搞乱了，Rust的报错通常都会讲得很清楚。” —— 一位研究Rust静态分析的研究员

“缺什么，编译器基本都会告诉我：它会说’你需要给这个引用声明生命周期’，然后我就知道该怎么改了。整体来说这套机制运作得相当好。” —— 一位资深软件工程师

路径二：靠写代码“熬”出来的。 也有人是通过大量实战项目、编码挑战反复练习之后才真正“开窍”：

“我真的是写了大量Rust代码之后，才理解借用检查器到底是怎么回事的。” —— 一家Rust创业公司的创始人

“除了自己做项目练手，我还做了Advent of Code之类的编程挑战……到某个节点突然就’咔哒’一下通了，不再是我和Rust较劲，而是Rust开始为我所用。当程序终于符合Rust的要求时，它就是能跑，我不用花时间调试。” —— 一家大型SaaS厂商的首席工程师

路径三：放下“clone洁癖”。 这一条尤其值得单独拎出来说。不少新手一开始就给自己设定了“零clone、零拷贝、生命周期贯穿始终”的高标准，结果反而把自己绕进死胡同：

“我第一个项目的时候，心想’我绝对不要clone或copy任何东西’，于是小心翼翼地把生命周期全部串起来，结果把自己困住了。后来我看到别人直接clone了我正在折腾的那个struct，而且开销很小。有时候直接clone就完全没问题。” —— 一位大学研究员

几乎所有资深Rust开发者给出的建议都高度一致：学习阶段大胆clone，先跑起来，理解问题之后再优化。这种“clone洁癖”本质上是Rust“高性能、高可靠”的名声反过来给新手加的心理包袱——很多人在写出第一个能跑的程序之前，就已经先入为主地认定“不够优雅就是错的”。

课堂实验：C++学生靠LLM交作业，Rust学生靠社区

调研里有一段来自大学课堂的观察格外有意思。一位教授同时教Java、C++和Rust相关课程，在嵌入式课程上做了一个对照实验：一半学生用C，一半用Rust。

“在嵌入式这块，我没看出Rust和C有多大差别。Rust班的反馈整体更差一些，主要是因为他们得自己搭项目。C班的学生直接找LLM生成一个，完全没问题。” —— 该大学教授

也就是说，C语言学生靠LLM“抄”作业毫无压力，Rust学生却做不到——目前还没人能给出确切原因，这也是官方明确标注为“有待进一步研究”的一个悬而未决的问题。

但另一个现象却很清晰：Rust班的学生在遇到嵌入式驱动相关的问题时，教授鼓励他们直接去GitHub上给维护者提issue、提问，而维护者也确实认真回复了。很多从没参与过开源的学生，第一次就得到了代码原作者的亲自解答——这构成了他们对Rust社区最初、也最深刻的好印象。

LLM正在改写“谁能学会Rust”的门槛

LLM是这份调研里绕不开的话题，尽管Vision Doc团队特意声明，讨论范围只限定在“作为学习工具”这一层面，不涉及AI在软件开发中更广泛的争议。

一部分资深从业者把LLM当作快速上手一个陌生领域的辅助工具：

“我挺乐观的，觉得有办法把LLM用进来，缩短学习曲线。这类工具最大的价值之一，就是帮你在一个完全陌生的领域里快速找到方向。” —— 某大型开源Rust crate的维护者

也有人保持谨慎，把LLM当作“更聪明版的Stack Overflow”：

“我大概一个月会试一次LLM，主要是用来生成示例代码。就像读Stack Overflow上的答案一样，你得仔细读、真正理解，而不是复制粘贴——最好是自己用自己的话把代码重新敲一遍再检查，因为魔鬼往往就藏在那些细节里。” —— 一家Rust创业公司的创始人

但最有冲击力的一段访谈，来自一位培训机构的创始人。他的公司在招募完全没有系统编程背景的人，用“LLM+Rust编译器”的组合把他们训练成能干活的Rust工程师：

“一开始我挺担心的，但现在有了LLM帮忙，语言本身的难度已经不是问题了。我在强类型运行时语言（比如Rust）身上看到了巨大的机会……我们在[某发展中国家]招募20到25名高中毕业生，把他们培养成Rust程序员，然后让他们加入我们全球的团队。” —— 某咨询公司创始人

Vision Doc团队对此的态度也很克制：这只是一个案例，不代表能被普遍复制。这些开发者能留多久、能不能独立维护复杂代码、这套培养模式换个组织结构还灵不灵，都是未知数。但如果这个结论真的能推广开来，那意味着“谁能成为Rust工程师”这个人才池，可能比大家想象的要大得多。

企业怎么批量培养Rust团队

对于正在或计划批量引入Rust的团队，调研给出的画像高度一致，几乎是一套“标准流程”：

  • 先用培训课程或官方教材+Rustlings，把团队拉到同一个基线水平；
  • 从低风险、低优先级的任务开始练手；
  • 建立内部答疑渠道（比如专门的Slack频道），营造互相帮助的氛围。

“开这门培训课，而不是让大家’各自去看Rust那本书’，用意就是让每个人有一个统一的起点。” —— 移动机器人领域首席固件工程师

“通常我们会让大家先过一遍Rustlings，再过一遍官方教材，然后开始接手一些低风险的票据（ticket）。” —— 某大型SaaS公司首席工程师

一些企业还发现，与其花两年时间苦苦寻找一个C++高手，不如直接招不懂Rust的人，慢慢带起来：

“他们需要维护和扩展一个C++代码库，原来有个C++大神，结果他们花了差不多两年都没找到同等水平的替代者。最后干脆招了完全不懂Rust的人，慢慢带起来，还从C++那边做了FFI绑定，让新人能在Rust那侧工作。能感觉到，借用检查器正在’教’这些人用正确的方式处理系统层面的问题。” —— 某汽车OEM首席工程师

被忽视的“静默流失”

如果说前面几部分讲的是“留下来的人怎么学会的”，那这一段讲的是“离开的人为什么走”——这也是整篇调研里，笔者认为最值得警惕的一个发现。

有受访者提到，一位朋友因为受不了Rust嵌入式生态的严格约束而彻底放弃：

“那种嵌入式生态对一个习惯了C的人来说会非常令人抓狂：为什么我不能直接拿到一个指向外设的指针、然后往寄存器里写数据？你们到底在搞什么？……我朋友一直没能过这个坎，看了看就说’我不想折腾这个’，然后就走了。” —— 另一位大学教授

更值得关注的是社区氛围本身可能正在“劝退”一部分人：

“大家其实挺乐于助人的，但普遍的态度是：如果你的程序写得很复杂，那基本就是水平问题。人们卡壳的时候，很少能得到真正的共情，很多人就这样被悄悄推开了。可能有大量人默默地放弃了写Rust，因为写到一定复杂度之后，得到的反馈却是’你显然需要提升自己的水平’。” —— 某SaaS公司软件工程师

问卷里也收集到了类似经历，有人是在1.0版本发布前“折戟”、之后又重新捡起来学会的：

“我在1.0之前就开始学了，很快就卡在把C++的思维模式往Rust上套（借用检查的问题）。1.0之后我又试了一次，这次就学会了。” —— 问卷受访者A

Vision Doc团队坦诚地指出，这部分内容其实是整份调研里样本最不完整的一块：几乎所有能被访谈到的人，都是那些坚持下来、依然活跃在Rust渠道里的人；真正“悄悄离开、再也不回来”的那批人，几乎无法通过现有渠道触达。如果后续真的成立专门的用户研究团队，“访谈那些放弃了Rust的人”会是一个很好的切入点。

Rust官方给出的建议清单

基于这些发现，Vision Doc团队给出了几条值得尝试的方向：

  • 针对“卸载旧习惯”专门做学习材料。 目前大多数教材都是从零基础讲起，但很少有材料专门写给“一个有十年Java经验、刚被调来写Rust的工程师”，明确告诉他们哪些老习惯用不了、该换成什么做法。
  • 把“学习阶段大胆clone”这条建议写进官方材料。 这几乎是所有资深开发者的共识，但目前基本靠“运气好碰到有人告诉你”，写进官方文档能省掉很多人的弯路。
  • 继续把编译器诊断信息当成重要的学习入口来打磨。 很多人是靠报错信息自学会了生命周期，写新的诊断提示时，应该同时考虑专家和困惑中的新手两种视角。
  • 正视“官方教材过时”的观感问题。 不管材料是否真的落后，issue和PR堆积本身就会让评估中的团队产生负面印象，做好可见的issue分诊、公开沟通“哪些内容是最新的、哪些正在计划中”，比闷头改内容更重要。
  • 社区对待“卡壳新人”的方式，正在决定谁会留下来。 被maintainer耐心回应的学生对Rust印象深刻，被说“这是水平问题”的人则悄悄消失——这不是小事。
  • 企业规模化培养Rust团队的路径已经相当成熟，不需要每家公司都重新摸索一遍。

小结

这份调研最打动人的地方，不是“证明了Rust好学”或者“证明了Rust难学”，而是把过去停留在论坛吵架和个人经验层面的争论，第一次拉到了系统性的证据层面。

对国内正在或计划引入Rust的团队来说，这份调研里有几条经验其实可以直接落地：与其让新人自己摸索官方教材，不如先明确告诉他们“哪些C++/Java的老习惯在Rust里行不通”；与其纠结要不要招“懂Rust”的人，不如参考这些企业的经验，招人进来、用培训+低风险任务把团队一起带起来；而团队内部对“卡壳”的容忍度，可能比任何一份学习资料都更决定新人能不能留下来。

至于LLM能在多大程度上重塑Rust的学习门槛，目前还只是一堆值得追踪的线索，而不是定论。但可以确定的是，这件事正在发生，也值得持续关注。

参考资料：

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

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

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

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

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

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

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

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

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