Rust 在微软成为一级语言

原文 ↗ Hacker News 讨论 ↗

微软将 Rust 设为与 C++、C# 和 TypeScript 并列的“tier‑1”内部语言，表明其对内存安全系统编程和更深度工具链集成的重大押注，其中还包括新的基于 MSVC 的 Rust 后端。评论者将这视为对 Rust 成熟度的认可，以及减少长期存在的内存安全漏洞的一种方式，同时也在讨论 Visual Studio 支持、C/C++ 互操作、编译时间，以及它在 Web 后端、嵌入式和 GPU 代码等领域的适用性等实际问题。也有人对微软的采用能否转化为更轻量、更高质量的应用持怀疑态度，认为组织激励和臃肿框架比语言选择更重要。

“Tier‑1”的定义与含义

  • 在微软，“Tier‑1”指的是一种得到完全支持的内部语言，从开发到生产都有一条“铺好的路径”：安全的工具链、工作流、平台集成以及 SDL 合规。
  • Rust 与 C++、C# 和 TypeScript 一起加入 Tier‑1；Java 和 Python 明确不在这组里。
  • 有些人认为这证明了 Rust 的成熟；也有人指出这只是“内部 Tier‑1”，并不自动意味着它已经在公共工具中可见。

工具、IDE 与调试

  • 很多人问为什么 Visual Studio 还没有一流的 Rust 支持；也有人指出 VS Code 其实已经有了，微软可能正在优先投入那里。
  • 一些人预测，新的语言投资会逐步从完整的 Visual Studio 转向 VS Code。
  • 目前通过 VS 的调试支持已经在用一些变通办法（natvis、自定义工具）实现，但容器/枚举可视化仍然比较粗糙。
  • 还提到了 RustRover 等替代 IDE，对它们的界面评价褒贬不一。

MSVC 后端 / rustc_codegen_utc

  • 一个重要的技术消息是：Rust 现在有了 MSVC 代码生成后端（rustc_codegen_utc），在 Windows 上绕过了 LLVM。
  • 据称内部基准测试显示其性能与 LLVM 持平。
  • 外部可用性也在计划中，但细节（许可、开放程度）仍不清楚。

C/C++ 互操作与部分重写

  • 大型 C++ 团队希望逐步引入 Rust，而不是一次性全部重写。
  • 文中提到了若干用于 C++↔Rust 互操作的工具/项目（例如 Crubit、类似 cbindgen 的工具），但由于类型系统差异，“无缝”互操作被认为在根本上受限。
  • 预计跨越边界仍然会是 unsafe，有时使用包装层，甚至进程内 RPC 也可能更合适。

Rust 的用途、优势与局限

  • 被称赞的领域包括：系统代码、嵌入式、高性能后端、科学计算、GPU 主机代码，以及一些 GUI/桌面应用。
  • 对 Web 后端存在争论：一些团队表示，从 TypeScript/Go 迁移到 Rust 带来了巨大收益；另一些人仍然更偏好 Go/Java，因为它们更易用、交付更快。
  • Rust 被认为在快速原型、脚本编写，以及需要超快迭代和大量 unsafe/引擎集成的游戏开发工作流中相对较弱。

性能、内存与微软应用膨胀

  • 一些评论者希望 Rust 能减少 Windows 的臃肿问题（例如 1GB+ 的天气应用、缓慢的计算器），但很多人认为语言选择只是次要因素，企业激励、框架（WebView2）以及遥测/广告堆栈才是关键。
  • 也有人对 Rust 在微软是否会明显提升面向消费者的软件质量持怀疑态度。

稳定性、生态与 AI 生成的 Rust

  • 有人表示旧的 Rust 项目重新编译也没问题；但也有人在使用发行版编译器时频繁遇到“需要更新的 rustc”的问题，把原因归咎于对新特性的激进使用。
  • edition 和 MSRV 策略被认为是稳定因素，但向前兼容方面的痛点仍然存在。
  • 人们认为 LLM 生成可编译 Rust 的能力异常强，因为编译器和 Clippy 提供了很强的反馈回路；但也有人担心初学者/代理会滥用 .clone()、Arc<RwLock<_>> 或 unsafe，从而写出低效但内存安全的“氛围编码” Rust。