微软将 Rust 列为内部最高支持等级

据 Rust 基金会 10 月 4 日消息，Rust 已正式成为微软公司内部的”一级编程语言（Tier-1）”，与 C++、C# 和 TypeScript 并列。需要明确的是，这里的 Tier-1 是微软内部对开发语言的支持分类，并非 Rust 开源项目自身的支持等级。

对微软内部开发团队而言，获得 Tier-1 地位意味着今后无需再各自搭建 Rust 相关的开发和生产环境。微软将提供从代码编写、构建、测试到发布和长期维护的一整套标准流程，Rust 项目也将被纳入微软既有的软件安全、合规等开发流程。

此前，微软工程师已使用 Rust 开发软件一段时间。Tier-1 地位的关键意义在于，Rust 不再只是部分团队根据需求单独适配的开发工具，而是正式成为微软内部完全受支持的标准选项。

与 C++ 长期并行，并非替代

微软表示，目前 Rust 已经被应用于固件、驱动程序、内核、虚拟机监控程序、微服务和应用程序等多种场景。不过由于 C++ 已在微软内部使用多年，并广泛存在于 Windows 等大型项目中，未来很长一段时间内，Rust 与 C++ 仍将并行使用。

为了让两种语言更好地协同，微软开发了 rustc_codegen_utc 项目。该项目提供了一种新的代码生成方式，可以让 Rust 编译器直接连接 Windows 平台 MSVC 工具链所使用的代码生成后端。

借助这一机制，Rust 能够更好地与 Windows 现有工具链以及应用程序二进制接口（ABI）协同工作，同时继续使用相关的安全功能、调试工具、崩溃转储分析、性能分析、诊断、代码覆盖率、热补丁和编译优化能力。对于同时包含 Rust 和 C++ 代码的大型项目，微软可以在两种语言之间共享一套底层基础设施，而不必分别维护两套工具和功能。

后端已进入生产环境

微软强调，rustc_codegen_utc 并非实验性项目。该项目从 2026 年初起已具备生产环境使用条件，并从 Rust 1.90 版本开始能够完成自身的编译。目前已有超过 100 个微软项目代码库使用这一后端，未来还将有更多项目采用。

与此同时，微软为 Rust 编译器、标准库及相关工具建立了安全的软件供应链流程，并将其接入本地开发环境、生产流水线以及既有的安全、质量和合规体系。

从整体规划看，微软希望 Rust 覆盖完整的软件生命周期，从获取和构建工具链开始，一直延伸到软件部署、服务维护以及后续更新。随着 Rust 正式获得微软内部 Tier-1 语言地位，其在 Windows、云服务以及其他微软核心软件中的应用范围预计还将进一步扩大。

前二十名排名

TIOBE 9 月榜单前二十名依次为：

1. Python：17.76%（同比 -8.22%）
2. C：10.28%（+1.63%）
3. C++：8.67%（-0.13%）
4. Java：7.54%（-0.81%）
5. C#：4.22%（-2.16%）
6. JavaScript：2.76%（-0.46%）
7. Visual Basic：2.55%（-0.28%）
8. SQL：2.16%（+0.29%）
9. R：1.69%（+0.27%）
10. Rust：1.34%（+0.33%）
11. Fortran：1.24%（-0.25%）
12. Go：1.10%（-1.22%）
13. Delphi/Object Pascal：1.08%（-1.18%）
14. PHP：1.04%（-0.21%）
15. Scratch：0.99%（-0.19%）
16. Assembly language：0.89%（-0.15%）
17. Ada：0.85%（-0.42%）
18. Swift：0.83%（+0.10%）
19. Objective-C：0.81%（+0.32%）
20. COBOL：0.78%（-0.13%）

Julia 距重回前二十仅一步之遥

