The use cases is not writing unsafe C in first place, and proving the point Go is usable in such scenarios, regardless of naysayers.

The creators of USB Armory also created TamaGo, instead of using Rust, exactly for the same reasons, to prove a point.

https://github.com/usbarmory/tamago

https://reversec.com/usb-armory/

Because in IT, seeing is believing.

There aren't that many UEFI shells and the ones that exist are certainly not modern. Anything new is helpful, especially if its written in a popular language like Go.

When you turn on a computer, it transfers code to software required to get the machine up and running reliably--the boot process. That used start in a chip called the BIOS. It's a 40-year old holdover from the early days of the IBM PC. UEFI is a more complex and feature-rich protocol. Due to its default memory management Go hasn't been considered the first choice for such purposes but this proof of concept uses Go for the very low level code needed for UEFI.

There’s some more context in a proposal from the folks behind this project to upstream the needed Go runtime hooks into Go proper.

From what I can tell, the core Go team seems generally favorable to it, so seems like a decent chance it will happen.

From:

#73608 proposal: all: add bare metal support

https://github.com/golang/go/issues/73608

> Go applications built with GOOS=none would run on bare metal, without any underlying OS. All required support is provided by the Go runtime and external driver packages, also written in Go.

And:

> These hooks act as a "Rosetta Stone" for integration of a freestanding Go runtime within an arbitrary environment, whether bare metal or OS supported.

That's the list of hardware they've explicitly tested on. Always bear in mind that, for any given standard, no matter how straightforward, there are going to be dozens of vendors who screw it up for no real reason other than incompetence or malice.

The older a piece of software is, the more workarounds it will have accrued for various hardware bugs or vendor misdeeds, so it's reasonable for the project to disclaim that it's only been tested on a small number of physical hardware devices even if, in theory, it should work out of the box on all of them.

Why? You can’t just leave that dangling like a meat stick.

If that makes you cringe, I cannot even begin to imagine what this https://tinygo.org will do to you.

Why? Xerox PARC used to do this.

As did all machines that booted into a Lisp or BASIC REPL.

I think what it means is:

1. It's an EFI application

2. It doesn't require any external runtimes, any setup, etc. (i.e. your UEFI system can boot straight into it without anything in between).

At least, that seems to be the case.