Microsoft procura desenvolvedores Rust para reescrever código central em C#

Artigo original ↗ Discussão no Hacker News ↗

O anúncio de vagas da Microsoft para desenvolvedores Rust trabalhando em serviços centrais do Office 365 gerou debate sobre se isso indica uma mudança para longe de C# e .NET. A maioria dos comentaristas conclui que não: a Microsoft continuará usando C# extensivamente, enquanto adota Rust de forma seletiva para componentes ultra-sensíveis a desempenho e críticos em segurança, onde pausas de GC e uso de recursos em hyperscale se tornam caros. A discussão se amplia para uma comparação entre Rust e linguagens com garbage collector, abordando segurança de memória, concorrência, ferramentas e as dificuldades práticas de contratar ou treinar equipes para Rust.

Âmbito da adoção de Rust pela Microsoft

  • A discussão gira em torno de uma única vaga para serviços de roteamento/núcleo do Office 365, e não de uma reescrita completa do .NET nem de abandonar C#.
  • Vários comentários enfatizam que a Microsoft usa muitas linguagens (C#, C++, Rust, JS/TS, Go, Python, Java, etc.) e continua investindo fortemente em .NET.
  • Rust é apresentado como substituto para componentes críticos de desempenho ou de baixo nível que antes talvez fossem escritos em C/C++, e não para lógica de negócios típica.

Desempenho, GC e custo em escala

  • Muitos argumentam que o principal motor é o desempenho: em escala de nuvem, até ganhos modestos de CPU/memória podem se traduzir em grandes economias de custo.
  • Pausas de GC e ajustes finos são pontos de dor recorrentes para serviços de alto throughput/baixa latência em linguagens com GC (C#, Java, etc.), especialmente ao buscar “mais 9s” de latência ou minimizar gasto de recursos.
  • Alguns observam que o .NET melhorou muito e pode ser “rápido o suficiente” para muitos serviços internos grandes, mas “rápido o suficiente” se torna relativo na escala do O365.

Segurança, ownership e lifetimes

  • Vários comentários destacam o sistema de ownership/lifetime do Rust como trazendo benefícios além da segurança de memória:
    • Limpeza determinística de recursos (RAII) para arquivos, sockets, mutexes, diretórios temporários, etc.
    • Ownership claro e não compartilhado reduzindo bugs sutis e data races.
  • Contrapontos:
    • C# já é seguro em relação à memória, com IDisposable e using para limpeza determinística, mas isso é opcional e fácil de usar incorretamente ou esquecer.
    • O borrow checker do Rust é descrito como análise estática poderosa, mas não mágica; alguns esclarecem equívocos sobre o que ele faz em tempo de execução.

Async, paralelismo e runtimes

  • Debate sobre se ARM e workloads modernos aumentam o valor de runtimes com GC em comparação com código nativo.
  • O async/await do .NET, o ThreadPool e os escalonadores work-stealing são defendidos como maduros e escaláveis.
  • Outro tópico contrasta a concorrência e tolerância a falhas do BEAM/Erlang com .NET/JVM; não há consenso, mas o BEAM é elogiado por concorrência massiva “de verdade”.

Ecossistema Rust, ferramentas e vagas

  • As ferramentas e o ecossistema do Rust (cargo, crates) são amplamente elogiados.
  • Há reclamações de que no Windows são necessárias toolchains MSVC grandes e, às vezes, privilégios de administrador; GCC/MinGW é uma alternativa mais leve, porém “instável”.
  • O mercado de trabalho em Rust é visto como menor e enviesado para blockchain e infra/segurança; contratar desenvolvedores Rust experientes é difícil.
  • Alguns aconselham introduzir Rust incrementalmente em stacks existentes; outros alertam para fragmentação do stack e complexidade de build.

Sentimento geral

  • Há amplo consenso de que:
    • C#/.NET e Rust vão coexistir.
    • Rust é uma boa opção para componentes selecionados e ultra-críticos.
    • Reescritas precisam ser justificadas por ganhos concretos de desempenho, segurança ou operação, e não apenas por hype.