Rust is tier-1 language at Microsoft

Original Article ↗ Hacker News Discussion ↗

Microsoft’s decision to designate Rust as a “tier‑1” internal language—alongside C++, C# and TypeScript—signals a major bet on memory‑safe systems programming and deeper integration into its toolchain, including a new MSVC-based Rust backend. Commenters see this as validation of Rust’s maturity and a way to reduce long‑standing memory‑safety vulnerabilities, while debating practical issues like Visual Studio support, C/C++ interoperability, compile times, and suitability for domains from web backends to embedded and GPU code. Some remain skeptical that Microsoft’s adoption will translate into leaner, higher‑quality apps, arguing that organizational incentives and bloated frameworks matter more than language choice.

Definition and implications of “Tier‑1”

  • “Tier‑1” at Microsoft means a fully supported internal language with a “paved path” from dev to production: secure toolchains, workflows, platform integration, and SDL compliance.
  • Rust joins C++, C#, and TypeScript as Tier‑1; Java and Python are explicitly not in that group.
  • Some see this as proof of Rust’s maturity; others note it’s “internal Tier‑1” and not automatically visible in public tooling yet.

Tooling, IDEs, and debugging

  • Many ask why Visual Studio doesn’t have first‑class Rust yet; others point out VS Code already does, and MS may be prioritizing that.
  • Some predict a gradual shift from full Visual Studio to VS Code for new language investment.
  • Debugging support via VS has been used today with workarounds (natvis, custom tooling), but container/enum visualization is still rough.
  • Alternative IDEs like RustRover are mentioned, with mixed opinions on their UI.

MSVC backend / rustc_codegen_utc

  • Big technical news: Rust now has an MSVC codegen backend (rustc_codegen_utc), bypassing LLVM on Windows.
  • Internal benchmarks reportedly show performance on par with LLVM.
  • External availability is planned but details (licensing, openness) remain unclear.

C/C++ interoperability and partial rewrites

  • Large C++ shops want incremental Rust adoption, not full rewrites.
  • Several tools/projects for C++↔Rust interop are cited (e.g., Crubit, cbindgen‑style tools), but “seamless” interop is seen as fundamentally limited by type‑system differences.
  • Crossing the boundary is expected to remain unsafe, with wrapper layers or even in‑process RPC sometimes preferable.

Use cases, strengths, and limits of Rust

  • Praised domains: systems code, embedded, high‑performance backends, scientific computing, GPU host code, and some GUI/desktop apps.
  • Debate over web backends: some teams report large wins moving from TypeScript/Go to Rust; others still prefer Go/Java for ergonomics and speed of delivery.
  • Rust is considered weaker for rapid prototyping, scripting, and game dev workflows that need ultra‑fast iteration and heavy unsafe/engine integration.

Performance, memory, and Microsoft app bloat

  • Several commenters hope Rust reduces Windows bloat (e.g., 1+ GB Weather app, slow Calculator) but many argue language choice is secondary to corporate incentives, frameworks (WebView2), and telemetry/ad stacks.
  • Some are skeptical that Rust at Microsoft will visibly improve consumer‑facing software quality.

Stability, ecosystem, and AI‑generated Rust

  • Some report old Rust projects recompiling fine; others hit frequent “requires newer rustc” issues when using distro compilers, blaming aggressive use of new features.
  • Editions and MSRV policies are cited as stabilizing factors, but forward‑compatibility pain remains.
  • LLMs are seen as unusually good at generating compiling Rust because the compiler and Clippy provide strong feedback loops; concerns remain about beginners/agents abusing .clone(), Arc<RwLock<_>>, or unsafe, leading to inefficient but memory‑safe “vibe‑coded” Rust.