Construyendo un juego arrancable bare-metal para Raspberry Pi en C#

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

Un juego al estilo bare-metal para Raspberry Pi escrito en C# usando UEFI y NativeAOT provoca debate sobre cuán “bare metal” es realmente y si apuntar al firmware en lugar de a un SO es práctico o solo un truco divertido. Los comentaristas aprovechan para examinar la evolución de .NET —desde el control manual de memoria y el ajuste del GC hasta NativeAOT, WASM y herramientas multiplataforma como Rider y VS Code— y hasta qué punto C# puede ser viable en contextos embebidos y de microcontroladores. Muchos ven un gran potencial en C# orientado al rendimiento y en NativeAOT, pero señalan que los ecosistemas, la calidad de las herramientas y la estabilidad de la plataforma a largo plazo importan tanto como las capacidades brutas del lenguaje.

Gestión de memoria y GC en C#

  • Algunos quieren que C# admita la asignación/liberación completamente manual de objetos administrados para evitar el GC, por ejemplo, mediante punteros inteligentes con recuento de referencias o flags del compilador.
  • Otros sostienen que esto añade fuertes cargas de corrección, con poca ganancia real de rendimiento frente al GC actual.
  • Herramientas existentes: punteros unsafe, structs, Span/Memory, where T : unmanaged, API de control del GC (suspender/reanudar, regiones sin GC) y API de asignación para interoperabilidad.
  • Hay interés en un modo de GC “no-op” similar al GC Epsilon de Java, pero preocupaciones de que los patrones típicos de asignación agotarían la memoria rápidamente.
  • Se mencionan como prometedores modelos alternativos de compilación o híbridos (por ejemplo, de estilo Mojo, investigaciones como Perceus), aunque limitados por la semántica del lenguaje y la usabilidad.

“Bare metal” frente a UEFI y Raspberry Pi

  • Algunos dicen que esto no es realmente “bare metal” porque se ejecuta como una aplicación UEFI y usa APIs gráficas de UEFI en lugar de controlar el hardware directamente.
  • Otros responden que UEFI ya es muy de bajo nivel y práctico para trabajos aficionados de SO/juegos.
  • La discusión aborda enfoques aún más “bare”: programación directa de VideoCore, video generado por GPIO o técnicas al estilo microcontrolador.
  • El hilo señala que Raspberry Pi puede usarse con UEFI y que el repositorio sí menciona Pi, aunque el texto del artículo apenas lo aborda, lo que confundió a algunos lectores.

Ecosistema .NET, herramientas y panorama multiplataforma

  • Varios comentarios se muestran impresionados por el .NET moderno: multiplataforma, IoT, juegos, WASM y soporte móvil.
  • Debate sobre herramientas:
    • Visual Studio es elogiado por sus capacidades, pero criticado por su lentitud y su enfoque exclusivo en Windows.
    • Rider y VS Code se ven como alternativas sólidas y multiplataforma; algunos dicen que están desplazando a Visual Studio en muchas cargas de trabajo.
  • UI multiplataforma y WASM:
    • Algunos consideran que el targeting de .NET para WASM/Android/iOS (Blazor, MAUI) es más débil o inestable que Kotlin multiplatform y Compose.
    • Otros replican, citando uso en producción de .NET WASM, múltiples marcos de UI multiplataforma (Avalonia, Uno), y sostienen que la historia no-Android de Kotlin también tiene sus propios problemas.
    • Hay desacuerdo sobre si .NET es “puro espectáculo” o una pila pragmática y ampliamente capaz.

NativeAOT, rendimiento y comparación con Go

  • NativeAOT se ve como prometedor; la falta de un soporte robusto para EF Core es un punto de dolor frecuente.
  • Dapper AOT se cita como una respuesta a las necesidades de AOT (por ejemplo, para serverless).
  • Algunos dicen que C# podría rivalizar con Go una vez que AOT madure, aunque la velocidad de compilación todavía no está al nivel de Go.

Desarrollo embebido y de microcontroladores

  • Una perspectiva: las herramientas, bibliotecas y portabilidad para MCU son “basura”, y ecosistemas de más alto nivel (C#, Python, JS) podrían impulsar mejores prácticas.
  • Otra responde que la calidad varía como en cualquier dominio, que el tooling serio para MCU está bien y que la elección del lenguaje importa (C++, Rust, etc. ya se usan).
  • Hay curiosidad —pero también escepticismo— sobre C# en microcontroladores muy pequeños; muchos lo ven como técnicamente interesante pero no obviamente práctico.

Reacciones generales

  • Muchos expresan entusiasmo por ideas “malditas” como binarios nativos de C# y juegos tipo bare-metal, viéndolos como experimentos divertidos.
  • Otros están más interesados en un trabajo bare-metal más profundo (bootloaders personalizados, acceso directo al hardware) que en trucos basados en UEFI.