微软寻求 Rust 开发者重写核心 C# 代码

原文 ↗ Hacker News 讨论 ↗

微软为核心 Office 365 服务招聘 Rust 开发者的广告，引发了关于这是否意味着微软正从 C# 和 .NET 转向的讨论。评论者总体认为并非如此：微软会继续大量使用 C#，同时有选择地采用 Rust，用于那些对性能和安全性要求极高、在超大规模下 GC 停顿和资源使用会变得昂贵的组件。讨论进一步延伸到 Rust 与带垃圾回收语言的对比，涉及内存安全、并发、工具链，以及为 Rust 招聘或让团队转型的实际困难。

微软采用 Rust 的范围

  • 讨论集中在一则针对 Office 365 路由/核心服务的职位发布上，而不是对 .NET 的全面重写或放弃 C#。
  • 多条评论强调，微软使用许多语言（C#、C++、Rust、JS/TS、Go、Python、Java 等），并且仍在大力投资 .NET。
  • Rust 被视为以前可能会用 C/C++ 编写的、对性能关键或低层组件的替代，而不是用于典型的业务逻辑。

性能、GC 与规模化成本

  • 许多人认为性能是主要驱动力：在云规模下，即使 CPU/内存有小幅提升，也可能转化为巨大的成本节省。
  • 对于高吞吐/低延迟服务而言，GC 停顿和调优是使用带 GC 语言（C#、Java 等）时反复出现的痛点，尤其是在追求“额外的 9”级延迟或尽量降低资源开销时。
  • 有人指出 .NET 已经有了很大改进，对许多大型内部服务来说可以“足够快”，但在 O365 的规模下，“足够快”会变成相对概念。

安全性、所有权与生命周期

  • 若干评论强调 Rust 的所有权/生命周期系统不仅仅带来内存安全方面的好处：
    • 对文件、套接字、互斥锁、临时目录等进行确定性的资源清理（RAII）。
    • 清晰、非共享的所有权可减少微妙 bug 和数据竞争。
  • 反驳观点：
    • C# 本身已经是内存安全的，并且有 IDisposable 和 using 来进行确定性清理，但这些是可选的，且容易被误用或遗漏。
    • Rust 的借用检查器被描述为强大的静态分析，但并非魔法；一些人也澄清了关于它在运行时做什么的误解。

异步、并行与运行时

  • 关于 ARM 和现代工作负载是否会提高 GC 运行时相对于原生代码的价值，存在争论。
  • .NET 的 async/await、ThreadPool 以及 work-stealing 调度器被认为成熟且可扩展。
  • 另一个线程将 BEAM/Erlang 的并发与容错能力与 .NET/JVM 进行对比；没有形成一致结论，但 BEAM 因其“真正”的大规模并发能力而受到称赞。

Rust 生态、工具链与招聘

  • Rust 的工具链和生态（cargo、crates）普遍受到赞扬。
  • 有人抱怨 Windows 需要大型 MSVC 工具链，而且有时还需要管理员权限；GCC/MinGW 虽然更轻量，但被认为有些“别扭”。
  • Rust 的就业市场被认为更小，并且偏向区块链、基础设施/安全方向；招聘有经验的 Rust 开发者很难。
  • 有些人建议在现有技术栈中逐步引入 Rust；也有人警告技术栈碎片化和构建复杂度上升。

总体情绪

  • 普遍共识是：
    • C#/.NET 和 Rust 会并存。
    • Rust 很适合少数、超关键的组件。
    • 重写必须由明确的性能、安全性或运维收益来证明，而不是仅凭热度。