Can Go Run Without an OS? Exploring the New Bare‑Metal Support Proposal

New Proposal: Add Bare Metal Support

Proposal Background

The proposal “proposal: all: add bare metal support” was submitted by Andrea Barisani.

The core idea is to introduce a new GOOS target value, such as GOOS=none (or the existing GOOS=tamago ), which allows Go applications to run in environments without an underlying operating system – the so‑called “bare‑metal” mode.

This enables:

Running Go programs without Linux, Windows, macOS, etc.

Defining a set of hardware‑related functions so that the Go runtime and external drivers (also written in Go) can cooperate.

Operating without OS syscalls, directly between the runtime and the hardware.

TamaGo Project Outcomes

The open‑source project TamaGo has already been developing for this need for several years.

Current achievements include:

Good compatibility with the Go standard library , passing most distribution tests.

Comprehensive cross‑platform support : amd64, arm, riscv64.

Network stack extensible via injected SocketFunc , allowing custom virtual networks and even use in js/wasip1.

Support for user‑mode execution (running as a Go app in a sandbox).

Extension beyond ARM to microVMs such as Firecracker and Cloud Hypervisor.

Changes to the official Go release are almost non‑invasive, keeping hardware drivers and the build system external.

Potential Issues

Community feedback, including from Google Go team member Michael Pratt, highlights two main compatibility challenges:

Providing a stable API for the runtime.

Defining a language subset suitable for implementing the runtime API.

Issue 1: Stable Runtime API

The Go 1 Compatibility Promise requires long‑term stability of any runtime‑dependent API.

The tamago runtime API defined in the proposal is roughly feasible, but the go:linkname mechanism needs a better replacement.

Some community members also want the API to work on minimal WASM runtimes (e.g., GOOS=none GOARCH=wasm).

Issue 2: Language Subset for Runtime API

The Go runtime itself uses a partially defined Go subset with special characteristics.

Small changes in the standard compiler (e.g., an extra memory allocation) can cause errors in non‑allocatable locations, though the runtime source can be adjusted together.

Once GOOS=none is enabled, any changes to the runtime must not break existing bare‑metal implementations, possibly requiring a defined “stable, safe” Go subset for these low‑level APIs.

This represents a substantial amount of work.

Significance and Value for Go

Make Go a bare‑metal development language : no need for C or assembly, full Go development experience.

Build minimal systems : trusted execution environments, bootloaders such as go‑boot.

Sandbox and virtualization innovation : enable soft‑isolation VMs and serverless runtimes.

Enhance Go runtime pluggability : improve multi‑platform abstraction capabilities.

Conclusion

If Go gains bare‑metal support, its advantages and opportunities in new domains will increase, but two critical engineering challenges remain before merging into the master branch: establishing a long‑term stable runtime API and ensuring those interfaces remain functional despite future changes to the Go language or compiler.

References

proposal: all: add bare metal support: https://github.com/golang/go/issues/73608

TamaGo: https://github.com/usbarmory/tamago