2026年对Rust编译器（Rust compiler）来说似乎有些特别，很多事同时推进；自开始动笔以来，部分事项已经公布，但仍有不少进展尚未公开。今年实为多个计划同时进入最后阶段，工作量并不异常，只是若干长期投入开始产生回报。最大的一件事是下一代trait求解器（next generation trait solver），它重写类型系统的大部分，已开发近10年，修复大量健全性缺陷，并扫清许多功能和长期问题修复的障碍。

你可能已经注意到，2026 年对 Rust 编译器来说似乎有点特别，各种事情集中发生。我动笔时已经有一些事情宣布了，但还有很多不那么显眼。下面分享一些我个人觉得有意思的部分。

先补充一点背景：今年发生的事情是，多个不同举措同时进入最后阶段。换句话说，2026 年并不是工作量突然变大，而是我们开始看到几项长期投入产生回报。

下一代 trait 求解器

最大的一件事大概是下一代 trait 求解器。它是对类型系统很大一部分的重新实现，以各种形式开发了很长时间，差不多有十年。它修复了一批健全性（soundness）bug，并解锁了大量特性，以及长期存在问题的修复。

这对编译器的意义再怎么强调也不为过。这项工作解决了一大块技术债，很多编译器开发者多年来一直盼着有人来做。它还腾出了一批对类型系统有全新且深入理解的人，可以去做新东西。被解锁的队列里包含语言中许多常见痛点，甚至包括一些看似无害或不相关的问题，比如 async Rust 的大问题，或 impl Trait 的各类限制。

Polonius

另一件大事是Polonius，一个新的借用检查器实现，同样开发了很久。它允许更多代码通过编译，并解锁若干相关特性——希望有一天也能支持内部引用（internal references）。它对编译器的冲击不如新求解器那么大，但仍然相当重要。

性能

我主要关注的是编译器性能，这方面也有不少事情在推进。在经历了一到两年的某种停滞（至少在结果上是如此）之后，我们突然同时有很多事在发生。多到我很难全部记住，凭印象来说：

并行前端接近稳定

这是一个很老的举措，曾搁置数年，阻塞点也不清楚。几年前，新贡献者 @SparrowLi 重启了开发，后来也有不少人参与进来。

多年来，这件事变成一个巨大的烂摊子。我感觉几乎没人对现有设计真正满意。但在可预见的未来似乎也没有更好的替代方案，而并行前端又非常值得做，所以最后的解决办法就是硬啃一系列烦人又棘手的问题，直到全部解决。

当前项目目标由 @petrochenkov 推动，已经接近稳定。

LLVM 正在变快

LLVM 23 带来了明确且出乎意料的大幅性能提升。很长时间里，LLVM 升级对 rustc 性能并不友好。LLVM 10 升级后出现了一个 10% 的巨大退步，@nikic（LLVM 现任首席开发者）在博文 Make LLVM fast again 中指出了这一点。他还在文中引入了一套跟踪 LLVM 性能随时间变化的系统，灵感来自我们用于 rustc 的那套。

此后，LLVM 开始更早地发现性能退步，升级到 rustc 的结果从“没那么糟”到“好坏参半”，再到“大体正面但有保留”。上一个这类版本是 LLVM 22，它在 icount 基准上全绿，但在 wall time 上几乎全红。

LLVM 23 则几乎完全是正面的。我不太跟进 LLVM 开发，但据我理解，这是因为现在有更多工作真正去做优化，而不是只做特性却不避免性能退步。这些改进既来自新的优化（有助于在 bootstrap 时优化编译器），也来自 LLVM 本身变得更快。

大量性能改进落地（微优化）

过去几个月，编译器性能持续有一连串改进。大概没有单一原因，而是多重因素叠加：新贡献者加入，老贡献者有更多时间做性能工作，工具改进加上架构清理释放了新机会。

随着更多人投入这一领域，我注意到很多相互启发：某个想法会在几个人的脑子里转，大家受彼此 PR 启发去尝试相关做法。

我们在管理退步方面也做得更好了，包括分类和处理。这既是工具投入，也和流程、社交结构有关。一个主要进展是 tree ops 与性能分类之间的联系，代表性人物是 @JonathanBrouwer。

也就是说，负责合并的人往往会直接评估其性能影响。这很重要，因为它缩短了响应时间，但这种联系还有其他用处。例如，性能影响会决定如何把 PR 分组进 rollups。看来康威定律依然是定律。

我也很喜欢帮人解读测量结果、诊断退步。我常发现，哪怕只是一个多年每天看结果的人说的几句话，也能大大推动退步被解决。

