NET 8 Standalone un 50% más pequeño en Linux

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

Las herramientas nativas AOT de .NET 8 ahora producen binarios independientes mucho más pequeños en Linux, lo que reaviva el interés por C# para cargas de trabajo serverless, contenedores y herramientas CLI multiplataforma. Los comentaristas destacan las compensaciones entre reflexión y generadores de código fuente para la compatibilidad con AOT, comparan la concurrencia, el rendimiento y el uso de memoria de .NET con Go y Java, y comparten amplia experiencia de producción ejecutando .NET en Linux en entornos cloud y locales. El entusiasmo se ve atenuado por puntos problemáticos persistentes como bibliotecas oficiales fragmentadas o “a medio terminar”, el débil soporte de GUI de primera parte en Linux y las dudas sobre la gestión a largo plazo de Microsoft pese al fuerte progreso técnico.

Native AOT, tamaño y rendimiento

  • La discusión se centra en que los binarios independientes nativos AOT de .NET 8 son de ~2 MB para “hello world” y ~50% más pequeños en Linux que antes.
  • Se aclaró que esto aplica a native AOT; las aplicaciones .NET típicas siguen usando JIT, aunque el trimming ha mejorado.
  • AOT se valora sobre todo por arranques en frío más rápidos e imágenes pequeñas en escenarios de serverless/contenedores (p. ej., AWS Lambda, Azure Functions).

Reflexión, generadores de código fuente y restricciones de AOT

  • AOT está limitado por el uso intensivo de reflexión y la generación de código en tiempo de ejecución; esto requiere enfoques alternativos.
  • Algunos esperan que el uso de reflexión disminuya con el tiempo gracias a generadores de código fuente e interceptores; otros sostienen que la reflexión es demasiado cómoda y los generadores demasiado engorrosos, así que ambos coexistirán.

Adopción y experiencias de .NET en Linux

  • Muchos informan que ejecutan .NET en Linux de forma habitual: Kubernetes, Docker, AWS Lambda, Azure App Service (Linux), VMs en la nube, servidores autogestionados y apps de homelab (p. ej., Jellyfin, apps *arr, cliente Ethereum).
  • Varios equipos usan Linux en producción mientras los desarrolladores trabajan en Windows/macOS; otros desarrollan por completo en macOS/Linux con Rider, VS Code o Neovim.
  • Para muchas APIs web y aplicaciones function, Linux es ahora el destino de despliegue por defecto; el ahorro en licencias frente a Windows es una razón importante.
  • La migración desde .NET Framework sigue siendo un punto doloroso para algunos, lo que ha llevado a unas pocas organizaciones a pasarse a Java.

Herramientas y ecosistema

  • Gran elogio a la productividad, el rendimiento y las herramientas de C#/.NET, especialmente Rider; VS se ve como más pesado y a veces frágil, aunque algunos dicen que ha mejorado.
  • Las opiniones están divididas sobre las bibliotecas “oficiales” de Microsoft: Entity Framework Core suele recibir elogios, OData es ampliamente criticado; muchos recomiendan herramientas OSS más ligeras (Dapper, Postgres, Redis) en lugar de las pilas de MS.
  • Algunos se quejan de que MS tiende a “competir con” en lugar de abrazar el OSS comunitario, dañando el ecosistema.

Comparaciones de lenguajes (Go, Java, F#, etc.)

  • Debate sobre Go vs C#:
    • A favor de Go: más simple, concurrencia de primera clase sin “coloración” de async, bueno para infraestructura cloud.
    • A favor de C#: sistema de tipos más rico, async/await potente, tasks, channels, a menudo mejor throughput; algunos afirman que el GC y la concurrencia de Go no son superiores.
  • Desacuerdo sobre si los ejemplos de concurrencia en C# mostrados son realmente “concurrencia” o “paralelismo”.

GUI y soporte en Linux

  • Gran frustración: no hay soporte oficial de GUI en Linux en MAUI, pese a un fuerte impulso multiplataforma.
  • Algunos argumentan que Avalonia/Uno son suficientes; otros ven la ausencia de GUI Linux de primera parte como una señal preocupante sobre el compromiso de Microsoft con Linux para aplicaciones de escritorio.

Notas técnicas varias

  • TimeProvider y FakeTimeProvider fueron bien recibidos por su capacidad de prueba; se expresó el deseo de un FileSystemProvider.
  • Ahora es posible el enlazado estático con Native AOT, incluyendo enlazar bibliotecas .NET en proyectos nativos.
  • Se mencionó Azure Functions en Kubernetes con KEDA como alternativa serverless hecha a medida.