.NET 8 Standalone 50% Smaller On Linux

Original Article ↗ Hacker News Discussion ↗

.NET 8’s native AOT tooling now produces much smaller standalone binaries on Linux, prompting renewed interest in C# for serverless workloads, containers, and cross‑platform CLI tools. Commenters highlight trade-offs around reflection and source generators for AOT compatibility, compare .NET’s concurrency, performance, and memory use to Go and Java, and share extensive production experience running .NET on Linux in cloud and on-prem environments. Enthusiasm is tempered by ongoing pain points such as fragmented or “half-finished” official libraries, weak first‑party GUI support on Linux, and concerns about Microsoft’s long‑term stewardship despite strong technical progress.

Native AOT, Size & Performance

  • Discussion centers on .NET 8 native AOT standalone binaries being ~2 MB for “hello world” and ~50% smaller on Linux vs before.
  • Clarified this applies to native AOT; typical .NET apps still use JIT, though trimming has improved.
  • AOT mainly valued for faster cold starts and small images in serverless/container scenarios (e.g., AWS Lambda, Azure Functions).

Reflection, Source Generators & AOT Constraints

  • AOT is constrained by heavy reflection and runtime code generation; these need alternate approaches.
  • Some expect reflection use to shrink over time via source generators and interceptors; others argue reflection is too convenient and generators too cumbersome, so both will coexist.

.NET on Linux Adoption & Experiences

  • Many report running .NET on Linux routinely: Kubernetes, Docker, AWS Lambda, Azure App Service (Linux), cloud VMs, self-hosted servers, and homelab apps (e.g., Jellyfin, *arr apps, Ethereum client).
  • Several teams use Linux in production while devs run Windows/macOS; others develop entirely on macOS/Linux with Rider, VS Code, or Neovim.
  • For many web APIs and function apps, Linux is now the default deployment target; license savings vs Windows are a major reason.
  • Migration from .NET Framework remains a pain point for some, leading a few orgs to move to Java instead.

Tooling & Ecosystem

  • Strong praise for C#/.NET productivity, performance, and tooling (especially Rider; VS seen as heavier and sometimes fragile, though some say it has improved).
  • Opinions split on Microsoft “official” libraries: Entity Framework Core often praised, OData widely criticized; many recommend lighter OSS tools (Dapper, Postgres, Redis) over MS stacks.
  • Some complain MS tends to “compete with” instead of embracing community OSS, harming the ecosystem.

Language Comparisons (Go, Java, F#, etc.)

  • Debate over Go vs C#:
    • Pro-Go: simpler, first-class concurrency without async “coloring”, good for cloud infra.
    • Pro-C#: richer type system, powerful async/await, tasks, channels, often better throughput; some claim Go’s GC and concurrency are not superior.
  • Disagreement over whether C# concurrency examples shown are really “concurrency” vs “parallelism.”

GUI & Linux Support

  • Major frustration: no official Linux GUI support in MAUI, despite strong cross-platform push.
  • Some argue Avalonia/Uno are good enough; others see lack of first-party Linux GUI as a worrying signal about Microsoft’s commitment to Linux for desktop apps.

Misc Technical Notes

  • TimeProvider and FakeTimeProvider welcomed for testability; desire expressed for a FileSystemProvider.
  • Static linking with Native AOT now possible, including linking .NET libraries into native projects.
  • Azure Functions on Kubernetes with KEDA mentioned as DIY serverless alternative.