2

Não acho que AOT resolve um problema real.

O problema de .NET é portabilidade. Se você quer distribuir um binário feito em Go, ele pesará ~2mb no mínimo, não preciso de nenhum runtime na máquina destino. Distribuir um binário em bun? Pouco mais de 7mb, nenhum runtime no destino, nem mesmo o próprio bun.

Mas .NET decidiu não ser assim.

Quer distribuir algo feito em .NET? Você tem as opções:

  • Exija que seu usuário tenha o .NET correto instalado; ou
  • Empacote seu app com o tal do single file + self-contained, espere um binário de +80mb para um simples hello world. Nota: você pode diminuir um pouco se habilitar o Ready to Run.
  • Adapte toda sua codebase, remova pacotes críticos, esqueça JSON dinâmico, resolva centenas de warnings, e ative o Native AOT para conseguir por seu app dentro de 20mb. E torça para ele funcionar.

Ah, você não pode fazer cross-compilation com Native AOT. Quer compilar para Mac e está no Windows? Esquece.

.NET ainda é péssimo para portabilidade.

AOT não serve para 95% dos projetos feitos com .NET.

Não tem uso real.

Carregando publicação patrocinada...
1

Eu sempre adorei C#. Nunca fui fã do .NET Framework. Adorei o .NET Core, ainda mais com a promessa do AOT. Mas aí confirmei o que me parecia complicado. Muita coisa da BCL e outras partes já eram grandes demais. A filosofia geral não era de economia e não daria para melhorar muito sem quebrar compatibilidade. Lembremos que ainda foi criado na época que a Microsoft fazia só para Windows e confiava que o gardware iria evoluir e podiam fazer sem pensar em economia. Claro que está ficando perto do ideal, tem gente competente trabalhando nisso, só não estão fazendo o que não tem jeito.

Conversei pessoalmente com o Anders, o Mads, e vários outros (infelizmente não consegui falar co o Eric Lippert), disse o quanto eu gosto da criação deles e quanto eu adoraria que tivesse a chamce, quase zxero, convenhamos, de começar de novo com o sucessor do C# poder ser feito sem compromisso de compatibilidade pensando no que sabemos que é a computação real hoje, como são os concorrentes que vieram depois, considerando a linguagem M# que eles criaram, mas nunca viu a luz do dia, e que era sensacional, que tivesse um pouco mais a pegada de F# de um lado e mais um puco de Rust, Go, Carbon, de outro, sem exageros. Além disso fazer um framework que pudesse ser usado de forma muito mais leve, e sem as gambiarras que foram feitas porque tinha prazo para lançar e a linguagem não estava completa para atender a todos os cenários (melhoraram o que dava, mas tem coisas bem ruins que não tem co que fazer).

Eu adoro Go de um jeito e odeio de outro, mas o ambiente é muito bom. Não é tão perfeito quanto alguns acham, mas é o caminho certo, especialmente se fizer o melhor algumas questões.

Algumas falhas ainda existentes no .NET são resolvíveis, mas tem muitas que realmente vamos ficar reféns para sempre, sem um novo start, que não ocorrerá. Curiosamente se algum gigante resolver, ele poderia fazer o que a Microsoft não tem coragem de fazer. Não rolará de novo com a Google, e tenho críticas a tudo que ela faz, mas foi ela que teve a coragem de investir em Go, Dart, com todas as críticas que faço a ela e agora Carbon, fora abraçar Kotlin. E se não abraçacem Kotlin eu acho que eles fariam uma linguagem enterprise que completaria o portfolio deles, algo que a Microsoft deveria ter completo.

Dito tudo isso, não acho que a portabilidade é tão problema assim, ainda que esteja longe do ideal. O tamanho é, mas não acho um problema na maioria dos cenários. Convenhamos, para fazer o deploy da maioria das aplicações, tanto faz se o tamanho é 8 ou 80MB, virtualmente não muda nada importante.

Confordo parcialmente com

AOT não serve para 95% dos projetos feitos com .NET.

o que é uma pena, mas não com:

Não tem uso real.

até porque contradiz a afirmação anterior.

De qualquer forma ao mesmo yem que um número por volta dos 95% seja factível, também podemos dizer que cerca de uns 95% dos projetos podem se benecificar do AOT. Ou seja, para a maioria dos projetos, tanto faz o que você usa, terá benefícios e malefícios, e como a maioria não tem grandes restrições técnicas, vai no mais fácil, deixe para quem precisa e/ou gosta de mais eficiência usar o AOT.

Mas como sempre, engenheiros analisam tudo e fazem, a melhor escolha possível, considerando todos os aspectos, até mesmo não técnicos.