Construindo um jogo bootável bare-metal para Raspberry Pi em C#

Artigo original ↗ Discussão no Hacker News ↗

Um jogo em estilo bare-metal para Raspberry Pi escrito em C# usando UEFI e NativeAOT gera debate sobre o quanto isso é realmente “bare metal” e se apontar para firmware em vez de um SO é prático ou apenas um truque divertido. Os comentaristas usam isso como ponto de partida para examinar a evolução do .NET — do controle manual de memória e ajuste do GC ao NativeAOT, WASM e ferramentas multiplataforma como Rider e VS Code — e o quão perto o C# está de ser viável em contextos embarcados e de microcontroladores. Muitos veem forte potencial em C# voltado a desempenho e no NativeAOT, mas observam que ecossistemas, qualidade das ferramentas e estabilidade de plataforma a longo prazo importam tanto quanto as capacidades brutas da linguagem.

Gerenciamento de memória e GC em C#

  • Alguns querem que C# suporte alocação/desalocação totalmente manual de objetos gerenciados para evitar o GC, por exemplo, via ponteiros inteligentes com contagem de referências ou flags do compilador.
  • Outros argumentam que isso adiciona grandes encargos de correção, com pouco ganho de desempenho no mundo real em comparação com o GC الحالي.
  • Ferramentas existentes: ponteiros unsafe, structs, Span/Memory, where T : unmanaged, APIs de controle do GC (suspender/retomar, regiões sem GC) e APIs de alocação para interoperabilidade.
  • Há interesse em um modo de GC “sem operação” semelhante ao Epsilon GC do Java, mas existem preocupações de que padrões típicos de alocação esgotariam a memória rapidamente.
  • Modelos alternativos em tempo de compilação ou híbridos (por exemplo, estilo Mojo, pesquisas como Perceus) são mencionados como promissores, mas limitados pela semântica da linguagem e pela usabilidade.

“Bare metal” vs UEFI e Raspberry Pi

  • Alguns dizem que isso não é realmente “bare metal” porque roda como uma aplicação UEFI e usa APIs gráficas da UEFI em vez de controlar o hardware diretamente.
  • Outros respondem que a UEFI já é muito de baixo nível e prática para trabalho hobbyista de SO/jogos.
  • A discussão toca em abordagens ainda mais “bare”: programação direta do VideoCore, vídeo gerado por GPIO ou técnicas estilo microcontrolador.
  • A thread observa que o Raspberry Pi pode ser usado com UEFI e que o repositório realmente menciona Pi, embora o texto do artigo mal o trate, o que confundiu alguns leitores.

Ecossistema .NET, ferramentas e história multiplataforma

  • Vários comentários se impressionam com o .NET moderno: suporte multiplataforma, IoT, jogos, WASM e mobile.
  • Debate sobre ferramentas:
    • Visual Studio é elogiado pela capacidade, mas criticado pela lentidão e pelo foco apenas no Windows.
    • Rider e VS Code são vistos como alternativas fortes e multiplataforma; alguns dizem que estão substituindo o Visual Studio em muitos cenários.
  • UI multiplataforma e WASM:
    • Alguns veem o suporte do .NET a WASM/Android/iOS (Blazor, MAUI) como mais fraco ou instável do que Kotlin multiplatform e Compose.
    • Outros rebatem, citando uso em produção de .NET WASM, múltiplos frameworks de UI multiplataforma (Avalonia, Uno) e argumentam que a história “não Android” do Kotlin também tem seus problemas.
    • Há desacordo sobre se o .NET é “espetáculo” ou uma stack pragmática e amplamente capaz.

NativeAOT, desempenho e comparação com Go

  • O NativeAOT é visto como promissor; a falta de suporte robusto ao EF Core é um ponto de dor comum.
  • Dapper AOT é citado como uma resposta às necessidades de AOT (por exemplo, para serverless).
  • Alguns dizem que C# poderia rivalizar com Go quando o AOT amadurecer, embora a velocidade de compilação ainda não esteja no mesmo nível de Go.

Desenvolvimento embarcado e de microcontroladores

  • Uma perspectiva: as ferramentas, bibliotecas e a portabilidade para MCU são “lixo”, e ecossistemas de nível mais alto (C#, Python, JS) poderiam incentivar práticas melhores.
  • Outra resposta diz que a qualidade varia como em qualquer domínio, que ferramentas sérias de MCU são boas, e que a escolha da linguagem importa (C++, Rust etc. já são usados).
  • Há curiosidade — mas também ceticismo — sobre C# em microcontroladores muito pequenos; muitos veem isso como tecnicamente interessante, mas não obviamente prático.

Reações gerais

  • Muitos expressam entusiasmo por ideias “amaldiçoadas” como binários nativos em C# e jogos meio bare-metal, vendo isso como experimentos divertidos.
  • Outros estão mais interessados em trabalho bare-metal mais profundo (bootloaders personalizados, acesso direto ao hardware) do que em truques baseados em UEFI.