如果你关注编程语言生态，一定听过一个被反复念叨的数据：Rust 已经在 Stack Overflow 开发者调查中连续约十年蝉联"最受喜爱的编程语言"（Most Loved）。在一个喜新厌旧的行业里，一种语言能被开发者死心塌地爱这么久，几乎是个奇迹。但奇迹的另一面是一个尴尬的现实——这份"爱"并没有转化为同等的市场份额。Python 满大街都是，Java 仍是企业巨兽，JavaScript 统治了 Web，而 Rust 在 TIOBE 指数里长期徘徊在十名开外。
这个"爱它的人多，用它赚钱的人少"的悖论，正是 JetBrains 这期长达 80 分钟访谈的核心命题。受访者 Jon Gjengset（社区 ID: jonhoo）可能是当今最有资格回答这个问题的人之一——MIT PDOS 实验室博士、高性能流式数据库 Noria 的作者、Rust 进阶圣经《Rust for Rustaceans》的作者、深耕 Rust 教育十年的顶流直播主，如今是欧洲防务 AI 公司 Helsing 的 Principal Engineer。当一个既懂底层系统、又懂工程落地、还懂如何把语言讲明白的人坐下来谈"Rust 到底卡在哪"，这段对话就值得每个关心技术趋势的开发者认真看完。本文在还原访谈核心观点的同时，补充了大量访谈之外的技术背景与延伸分析，帮你把这场对话榨干。
| 项目 | 内容 |
|---|---|
| 视频标题 | Rust 2026: \$400K Salaries, Java, AI & Why It's Not Everywhere (Yet) |
| 频道 | JetBrains |
| 受访者 | Jon Gjengset（jonhoo）— MIT 博士、《Rust for Rustaceans》作者、Helsing Principal Engineer |
| 访谈者 | Vitaly Bragilevsky — JetBrains 开发者布道师、《Haskell In Depth》作者 |
| 时长 | 约 1 小时 20 分钟 |
| 播放量 | 约 19.9 万次（截至撰写时） |
| 发布日期 | 2025 年 10 月 9 日 |
| 核心主题 | Rust 的采用困境、薪资真相、LLM 写 Rust 的局限、Rust vs Go 之争 |
访谈绕不开的第一个数据就是 Stack Overflow 的那份调查。Jon 对它的态度相当诚实——他没有顺着"Rust 就是最有吸引力的语言"这种讨喜的结论往下说，而是给出了一个更理性的解释（这一点在 Rust 官方论坛的讨论中被多位资深开发者专门点赞，认为他"比大多数人都更诚实地对待了这份调查"）。
关键在于区分两个维度："loved"（喜爱）衡量的是情感与意愿，"used"（使用）衡量的是真实市场。Rust 的高喜爱率主要来自一个自我强化的群体——用过它并留下来的人，几乎都会爱上它；但能"用过它"的前提，是你所在的公司愿意为 Rust 项目买单，而这样的岗位在整个就业市场里仍是少数。也就是说，Rust 的喜爱率是被一个高度同质化、高度自选（self-selected）的样本抬起来的。喜爱率高，恰恰可能说明它的渗透率还不够——因为还没有大量"被迫用它但又不喜欢它"的人来稀释分数。
延伸分析：这其实揭示了一个反直觉规律——一种语言越普及，越容易招黑，因为它必然卷入了大量并非自愿的使用者。Java、JavaScript 之所以口碑两极，正源于此。Rust 目前的"全员好评"，某种程度上是它"还不够大众"的副产品。
访谈里最吸睛的数字是 Jon 对资深 Rust 开发者薪酬的判断——"我预期总包（total compensation）大约在每年 40 万美元"。这句话在评论区炸了锅，尤其在欧洲开发者中间。一位欧洲开发者在论坛里苦笑："我做着要求更高、技能更强的活，年薪大概是这个数字的十分之一。"
怎么理解这个 \$400K？它不是 Rust 生态繁荣的证据，而是 Rust 人才极度稀缺的信号。供给端：能熟练驾驭所有权（ownership）、生命周期（lifetime）、异步（async）的资深工程师，全球就那么多；需求端：AWS、Google、Microsoft、Cloudflare、Helsing、1Password、Discord……一线基础设施和安全敏感型公司都在抢人。需求远大于供给，价格自然被推高。换句话说，\$400K 是"全美国、最顶尖、少数几家头部公司"的行情，中位数远低于此。但这个信号本身很有意义：当一个语言能让开发者拿到溢价薪资，说明产业界正在为它的能力买单，即便它还没有渗透到普通业务系统中。
视频原话强调"Rust 是最令人向往的语言，部分原因在于 AI 被过度炒作"。这里埋了一个关键论点，我们在第四点展开。
这是整场访谈的题眼——"Why It's Not Everywhere (Yet)"。综合 Jon 的论述与 Rust 社区的长期讨论，拦路虎主要有四个：
1. 生态引力（Ecosystem Gravity）。 Java 有三十多年沉淀下来的庞大类库与企业中间件，Python 有科学计算与 AI 的全套工具链。Rust 的 crates.io 增长很快，但在很多垂直领域（尤其是企业遗留系统、大型 ERP、金融交易中间件）仍远不及 incumbents。重写一个成熟的生态，从来不是靠语言本身优秀就能完成的。
2. 与"旧世界"互操作的成本（FFI）。 Jon 在访谈中明确提到，要不要"绑定其他语言的二进制代码"高度依赖每家公司的既有资产。绝大多数公司不会从零开始，它们要在海量的 Java/C++/Python 代码之上增量演进。Rust 通过 FFI（外部函数接口）可以调用 C，但跨语言边界的内存所有权、错误处理、并发模型对接，都是实打实的工程负担。只要这层胶水代码的成本高于"继续用旧语言"，迁移就不会发生。
3. 人才稀缺与团队复制成本。 论坛里有一段很尖锐的交锋：一位 Go 开发者指出，"Rust 的资深团队通常比 Go 的'普通'团队贵得多"，如果"上市时间"（time-to-market）与团队熟练度强绑定，那么用 Rust 的总成本——无论是时间还是金钱——可能并不低。Jon 的回应是：这是一次性成本，而开发是持续性成本；只要团队能找到足够的高级开发者，长期看 Rust 在"开发成本 + 技术债"上的总账更划算。这个分歧本质上是"短期 velocity"与"长期 maintainability"的权衡，没有标准答案，取决于你公司的业务周期与人才储备。
4. 编译速度与学习曲线。 这两项是 Rust 长期被诟病的体验问题。Borrow checker 对新手是一道陡峭的认知墙，大型项目的编译时间也常以分钟计。尽管 cargo、rust-analyzer、增量编译在不断改善，但对习惯了 Go "秒级编译、开箱即用"体验的团队，这仍是迁移的真实阻力。
延伸分析：把这四点放在一起看，Rust 的处境其实很像当年的 Linux 内核之于桌面操作系统——技术上无可挑剔，但"技术好"从来不是大规模采用的充分条件。采用是由生态、人才、迁移成本、惯性共同决定的政治经济问题，而非纯粹的技术优劣问题。
这是整场访谈最有思想深度、也最值得反复咀嚼的部分。Jon 明确表示"AI 被过度炒作（overhyped）"，而他给出的技术理由，远比泛泛的"AI 不靠谱"要深刻得多。
LinkedIn 上一位听众（kriskang）准确转述了这个观点的内核："Jon 推测，LLM 目前还无法归纳（induct）底层的推理逻辑。" 把这句略带学术味的话翻译成工程师能懂的语言——Rust 的核心难点在于它的所有权与借用检查器（borrow checker），这本质上是一个对"别名（aliasing）、生命周期、可变性"这三个维度的约束求解问题。要写对一段 Rust 代码，你不能只是"模式匹配"出看起来合理的语法，你必须真正推理清楚：哪个变量拥有这块内存？谁借用了它？借用是可变的还是不可变的？这些借用会不会在同一时间重叠？这些约束之间会不会冲突？
LLM 擅长的是统计层面的模式续写——给它一段 Python 或 JavaScript，它能凭借海量语料续写出概率上最可能的下一行。但 Rust 要求的不是"最可能"，而是"在约束求解器面前成立"。一个看起来完全自然、在 Python 里毫无问题的代码片段，在 Rust 里可能直接编译不过，因为它违反了别名规则。LLM 目前缺乏对这种约束系统进行可靠归纳推理的能力，因此它在 Rust 上的表现，显著弱于在弱类型、动态语言上的表现。
Rust 官方论坛的一位资深开发者评价 Jon 的立场"非常明智"，并认为这段话至少能"给那些仍以为 AI 是写代码可靠方式的人提供一些思考的养料"。我个人认为这个观点的意义甚至超出了 Rust 本身：Rust 用编译期约束，无意中成了一道抵御"AI 生成代码泛滥"的天然护城河。当 Python 仓库正被 AI 生成的低质量代码淹没时，Rust 的 borrow checker 会无情地把那些"看起来对但经不起推敲"的代码挡在编译门外。在未来很长一段时间里，"AI 写不好"反而可能是 Rust 在工程质量上的一项隐性优势。
Jon 在访谈里对 Go 的评价"毫不留情（didn't mince his words）"，引发论坛激烈辩论。他大致的论点是：对于已经熟练的团队，Rust 在"开发成本 + 技术债"的总账上更有利，而且开发体验（fun factor）也更好。
Go 阵营的反击很到位：为什么要拿"土豆（Go）"和"根芹（Rust）"做比较？Go 的优势恰恰在 Rust 不擅长的地方——上市速度快、可移植性好、部署简单（单个静态二进制）、技术债"利率"低、上手门槛低。这些都是软件工程"聪明程度"之外的维度。论坛里有人进一步指出：Rust 的熟练团队"显著贵于"Go 的普通团队，所以"上市时间与熟练度强绑定"意味着 Rust 在时间和金钱上的总成本，可能持平甚至更高。
这场争论没有裁判，因为它根本不是同一个赛道。Go 是为"团队规模可扩展性"和"开发速度"而生的语言——它的简洁是为了让 100 人的团队里水平最差的那位也能写出不出大错的代码；Rust 是为"正确性"和"长期维护成本"而生的语言——它的复杂是为了在编译期消灭整类 bug。选择哪种，取决于你的业务更怕"慢"还是更怕"错"。一个三个月就要上线的内部工具，Go 几乎总是更优解；一个要跑十年、一次崩溃就损失数百万的核心系统，Rust 的前期成本会被长期回报彻底摊平。
我的判断：Go 与 Rust 会在未来十年长期共存，各自统治自己的地盘。声称谁将"取代"谁，都是对两种语言设计哲学的误读。
如果说前面的论述偏理论，那 Helsing 就是 Rust 最有力的实战背书。这家 2021 年成立的欧洲防务公司，从第一天起就把整个工程栈押在了 Rust 上——而它做的，恰恰是"正确性不可妥协（correctness is non-negotiable）"的安全关键型（safety-critical）软件。
Helsing 的 Rust 实践里，有几个细节尤其能说明这种语言的威力：
Helsing 选中 Rust，参与欧洲台风战斗机（Eurofighter）升级、研发自主无人作战飞行器。这些场景里，一个内存安全漏洞可能意味着人命与国家安全的代价。这正是 Rust 内存安全（无 GC、无数据竞争）的最大用武之地。
把 Helsing 的实践抽象一层，就能看到 Rust 真正的哲学：把尽可能多的正确性，从运行时推到编译期。所有权管内存，生命周期管引用有效性，Send/Sync 标记管线程安全，新类型模式（newtype）管单位与领域语义。结果是那句被反复印证的 Rust 格言——"If it compiles, it (mostly) works"（能编译，就基本能跑）。
这与 C/C++ 的"运行时发现崩溃"、与动态语言的"线上才暴露错误"形成鲜明对比。代价是编译时间长、学习曲线陡；回报是软件在交付时就已经排除了整类 bug。在安全关键、长生命周期的系统里，这笔交易极其划算。
难能可贵的是，Jon 和 Helsing 都没有把 Rust 神化。访谈与播客反复强调一个安全原则——纵深防御（Defence in Depth）：即便用了 Rust，仍需要多层独立防护，不存在银弹。Rust 消除的是内存安全与数据竞争这一大类 bug，但逻辑错误、API 误用、配置失误、供应链投毒，它一个都挡不住。
供应链安全正是 Rust 生态的新前沿。CVE-2024-24576——Cargo/tar 的一个供应链漏洞——提醒所有人，"内存安全语言"不等于"安全软件"。Helsing 的应对是：用 Cargo 的 lock 文件生成 SBOM（软件物料清单）、用 AI 辅助审查引入的依赖包（AI-assisted vetting）。这里出现了一个有意思的反讽：Jon 一边说 AI 写代码被过度炒作，一边在用 AI 审查依赖——因为"审查海量第三方代码"恰恰是 AI 模式匹配能力真正适用的场景。工具与场景的匹配，远比"AI 万能 / AI 无用"的二元论重要。
flowchart TD
A["Rust 悖论<br/>十年最受喜爱 vs 渗透率有限"] --> B["现象层：SO 调查的陷阱"]
A --> C["经济层：人才供需"]
A --> D["技术层：四大拦路虎"]
A --> E["认知层：AI 与未来"]
B --> B1["loved ≠ used<br/>高喜爱率来自自选样本"]
B --> B2["越普及越招黑<br/>全员好评反证小众"]
C --> C1["$400K 薪资是稀缺信号"]
C --> C2["资深 Rust 工程师供给不足"]
D --> D1["生态引力<br/>Java/Python 历史积累"]
D --> D2["FFI 互操作成本"]
D --> D3["人才与团队复制成本"]
D --> D4["编译速度与学习曲线"]
E --> E1["LLM 难以归纳<br/>所有权约束求解"]
E --> E2["Rust 抗 AI 生成代码泛滥"]
D3 --> F["Rust vs Go 之争"]
F --> F1["Go: 速度/团队可扩展性"]
F --> F2["Rust: 正确性/长期维护"]
D --> G["实战背书: Helsing 全栈"]
G --> G1["sguaba: 编译期防单位错误<br/>→ 火星轨道器式灾难"]
G --> G2["correctness non-negotiable"]
G --> G3["纵深防御: Rust ≠ 银弹<br/>CVE-2024-24576 / SBOM"]
F2 --> H["哲学内核:<br/>把正确性推到编译期<br/>If it compiles, it mostly works"]
对个人开发者：把 Rust 当作职业护城河。 Jon 的 \$400K 论断揭示了一个残酷但有利可图的事实——Rust 人才稀缺，且短期内不会缓解。更妙的是，正如第四点分析，Rust 的编译期约束让它在"AI 生成代码"的浪潮里相对免疫。当一个领域既稀缺又难以被 AI 取代，它就值得你投入时间。建议路径：先啃下《The Rust Programming Language》官方书，再用 Jon 的《Crust of Rust》直播系列打通所有权与生命周期的任督二脉，最后用一个真实项目（实现一个小型数据库、HTTP 服务器或 CLI 工具）巩固。
对技术决策者：用 Rust 的"时机判断矩阵"。 何时该选 Rust？当你的系统满足以下任一条件：(1) 安全关键或生命攸关；(2) 性能瓶颈明显，CPU/内存是硬约束；(3) 代码要跑五年以上，长期维护成本主导；(4) 并发复杂，数据竞争是真实风险。何时不该选？(1) 快速原型与 MVP（用 Python/Go 更快）；(2) 团队没有 Rust 专家且业务紧迫；(3) 项目严重依赖某个非 Rust 生态的庞大库。
对团队：渐进式采用，而非全盘重写。 Helsing 的全栈 Rust 是特例（新公司、安全关键赛道）。对绝大多数公司，现实路径是：在新的性能/安全关键模块上引入 Rust，通过 FFI 与既有 Java/C++/Python 代码共存。用 Rust 重写最痛的那一块（比如一个被数据竞争折磨的并发模块、一个被内存泄漏拖垮的服务），让团队在真实收益中积累经验，而不是赌上整个系统做一次高风险迁移。
一个被忽视的洞察：用 AI 审代码，而不是用 AI 写 Rust 代码。 借鉴 Helsing 的做法——在 Rust 项目里，让 AI 发挥它"海量模式匹配"的长处去审查依赖、生成测试用例、辅助 code review，而不是让它直接生成核心逻辑。这恰好绕开了 LLM 在约束求解上的短板，又用足了它的优势。
Rust 之所以十年最受喜爱却仍未普及，是因为采用是生态、人才与迁移成本的政治经济问题，而非技术优劣问题——而它的编译期约束，恰恰让它在 AI 代码泛滥的时代，成为一道稀缺的、难以被替代的工程质量护城河。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。