整体来看，编译时间方面的顾虑比以往任何时候都更好地融入了开发过程。

移动消除

这件事今年早些时候似乎是凭空出现的，挺有意思。@Amanieu提议在 MIR 上做一个优化 pass，让编译器能消除那些 LLVM 难以优化的拷贝。它同时加快编译时间和运行时间。

这类 pass 适合放在 MIR 而不是 LLVM 里实现，因为编译器的 Rust 部分更清楚某种优化对 Rust 是否合法；更何况它实际上还需要稍微修改 MIR 的语义。

它对 Rust 尤其重要，因为 Rust 通常比 C(++) 产生更多移动（move），而 C(++) 是 LLVM 的主要目标。

多态化（Polymorphization）

这一项我特别有感情，因为我关注相关努力已经很久了。多态化是我们能做的对编译器性能影响最大的优化之一，但实现起来非常棘手。

据我所知，这将是第三次实验。这一次和之前略有不同，灵感来自 Swift 里的类似机制。

区别在于，原本的多态化只想避免重复或冗余的单态化（monomorphization），因此纯粹是编译期优化，不影响运行时间；而 Swift 风格的做法则打算把一切都多态化，并把泛型参数的布局（layout）作为参数传递。这会有运行时代价，所以可以通过编译器 flag 调整。

如果我的理解还没过时，下一代求解器也会以原本设想的方式启用多态化。不管怎样，两种方案会遇到相同问题，所以工作对两者都有用。也有可能同一份努力会同时产出两种方案。总之，这仍然只是一个有一堆问题要解决的实验，结果如何还得等着看。该项目目标由 @camelid 提出并推动。

cargo check 和 cargo build 共享缓存

@blyxyas 正在做一个项目目标，让 cargo 能在 cargo check 和 cargo build 之间共享产物。这个目标其实更通用，但这可能是最容易看到的效果。这是我们渴望多年的东西，能看到进展真的很棒。

这件事已经宣布，它将把 target 目录大小缩小 5–30%，具体取决于工作负载。

新的 cargo build-dir 布局

这项同样已经宣布，也是开发了相当久的项目。和上面其他事情一样，这是一次重大的内部重构，用于解锁其他能力——具体说就是 target 目录的细粒度加锁，以及跨 workspace 缓存。

no-link / link-only

@bjorn3 一直在修复对这两个 flag 的支持，它们能让构建脚本和 proc macro 流水线化。正如你在提案中看到的，这又是一条“先修掉一长串内部问题和架构问题，然后某天突然解锁一个大能力”的工作路线。

架构

编译器架构方面也有不少举措。我提几个，再次说明一点：大事很少以突然出现的大项目形式发生，而是长期持续投入健康系统后自然产生的结果。

两年前，@jdonszelmann启动了一项工作，统一并清理编译器中属性（attribute）的表示和检查方式。就在几天前，最后一个属性也移植到了新系统。这大幅改进了属性检查，并解锁了诊断等方面的改进。

今年早些时候，@Zalathar 和 @nnethercote 清理了 rustc 查询系统（query system）的实现。这提升了性能，但更重要的是让系统更容易理解，而“难懂”往往是改进它的阻碍。这个系统仍是代码库里相当吓人的部分，但已经前进了一大步。

这个领域其实还有更多架构工作：@oli-obk 一直在做展开期求值（expansion-time evaluation）的架构基础；@cjgilot、@petrochenkov 以及其他我一时想不起来的人（抱歉）在查询和增量方面做了大量工作。类似地，也有很多工作让 const 泛型能继续推进。这些努力的共同点是：让编译器能在更多原本受限的场景中使用自己的能力，而限制往往来自某些编译阶段的严格顺序。

项目目标与资金

元层面（meta）也有不少事。Rust 项目一直在试验一种叫“项目目标（project goals）”的新组织框架。

它经过多轮迭代和各种改动、试验，现在似乎终于达到了某种理想稳定状态，我们也看到了成效。我想从上面的列表就能清楚看到这一点。

我们现在有了 Fast Builds 路线图和多个与性能相关的项目目标，这挺让人兴奋。

资金方面也有多个新进展。其中一个明确与项目目标挂钩；我们还有了新的 “Maintainers in Residence” 项目，并成立了新的资金团队。

另外也不难注意到，过去一年 Hexcat 雇了一批人，产出了很多成果。

……以及我

最后，2026 年对我也确实是激动人心的一年。经过几年旁观、后来加入性能分类工作，我决定更认真地参与 Rust 项目。

