Microsoft seeks Rust developers to rewrite core C# code

Original Article ↗ Hacker News Discussion ↗

Microsoft’s job ad for Rust developers to work on core Office 365 services has triggered debate over whether this signals a shift away from C# and .NET. Commenters largely conclude it does not: Microsoft will keep using C# extensively, while adopting Rust selectively for ultra‑performance‑sensitive and security‑critical components where GC pauses and resource usage at hyperscale become costly. The exchange broadens into a comparison of Rust and garbage-collected languages, touching on memory safety, concurrency, tooling, and the practical difficulties of hiring or retraining teams for Rust.

Scope of Microsoft’s Rust Adoption

  • Discussion centers on a single job posting for Office 365 routing/core services, not a wholesale rewrite of .NET or abandoning C#.
  • Multiple comments stress Microsoft uses many languages (C#, C++, Rust, JS/TS, Go, Python, Java, etc.) and is still heavily investing in .NET.
  • Rust is framed as a replacement for performance‑critical or low‑level components that might previously have been written in C/C++, not for typical business logic.

Performance, GC, and Cost at Scale

  • Many argue performance is the main driver: at cloud scale, even modest CPU/memory gains can translate into large cost savings.
  • GC pauses and tuning are recurring pain points for high‑throughput/low‑latency services in GC languages (C#, Java, etc.), especially when chasing “extra 9s” of latency or minimizing resource spend.
  • Some note .NET has improved greatly and can be “fast enough” for many large internal services, but “fast enough” becomes relative at O365 scale.

Safety, Ownership, and Lifetimes

  • Several comments highlight Rust’s ownership/lifetime system as providing benefits beyond memory safety:
    • Deterministic resource cleanup (RAII) for files, sockets, mutexes, temp dirs, etc.
    • Clear, non‑shared ownership reducing subtle bugs and data races.
  • Counterpoints:
    • C# is already memory‑safe, with IDisposable and using for deterministic cleanup, but these are opt‑in and easy to misuse or forget.
    • Rust’s borrow checker is described as powerful static analysis, but not magic; some clarify misconceptions about what it does at runtime.

Async, Parallelism, and Runtimes

  • Debate over whether ARM and modern workloads increase the value of GC’d runtimes vs native code.
  • .NET’s async/await, ThreadPool, and work‑stealing schedulers are defended as mature and scalable.
  • Separate thread contrasts BEAM/Erlang’s concurrency and fault‑tolerance with .NET/JVM; no consensus, but BEAM is praised for “true” massive concurrency.

Rust Ecosystem, Tooling, and Jobs

  • Rust tooling and ecosystem (cargo, crates) are widely praised.
  • Complaints about Windows requiring large MSVC toolchains and sometimes admin rights; GCC/MinGW is a lighter but “janky” alternative.
  • Rust job market is seen as smaller and skewed toward blockchain and infra/security; hiring experienced Rust devs is hard.
  • Some advise introducing Rust incrementally into existing stacks; others warn about tech‑stack fragmentation and build complexity.

Overall Sentiment

  • Broad agreement that:
    • C#/.NET and Rust will coexist.
    • Rust is a strong fit for select, ultra‑critical components.
    • Rewrites must be justified by concrete performance, security, or operational wins, not hype alone.