.NET 11 Preview 1: o que realmente mudou e o que ainda é só ruído
Toda vez que sai uma preview nova do .NET, aparece gente anunciando revolução antes de terminar de ler a nota de lançamento inteira. Resolvi fazer o caminho mais chato: ler a nota oficial primeiro e só depois decidir o que realmente merece atenção.
Então o que mudou de fato no .NET 11 Preview 1?
Menos coisa do que o volume de posts sobre o assunto sugere. O .NET 11 Preview 1 trouxe uma mudança grande de runtime, duas novidades pequenas em C#, um ajuste na experiência do dotnet run e trabalho de base para rodar CoreCLR em WebAssembly. Nada disso é sobre IA, o que já é meio irônico dado o resto do mercado.
Runtime async é a mudança que realmente importa aqui
Hoje, async/await em C# é basicamente um truque de compilador: o compilador reescreve o método assíncrono numa state machine, e o runtime nem sabe que aquilo é “async” de verdade.
O runtime async muda isso. A ideia é o runtime entender código assíncrono como um conceito de primeira classe, em vez de depender só da reescrita feita pelo compilador. Na teoria, isso melhora performance em código com muito async e, principalmente, melhora a depuração: hoje, a call stack de um método assíncrono vira praticamente ilegível depois do primeiro await.
Se isso realmente resolver o problema de call stack, é a única parte desse preview que eu diria que vale acompanhar de perto.
Duas coisas pequenas em C# que valem nota
O C# 15 trouxe collection expression arguments. Até agora, a sintaxe curta de collection expression não deixava passar argumentos de construtor, tipo uma capacidade inicial ou um IEqualityComparer customizado. Isso passa a ser possível diretamente na sintaxe.
Também entrou suporte a extended layout, que permite ao compilador emitir TypeAttributes.ExtendedLayout para tipos marcados com ExtendedLayoutAttribute. É uma feature de interop bem de nicho. Não é algo que eu espero usar tão cedo, mas registro porque está lá.
O dotnet run ficou um pouco mais interativo
Em projeto multi-target, rodar dotnet run sem especificar --framework agora abre um seletor interativo (via Spectre.Console) para escolher o target framework com as setas. O mesmo mecanismo passa a valer para seleção de dispositivo em cenários mobile, quando o projeto expõe um target ComputeAvailableDevices.
É um ajuste de experiência, não de arquitetura. Mas é o tipo de coisa que economiza um --framework net10.0 digitado de memória todo dia.
E o resto: MAUI, WebAssembly, requisitos de hardware
O .NET MAUI passou a usar geração de XAML por source generator como padrão, e CoreCLR virou o runtime padrão para builds de Release no Android. Também começou o trabalho para migrar o suporte a WebAssembly do Mono para o CoreCLR, mas isso é trabalho de base, explicitamente não pronto para uso geral ainda.
O preview também trouxe requisitos mínimos de hardware atualizados para x86/x64 e Arm64, exigindo conjuntos de instrução mais modernos. Nada disso me afeta diretamente no que uso hoje, então só deixo registrado.
A recepção não foi só aplauso
Vale marcar que a reação de parte da comunidade não foi unanimemente positiva. Tem gente reclamando da sintaxe nova de C# ficar complexa demais, e tem gente cobrando mais foco em polimento do framework em vez de narrativa em torno de IA agêntica, mesmo que este preview específico seja, na prática, bem mais “código e runtime” do que “IA”.
Do lado positivo, tem gente com expectativa real em cima do runtime async, principalmente por causa da promessa de call stack utilizável em código assíncrono.
O que eu realmente vou acompanhar
Não instalei esse preview para rodar benchmark nem tirar conclusão própria sobre performance, seria cedo demais para isso e não é o que eu me propus a fazer aqui. O objetivo era só separar o que é mudança real do que é ruído em volta do anúncio.
Runtime async é a única peça desse preview que eu vou acompanhar com atenção daqui para frente. O resto é ajuste incremental, útil, mas não é a parte que decide se essa versão vai valer a migração quando sair estável.