今年早些时候，我明显感觉到需要决定下一步做什么。当时的工作慢慢进入维护阶段，我对基于 Web 的工作也有点倦怠，一直想回到更有技术挑战的事情上。

我考虑过几个方向，但一直没法下决心。借用 Marie Kondo 的说法，没有什么真正让我“心动”（spark joy）。在某个经历了一些疲惫事件、心情低落的晚上，我收到了 Rust All Hands 的邀请。这是个惊喜。我那年早些时候报了名，但没抱太大期望，因为不知道受邀概率有多大。我把这当作某种来自宇宙的暗示，订了行程。

这次经历极其正面，是我很长一段时间里参加的最令人兴奋的活动之一。它提醒我，我生活里有很大一块东西几乎无法与任何人分享，尤其是在现实生活里。若不是再次亲身经历，这点很容易被遗忘。

当然，我也能和朋友聊 Rust 编译器里一些有趣的地方，但和真正在做它、能深层理解你在说什么的人聊，完全是另一个层次。见到那些通过网络工作认识的人、加入语言发展的讨论，感觉非常好。

长话短说，我明白了这就是我想做的事。之前我也在想，但大概需要这样一个强烈“心动”的时刻，才能让我不再怀疑自己的感受，逼自己做出决定。

如何获得 Rust 相关工作？

接下来的问题当然是：到底怎么做到？正如你可能知道的（上面我也稍微提过），在这个项目里找一份工作并不简单。没有一家叫“Rust inc.”的公司可以投简历。这里是一个割裂又多样的可能性空间，每个人都得自己找出路。

有了那些新项目后，这条路变得更容易一些，但我预计仍需时间。其中一部分取决于人脉和信任，而这些需要时间积累。我不必着急，会继续做下去，直到想出办法。

如果有足够资金，我已同意去做减小 target 目录大小的项目目标。我也申请了 MiR 项目，但觉得短期内可能轮不到我，因为资金有限，还有更重要的领域更需要这笔特定资金。

结论

项目里发生的事情太多，想写尽真的很难。我已经觉得自己漏掉了大量有趣的工作，但总得画个句号。

我也想说，并不全是正面消息。年初被一堆人失去资金、以及围绕 AI 政策的激烈讨论蒙上阴影。就在 All Hands 前几天，有人把政策草案发到社交媒体，我们小小的 moderation 团队和其他人度过了一个压力很大的周末，努力减少损害。

有鉴于此，我觉得 All Hands 成了一个转折点，让大家可以重新充电、重新聚焦，并把正面能量带回项目。我确实有这种感觉。

多数人对 Rust 编译器一项长期技术债被解决感到振奋，并期待新 solver 与 Polonius 能解锁停滞多年的 specialization。少数人则唱衰 Rust 的必要性，或借题转向求职建议、生态情绪反差等边缘话题。

认为这项 Rust 编译器工作及 Rust 未来值得期待

• 有人强调这对编译器是重大进展，清除了编译器开发者多年想解决的技术债，并称自己等待新 solver 近半个十年，期待它与 Polonius 一起解除 specialization 的多年停滞。（较多人） > 我等这个 solver 至少等了半个十年，希望它和 Polonius 能解锁停滞多年的 specialization（@throwup238）
• 有人从使用者体验出发，希望未来能缩小 Rust 的 target 目录体积，称那会是“救命”的改进，并向相关工作和 Rust 表达祝福。（少数人）
• 有人把这种乐观与不久前 Ruby gem 维护者对 Ruby 未来的挫败作对照，感叹同一行业内因应用场景和处境不同，对语言未来的情绪可以截然不同；他强调并非比较 Rust 和 Ruby。（少数人）

认为在 C 加 LLM 检查内存的背景下 Rust 已不再重要

• 有人反直觉地唱衰：既然可以用 C 写程序，并偶尔让 LLM 扫一遍来捕捉内存问题，Rust 的存在价值就不再明显。（少数人） > 既然可以用 C 编写并偶尔用 LLM 检查内存问题，Rust 就没那么重要了（@lolakutty）

认为想获得 Rust 工作应先入职普通岗位再在岗写 Rust

• 有人给出求职建议：拿到 Rust 工作的最佳方式不是直接寻找 Rust 岗位，而是先找一份普通工作，然后在日常中写 Rust。（少数人） > 拿到 Rust 工作的最佳途径是先找个普通工作，然后直接写 Rust（@vatsachak）

有价值的补充

• Hacker News 上该帖多次提交都被系统换成错误标题；发帖人改用正确标题后仍被覆盖，且当天不允许自行改回，只能次日才编辑成功（@panstromek）。