排在第二十一名的 Julia 本月占比 0.74%，距离重新跻身前二十已非常接近。TIOBE 首席执行官 Paul Jansen 在月度述评中指出，Julia 于 2023 年夏季首次进入前二十，此后一度被挤出榜单，本月则有望卷土重来。

与之相对，长期位居前二十的科学计算语言 MATLAB 本月再降两位，目前已滑落至第二十七名（占比 0.61%）。Jansen 表示，Julia 正是近年来从 MATLAB 手中分走部分市场份额的编程语言之一。MATLAB、Julia、Python 与 R 均在数值计算、科学计算、建模与数据处理领域有深厚积累；过去多年中，Python 与 R 已从 MATLAB 手中获得可观份额，Julia 也在这一细分市场占据了一席之地。

不过 Jansen 也坦言，判断 Julia 能否长期立足仍属难题。该语言目前仍集中在相对小众的专业领域，尚未真正突破为通用型编程语言；其运行速度快，但市场上有更快的选择，学习门槛也低于多数替代方案却并非最低。值得注意的是，在去年 Stack Overflow 公布的「最受开发者喜爱的编程语言」调查中，Julia 甚至未能进入榜单。

第 20 名附近的此消彼长

榜单前十位整体依旧稳定，但第 20 名附近的变化值得关注。Perl 与 Ruby 本月已跌出前二十，为两门「老牌」语言腾出位置——Ada 与 Objective-C 双双重返前二十。两者均问世数十年，却在本月排名中显现出新的活力。

TIOBE 指数通过统计全球工程师数量、课程、第三方供应商以及 Google、亚马逊、维基百科、Bing 等二十余个搜索引擎的检索数据来评估语言热度，每月更新一次。该指数衡量的是编程语言的受欢迎程度，而非语言优劣或代码编写量，可作为开发者评估技能是否过时、或团队立项时选择技术栈的参考。

技术博主 Dan Luu 决定动手验证。他跑了两轮真实规模的评测，结论是：这个被广泛传播的判断，基本站不住脚。

被引用最多的那份数据，题目太简单了

流行说法的源头是一份对比实验，作者从 Rosetta Code 上取题，测量不同语言解同一道题需要多少 token。结果显示，最费 token 的 C 语言与最省的 Clojure 之间存在 2.6 倍的差距；后来又补测了数组语言 J，平均只需 70 个 token，几乎是 Clojure（109 个）的一半。作者由此推断，如果 token 效率真的成为关键驱动力，这可能会成为编程语言演化的一个有趣方向。

问题恰恰藏在这组数字里。Dan Luu 指出，一道能用 70 个 token 解决的题目，根本算不上题目。这类琐碎任务里，大部分工作只是把答案打印出来，性能表现无法推广到需要真正干活的场景。他此前在评测「穴居人模式」提示词时就见过同样的现象：在极简任务上宣称的巨大收益，一旦换成稍微需要动脑的问题就消失了。

另一份支持相同结论的对比实验，毛病更隐蔽。其中一项测试执行了一条并不存在的路径，导致失败；后面某个智能体把这条不存在的路径符号链接到了自己的可执行文件，测试通过了，但代价是此后所有测试都在跑那一个智能体的可执行文件。原作者据此分析 Rust 为何出现失败，实际上只是因为 Rust 的评分环节跑在 Go 智能体做符号链接之前。

两个真实项目：zstd 解码器与 Pandoc

Dan Luu 的做法是自己造评测，并且在看结果之前先公开写下预测。他给出的三条预注册判断是：95% 的把握认为动态与静态语言的整体差异说法不成立；60% 的较低把握认为在超高算力档位下静态语言会稍占上风；98% 的把握认为 J 这类「怪语言」的优势不会成立。

第一轮评测的任务是实现一个完整的 zstd 解码器。智能体拿到 zstd 的 RFC 文档和勘误，被关在没有网络的容器里，不提供测试用例。模型统一用 GPT-5.6 Sol，分 medium 与 ultra 两档算力投入。之所以不给测试，是因为像 zstd 这种覆盖面的项目，测试不可能穷尽所有分支——Dan Luu 本人就曾在这个久经考验的软件里找到过数据损坏的缺陷。

