用 C# 为 Raspberry Pi 构建一个可裸机启动的游戏
一个用 C# 编写、面向 Raspberry Pi 的类裸机风格游戏，使用 UEFI 和 NativeAOT，引发了关于它到底有多“裸机”，以及把目标放在固件而不是操作系统上究竟是实用还是只是有趣的“整活”讨论。评论者借此切入 .NET 的演进——从手动内存控制和 GC 调优，到 NativeAOT、WASM 以及 Rider 和 VS Code 等跨平台工具——并讨论 C# 离在嵌入式和微控制器环境中变得可行还有多远。许多人认为性能导向的 C# 和 NativeAOT 很有潜力，但也指出生态、工具质量和长期平台稳定性与语言的原始能力同样重要。
C# 中的内存管理和 GC
- 有些人希望 C# 支持对托管对象进行完全手动的分配/释放，以避免 GC，例如通过引用计数智能指针或编译器标志。
- 也有人认为这会带来很重的正确性负担，而相较于当前的 GC，现实中的性能收益并不大。
- 现有工具包括：
unsafe指针、结构体、Span/Memory、where T : unmanaged、GC 控制 API（暂停/恢复、无 GC 区域），以及互操作分配 API。 - 线程里有人对类似 Java 的 Epsilon GC 那样的“无操作 GC”模式感兴趣，但也担心典型的分配模式会很快耗尽内存。
- 还提到了一些替代的编译期或混合模型（例如 Mojo 风格、Perceus 等研究）看起来很有前景，但会受到语言语义和易用性的限制。
“裸机”与 UEFI 以及 Raspberry Pi
- 有些人认为这并不是真正的“裸机”，因为它作为 UEFI 应用运行，并使用 UEFI 图形 API，而不是直接驱动硬件。
- 也有人反驳说，UEFI 本身已经是很低层且对业余 OS/类游戏项目很实用。
- 讨论还涉及更“裸”的方式：直接编程 VideoCore、用 GPIO 生成视频，或采用类似微控制器的技术。
- 线程里指出 Raspberry Pi 可以配合 UEFI 使用，而且仓库确实提到了 Pi，但文章正文几乎没有讨论它，这让一些读者感到困惑。
.NET 生态、工具链与跨平台叙事
- 不少评论对现代 .NET 印象深刻：跨平台、IoT、游戏、WASM 和移动端支持。
- 工具链争论：
- Visual Studio 因功能强大而受到称赞，但也因缓慢和偏向 Windows 而被批评。
- Rider 和 VS Code 被视为强大的跨平台替代方案；有人说它们正在许多工作场景中取代 Visual Studio。
- 多平台 UI 和 WASM：
- 有些人认为 .NET 的 WASM/Android/iOS 目标（Blazor、MAUI）不如 Kotlin Multiplatform 和 Compose 成熟或稳定。
- 也有人反驳，指出 .NET WASM 已经有生产使用案例，还有多个跨平台 UI 框架（Avalonia、Uno），并认为 Kotlin 在非 Android 场景下也有自己的问题。
- 对于 .NET 是“花架子”还是务实且能力全面的技术栈，意见并不一致。
NativeAOT、性能与 Go 的比较
- NativeAOT 被视为很有前景；缺乏强大的 EF Core 支持是一个常见痛点。
- Dapper AOT 被提为应对 AOT 需求的一种方案（例如用于无服务器场景）。
- 有人认为等 AOT 成熟后，C# 可以与 Go 竞争，不过当前编译速度还无法与 Go 相提并论。
嵌入式与微控制器开发
- 一种观点认为，MCU 开发工具、库和可移植性都“很糟糕”，更高层的生态（C#、Python、JS）可能会推动更好的实践。
- 另一种回应是，各领域质量本就参差不齐，严肃的 MCU 工具链其实并不差，而且语言选择很重要（C++、Rust 等早已在使用）。
- 大家对在很小的微控制器上运行 C# 既好奇又怀疑；许多人认为这在技术上很有趣，但显然不算实用。
总体反应
- 许多人对“离谱”的想法表现出热情，比如原生 C# 二进制和类裸机游戏，觉得这是很有趣的实验。
- 也有人更关注更深入的裸机工作（自定义引导加载程序、直接访问硬件），而不是基于 UEFI 的“技巧性”方案。