Microsoft busca desarrolladores de Rust para reescribir código central de C#

Artículo original ↗ Discusión en Hacker News ↗

El anuncio de Microsoft buscando desarrolladores de Rust para trabajar en servicios centrales de Office 365 ha desencadenado un debate sobre si esto señala un giro lejos de C# y .NET. La mayoría de los comentaristas concluye que no: Microsoft seguirá usando C# de forma extensiva, mientras adopta Rust selectivamente para componentes ultrasensibles al rendimiento y críticos para la seguridad, donde las pausas del GC y el uso de recursos a hiperescala se vuelven costosos. El intercambio se amplía a una comparación entre Rust y los lenguajes con recolección de basura, abordando la seguridad de memoria, la concurrencia, las herramientas y las dificultades prácticas de contratar o reentrenar equipos para Rust.

Alcance de la adopción de Rust por parte de Microsoft

  • La discusión se centra en una sola oferta de trabajo para servicios de enrutamiento/núcleo de Office 365, no en una reescritura generalizada de .NET ni en abandonar C#.
  • Varios comentarios subrayan que Microsoft usa muchos lenguajes (C#, C++, Rust, JS/TS, Go, Python, Java, etc.) y sigue invirtiendo fuertemente en .NET.
  • Rust se presenta como un sustituto para componentes de rendimiento crítico o de bajo nivel que antes podrían haberse escrito en C/C++, no para la lógica de negocio típica.

Rendimiento, GC y coste a escala

  • Muchos sostienen que el rendimiento es el principal motor: a escala de nube, incluso mejoras modestas de CPU/memoria pueden traducirse en grandes ahorros de costes.
  • Las pausas del GC y su ajuste son problemas recurrentes para servicios de alto rendimiento/baja latencia en lenguajes con GC (C#, Java, etc.), especialmente cuando se persiguen “unos nueves” extra de latencia o se minimiza el gasto de recursos.
  • Algunos señalan que .NET ha mejorado mucho y puede ser “lo bastante rápido” para muchos servicios internos grandes, pero “lo bastante rápido” se vuelve relativo a escala de O365.

Seguridad, ownership y lifetimes

  • Varios comentarios destacan que el sistema de ownership/lifetimes de Rust aporta beneficios más allá de la seguridad de memoria:
    • Limpieza determinista de recursos (RAII) para archivos, sockets, mutexes, directorios temporales, etc.
    • Ownership claro y no compartido que reduce errores sutiles y data races.
  • Contraargumentos:
    • C# ya es seguro en memoria, con IDisposable y using para limpieza determinista, pero son optativos y fáciles de usar mal u olvidar.
    • El borrow checker de Rust se describe como un potente análisis estático, pero no mágico; algunos aclaran ideas erróneas sobre lo que hace en tiempo de ejecución.

Async, paralelismo y runtimes

  • Debate sobre si ARM y las cargas de trabajo modernas aumentan el valor de los runtimes con GC frente al código nativo.
  • Se defiende que async/await de .NET, ThreadPool y los planificadores de work-stealing son maduros y escalables.
  • Otro hilo contrasta la concurrencia y la tolerancia a fallos de BEAM/Erlang con .NET/JVM; no hay consenso, pero BEAM recibe elogios por su concurrencia masiva “real”.

Ecosistema, herramientas y empleo de Rust

  • Las herramientas y el ecosistema de Rust (cargo, crates) son ampliamente elogiados.
  • Hay quejas sobre Windows, que requiere grandes toolchains de MSVC y a veces permisos de administrador; GCC/MinGW es una alternativa más ligera pero “chapucera”.
  • El mercado laboral de Rust se percibe como más pequeño y sesgado hacia blockchain e infraestructura/seguridad; contratar desarrolladores de Rust con experiencia es difícil.
  • Algunos aconsejan introducir Rust de forma incremental en stacks existentes; otros advierten sobre la fragmentación del stack tecnológico y la complejidad de compilación.

Sentimiento general

  • Hay amplio acuerdo en que:
    • C#/.NET y Rust coexistirán.
    • Rust encaja bien en componentes selectos y ultracríticos.
    • Las reescrituras deben justificarse con beneficios concretos de rendimiento, seguridad u operativos, no solo por la moda.