.NET 8 Autônomo 50% Menor no Linux

Artigo original ↗ Discussão no Hacker News ↗

.NET 8 agora gera binários autônomos native AOT muito menores no Linux, reacendendo o interesse em C# para workloads serverless, contêineres e ferramentas CLI multiplataforma. Os comentaristas destacam trade-offs em torno de reflection e source generators para compatibilidade com AOT, comparam a concorrência, o desempenho e o uso de memória do .NET com Go e Java, e compartilham ampla experiência em produção rodando .NET no Linux em ambientes em nuvem e on-premises. O entusiasmo é temperado por problemas persistentes como bibliotecas oficiais fragmentadas ou “inacabadas”, fraco suporte nativo a GUI no Linux e preocupações com a gestão de longo prazo da Microsoft, apesar do forte progresso técnico.

AOT Nativo, Tamanho e Desempenho

  • A discussão gira em torno de binários autônomos com native AOT do .NET 8, com cerca de 2 MB para “hello world” e ~50% menores no Linux do que antes.
  • Ficou esclarecido que isso se aplica ao native AOT; aplicativos .NET típicos ainda usam JIT, embora o trimming tenha melhorado.
  • AOT é valorizado בעיקרamente por inicialização mais rápida e imagens pequenas em cenários de serverless/contêineres (por exemplo, AWS Lambda, Azure Functions).

Reflection, Source Generators e Restrições do AOT

  • O AOT é restringido por uso intenso de reflection e geração de código em tempo de execução; isso exige abordagens alternativas.
  • Alguns esperam que o uso de reflection diminua com o tempo por meio de source generators e interceptors; outros argumentam que reflection é conveniente demais e generators são trabalhosos demais, então ambos coexistirão.

Adesão e Experiências com .NET no Linux

  • Muitos relatam usar .NET no Linux rotineiramente: Kubernetes, Docker, AWS Lambda, Azure App Service (Linux), VMs na nuvem, servidores autogerenciados e apps de homelab (por exemplo, Jellyfin, apps *arr, cliente Ethereum).
  • Várias equipes usam Linux em produção enquanto os desenvolvedores rodam Windows/macOS; outras desenvolvem inteiramente em macOS/Linux com Rider, VS Code ou Neovim.
  • Para muitas web APIs e apps de funções, Linux agora é o alvo padrão de implantação; a economia de licença em relação ao Windows é um motivo importante.
  • A migração do .NET Framework continua sendo um ponto problemático para alguns, levando algumas organizações a mudar para Java em vez disso.

Ferramentas e Ecossistema

  • Grande elogio à produtividade, desempenho e ferramentas de C#/.NET (especialmente o Rider; o VS é visto como mais pesado e às vezes frágil, embora alguns digam que melhorou).
  • As opiniões se dividem sobre bibliotecas “oficiais” da Microsoft: Entity Framework Core é frequentemente elogiado, OData é amplamente criticado; muitos recomendam ferramentas OSS mais leves (Dapper, Postgres, Redis) em vez das stacks da Microsoft.
  • Alguns reclamam que a Microsoft tende a “competir com” em vez de adotar OSS da comunidade, prejudicando o ecossistema.

Comparações de Linguagens (Go, Java, F#, etc.)

  • Debate sobre Go vs C#:
    • Pró-Go: mais simples, concorrência de primeira classe sem “coloração” de async, bom para infraestrutura em nuvem.
    • Pró-C#: sistema de tipos mais rico, async/await poderoso, tasks, channels, frequentemente melhor throughput; alguns afirmam que o GC e a concorrência do Go não são superiores.
  • Há discordância sobre se os exemplos de concorrência em C# mostrados são realmente “concorrência” ou “paralelismo”.

GUI e Suporte no Linux

  • Grande frustração: não há suporte oficial a GUI no Linux no MAUI, apesar do forte impulso multiplataforma.
  • Alguns argumentam que Avalonia/Uno são bons o suficiente; outros veem a falta de GUI nativa de primeira parte para Linux como um sinal preocupante sobre o compromisso da Microsoft com Linux para apps de desktop.

Notas Técnicas Diversas

  • TimeProvider e FakeTimeProvider foram bem recebidos pela testabilidade; foi expressa a इच्छा de um FileSystemProvider.
  • Linkagem estática com Native AOT agora é possível, incluindo a ligação de bibliotecas .NET em projetos nativos.
  • Azure Functions em Kubernetes com KEDA foi citado como alternativa serverless “faça você mesmo”.