结果分成两层：只看 medium 档，动态语言的确聚集在成本更低、正确率更高的那一侧，看上去支持流行结论；但换到 ultra 档，格局就乱了，排在前列的反而以静态语言居多。真正稳定的规律不在动静态之分上，而在两个别的维度——汇编这类对人类也极其费劲的语言表现明显更差；冷门语言同样吃亏，合理的解释是各家 AI 实验室在小众语言上投入的合成训练数据极少甚至为零。把语言流行度和评测表现放在一起看，能观察到一个弱到中等的正相关：越主流的语言，写出来的代码往往既更正确又更便宜。这与第一份实验推崇 J 这类高密度语言的方向正好相反。

第二轮换了完全不同的任务与呈现方式。Dan Luu 把 ProgramBench 的 Pandoc 评测改造了一下：不做原本的逆向工程题，而是把 ProgramBench 的材料连同测试一并交给智能体，再用一组留出测试来打分，更接近测试驱动开发的节奏。结论依旧：成本与得分和语言的动静态属性没有明显关系，冷门语言仍然吃亏，汇编依旧垫底，而 Clojure 在这一轮比在 zstd 那轮好得多。

Clojure 在第一轮翻车有具体原因：40 次 medium 运行里有 36 次、40 次 ultra 运行里有 5 次出现测试失败，症结是字节转换在 128 到 255 区间抛出异常，或许应该改用 unchecked-byte。这也是一个真实存在的成本——如果没有测试兜住，这类错误会一路带到线上；即便有测试，修它同样要烧掉时间和 token。

哪些流行判断被证伪了

对照两轮数据，几条在社区里流传甚广的说法可以做初步清算：

• 「代码质量参差的语言（比如 PHP）在大模型手里表现更差」——在这两项任务上不成立
• 「既然重写成本变低了，就该用表达力强的语言（比如 Haskell）」——同样不成立
• 「应该选流行语言」——有弱支持
• 「动态语言在小项目上占优，项目变大后被静态语言反超」——这两项任务不支持这一判断，不过两个任务的形态和呈现方式差异太大，无法确定究竟是规模因素还是别的变量在起作用

回看他自己的三条预注册判断，第一条和第三条被证实，第二条（ultra 档静态语言稍好）信息不足，若必须二选一，他倾向于判定为错误。

值得留意的是这套方法本身的意义。Dan Luu 提到，2014 年他梳理过静态与动态类型的学术文献，除少数案例研究外收获寥寥。以一篇典型论文《静态类型系统能改善软件系统的可维护性吗？一项实证研究》为例：33 名受试者被分配修复既有代码中的错误或补全存根方法，静态组用 Java，动态组用 Groovy，采用被试内设计并随机化任务顺序。结论是类型错误场景下 Java 组更快，语义错误场景下没有差异。但该研究刻意回避了循环、递归等复杂控制结构以降低耗时方差，导致所有缺陷都是琐碎缺陷，中位解题时间只有几百秒——这恰恰是最不耗费职业程序员时间的那类问题。

大模型改变了这件事的可行性。让智能体实现一个 zstd 解码器大约花费 20 美元，乘上语言数量和每种条件下的重复次数确实不便宜，但相比雇一位能读懂 zstd 规范并动手实现的职业程序员，这个数量级的研究此前根本不可能做，Pandoc 那一轮更是如此。许多原本无从回答的问题——什么测试手法有效、什么软件架构适合、修缺陷的成本是否因语言而异——如今至少有了动手一试的可能。

至于最终答案，Dan Luu 的态度相当克制：绝大多数关于「某语言特别适合大模型」的流行断言看起来都是错的，但什么才是对的，目前还不清楚。

来源：danluu.com（Dan Luu）