.NET 8 在 Linux 上独立运行时小 50%

原文 ↗ Hacker News 讨论 ↗

.NET 8 的原生 AOT 工具现在能在 Linux 上生成小得多的独立二进制文件，这重新激发了人们对 C# 在无服务器工作负载、容器和跨平台 CLI 工具中的兴趣。评论者强调了反射与源生成器在 AOT 兼容性上的权衡，并将 .NET 的并发、性能和内存使用与 Go 和 Java 进行比较，同时分享了在云端和本地环境中运行 .NET on Linux 的大量生产经验。尽管技术进展显著，热情仍受到一些长期痛点的制约，例如碎片化或“半成品”的官方库、Linux 上薄弱的第一方 GUI 支持，以及对微软长期维护态度的担忧。

Native AOT、体积与性能

  • 讨论的重点是 .NET 8 的原生 AOT 独立二进制文件，“hello world” 约为 2 MB，并且在 Linux 上比之前小约 50%。
  • 这里指的是原生 AOT；典型的 .NET 应用仍然使用 JIT，不过裁剪能力已经改进。
  • AOT 主要因更快的冷启动和在无服务器/容器场景中的小镜像而受到重视（例如 AWS Lambda、Azure Functions）。

反射、源生成器与 AOT 约束

  • AOT 受大量反射和运行时代码生成的限制；这些需要替代方案。
  • 有些人预计随着源生成器和拦截器的出现，反射的使用会逐渐减少；也有人认为反射太方便而生成器太笨重，因此两者会共存。

.NET 在 Linux 上的采用与使用体验

  • 许多人表示自己一直在 Linux 上常规运行 .NET：Kubernetes、Docker、AWS Lambda、Azure App Service（Linux）、云虚拟机、自托管服务器，以及家庭实验室应用（例如 Jellyfin、*arr 应用、Ethereum client）。
  • 一些团队在生产中使用 Linux，而开发者运行 Windows/macOS；另一些则完全在 macOS/Linux 上开发，使用 Rider、VS Code 或 Neovim。
  • 对于许多 Web API 和函数应用，Linux 现在是默认部署目标；相比 Windows 的许可证节省是主要原因。
  • 从 .NET Framework 迁移对一些人来说仍然是痛点，导致少数组织转而使用 Java。

工具与生态系统

  • 大家高度赞扬 C#/.NET 的生产力、性能和工具链（尤其是 Rider；VS 被认为更臃肿且有时脆弱，不过也有人表示它已经有所改进）。
  • 对微软“官方”库的评价分化：Entity Framework Core 常获好评，OData 则广受批评；许多人建议使用更轻量的开源工具（Dapper、Postgres、Redis），而不是微软技术栈。
  • 有些人抱怨微软往往倾向于“与社区竞争”而不是拥抱社区开源，这损害了生态系统。

语言比较（Go、Java、F# 等）

  • 关于 Go 与 C# 的争论：
    • 支持 Go：更简单，拥有一等公民的并发能力而无需 async “染色”，适合云基础设施。
    • 支持 C#：类型系统更丰富，async/await 更强大，任务、通道等更灵活；一些人认为 Go 的 GC 和并发并不更优。
  • 对于 C# 并发示例究竟是真正的“并发”还是“并行”，也存在分歧。

GUI 与 Linux 支持

  • 主要的挫败感：尽管微软大力推动跨平台，却没有在 MAUI 中提供官方 Linux GUI 支持。
  • 有些人认为 Avalonia/Uno 已经足够好；另一些人则认为缺少第一方 Linux GUI 是微软对桌面应用 Linux 承诺不足的危险信号。

其他技术备注

  • TimeProvider 和 FakeTimeProvider 因提升可测试性而受到欢迎；有人希望推出 FileSystemProvider。
  • 现在可以使用 Native AOT 进行静态链接，包括将 .NET 库链接到原生项目中。
  • 还提到了在 Kubernetes 上结合 KEDA 的 Azure Functions，作为一种自建无服务器替代方案。