Building a bare-metal bootable game for Raspberry Pi in C#

A bare‑metal-style game for Raspberry Pi written in C# using UEFI and NativeAOT prompts debate over how “bare metal” it really is and whether targeting firmware instead of an OS is practical or just a fun hack. Commenters use it as a jumping-off point to examine .NET’s evolution — from manual memory control and GC tuning to NativeAOT, WASM, and cross‑platform tooling like Rider and VS Code — and how close C# is to being viable in embedded and microcontroller contexts. Many see strong potential in performance-focused C# and NativeAOT, but note that ecosystems, tooling quality, and long‑term platform stability matter as much as raw language capabilities.

Memory management and GC in C#

  • Some want C# to support fully manual allocation/deallocation of managed objects to avoid GC, e.g., via refcounted smart pointers or compiler flags.
  • Others argue this adds heavy correctness burdens, with little real-world performance gain compared to the current GC.
  • Existing tools: unsafe pointers, structs, Span/Memory, where T : unmanaged, GC control APIs (suppress/resume, no-GC regions), and interop allocation APIs.
  • There’s interest in a “no-op GC” mode similar to Java’s Epsilon GC, but concerns that typical allocation patterns would quickly exhaust memory.
  • Alternative compile-time or hybrid models (e.g., Mojo-style, research like Perceus) are mentioned as promising but constrained by language semantics and usability.

“Bare metal” vs UEFI and Raspberry Pi

  • Some call this not truly “bare metal” because it runs as a UEFI application and uses UEFI graphics APIs rather than driving the hardware directly.
  • Others counter that UEFI is already very low-level and practical for hobby OS/game-like work.
  • Discussion touches on even more “bare” approaches: direct VideoCore programming, GPIO-generated video, or microcontroller-style techniques.
  • Thread notes that Raspberry Pi can be used with UEFI and that the repo does mention Pi, though the article text barely addresses it, which confused some readers.

.NET ecosystem, tooling, and cross‑platform story

  • Several comments are impressed by modern .NET: cross-platform, IoT, games, WASM, and mobile support.
  • Tooling debate:
    • Visual Studio praised for capability but criticized for slowness and Windows-only focus.
    • Rider and VS Code are seen as strong, cross-platform alternatives; some say they’re displacing Visual Studio for many workloads.
  • Multi-platform UI and WASM:
    • Some see .NET’s WASM/Android/iOS targeting (Blazor, MAUI) as weaker or unstable compared with Kotlin multiplatform and Compose.
    • Others push back, citing production use of .NET WASM, multiple cross-platform UI frameworks (Avalonia, Uno), and argue that Kotlin’s non-Android story has its own issues.
    • There’s disagreement over whether .NET is “showmanship” versus a pragmatic, broadly capable stack.

NativeAOT, performance, and comparison to Go

  • NativeAOT is viewed as promising; missing robust EF Core support is a common pain point.
  • Dapper AOT is cited as one response to AOT needs (e.g., for serverless).
  • Some say C# could rival Go once AOT is mature, though compilation speed is currently not in Go’s league.

Embedded and microcontroller development

  • One perspective: MCU dev tooling, libraries, and portability are “garbage,” and higher-level ecosystems (C#, Python, JS) could push better practices.
  • Another replies that quality varies as in any domain, that serious MCU tooling is fine, and that language choice matters (C++, Rust, etc. already used).
  • There’s curiosity—but also skepticism—about C# on very small microcontrollers; many see it as technically interesting but not obviously practical.

General reactions

  • Many express enthusiasm for “cursed” ideas like native C# binaries and bare-metal-ish games, seeing them as fun experiments.
  • Others are more interested in deeper bare-metal work (custom bootloaders, direct hardware access) than in UEFI-based hacks.