{} The Go Reference

Syscalls · Guide · Start here

Why Go for Systems Programming

Why Go excels at systems programming — static binaries, a tiny runtime, cross-compilation, and a toolchain that made it the language of infrastructure.

Syscalls Start here ⏱ 5 min read Complete

🛠️ Analogy

Most languages talk to the operating system through a thick interpreter or a heavy runtime — like ordering through a concierge who relays everything. Go is more like having your own key to the building: a small runtime, a single static binary, and direct access to system calls. You still get safety rails (a garbage collector, memory safety), but you’re close enough to the metal to write the daemons, CLIs, and agents that are the infrastructure.

What “systems programming” means here

Systems programming is software that talks to the operating system rather than to a user or a browser: command-line tools, daemons and agents, container runtimes, schedulers, log processors, network services. It’s about files, processes, signals, pipes, sockets, and memory — the primitives the OS exposes.

Go was built at Google explicitly for this layer, and it shows. This track lives at the boundary between your program and the kernel; this page is the why before the how.

The four things that make Go a systems language

graph TD
GO["Go program"] --> A["single static binary<br/>(no runtime to install)"]
GO --> B["cross-compiles anywhere<br/>(GOOS/GOARCH)"]
GO --> C["tiny runtime<br/>+ memory safety"]
GO --> D["goroutines<br/>(cheap concurrency)"]
A --> SHIP["copy & run on scratch/distroless"]
B --> SHIP
C --> SHIP
D --> SHIP
  • Static binaries. CGO_ENABLED=0 go build yields one self-contained executable. No interpreter, no shared libraries — scp it to a scratch container and it runs. Deployment is copy the file.
  • Cross-compilation. Set GOOS/GOARCH and build for any platform from any platform, no cross toolchain required. One CI job ships Linux, macOS, Windows, amd64 and arm64.
  • A tiny runtime with safety. You get a concurrent low-latency garbage collector and memory safety, but the runtime is small and you can talk to the kernel directly through syscall/x/sys.
  • Cheap concurrency. Goroutines make “one goroutine per connection / per file / per signal” affordable, so event-driven system software stays simple.

See it: who am I, where am I running?

A systems program almost always starts by asking the runtime about its environment. This runs anywhere — including the playground:

▶ env.go — editable & runnable
package main

import (
"fmt"
"os"
"runtime"
)

func main() {
fmt.Println("go version: ", runtime.Version())
fmt.Printf("target:      %s/%s\n", runtime.GOOS, runtime.GOARCH)
fmt.Println("CPUs:        ", runtime.NumCPU())
fmt.Println("PID:         ", os.Getpid())

// The environment is a key/value view of the process's world.
if home, ok := os.LookupEnv("HOME"); ok {
	fmt.Println("HOME:        ", home)
}
wd, _ := os.Getwd()
fmt.Println("working dir: ", wd)
}

runtime.GOOS/GOARCH are how portable code branches on platform; os is your portable window onto the process — its PID, environment, working directory, and standard streams.

Cross-compiling and shipping

The release story is the headline. None of this needs a special toolchain:

# Build for five targets from one machine, no cgo, fully static.
CGO_ENABLED=0 GOOS=linux   GOARCH=amd64 go build -o app-linux-amd64 .
CGO_ENABLED=0 GOOS=linux   GOARCH=arm64 go build -o app-linux-arm64 .
CGO_ENABLED=0 GOOS=darwin  GOARCH=arm64 go build -o app-macos .
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o app.exe .

# A minimal container: the binary is the whole image.
#   FROM scratch
#   COPY app-linux-amd64 /app
#   ENTRYPOINT ["/app"]

🐹 The portable layer, and the escape hatch

Most of what you need is portable: os, io, os/exec, os/signal, time, net. Write against those and your code runs on Linux, macOS, and Windows unchanged. When you genuinely need a platform-specific call (an ioctl, a Linux-only flag), drop to syscall or golang.org/x/sys behind a build-tagged file. The rest of this track lives at exactly that boundary — portable when it can be, raw when it must be.

⚠️ cgo quietly breaks 'static and portable'

The static-binary superpower depends on cgo being off. Import a package that uses cgo (some DB drivers, or net/os/user with the C resolver) and your “static” binary may dynamically link libc — so it won’t run on scratch, and it won’t cross-compile without a C cross-toolchain. Set CGO_ENABLED=0 and test on your actual deploy image. Also: file modes, path separators, and signals differ across OSes — don’t hard-code /tmp or assume SIGUSR1 exists on Windows.

See also

Next: how a Go program actually crosses into the kernel — system calls.

syscallsSystem Calls

How Go asks the kernel for services — system calls, the syscall and x/sys packages, file descriptors, the standard streams, and tracing calls with strace/dtrace.

filesFiles & Directories

Working the filesystem in Go — permissions, reading and walking directories with WalkDir, computing directory sizes, finding duplicates by hash, and symlinks.

processesSignals

Reacting to OS signals in Go — os/signal.Notify, catching SIGINT/SIGTERM for graceful shutdown, signal.NotifyContext, and ignoring or resetting signals.

Check your understanding

Score: 0 / 5

1. What makes deploying a Go program so simple compared to Python or Java?

A Go build (with CGO_ENABLED=0) produces one self-contained executable — copy it to a scratch/distroless container and it runs. No interpreter, no shared libraries, no dependency hell. That's a big reason Go dominates cloud-native tooling.

2. How do you cross-compile a Linux/arm64 binary from a macOS laptop?

Go cross-compiles out of the box: set GOOS and GOARCH and `go build` emits a binary for that target, no extra toolchain (as long as CGO is off). This is why one CI job can build releases for every platform.

3. Go has a garbage collector. Why is it still suitable for systems work?

Go trades C's manual memory management for a concurrent, low-latency GC plus memory safety. For the vast majority of systems software (CLIs, daemons, network services) that's the right trade; where it isn't, you reduce allocations or set GOGC/GOMEMLIMIT — see the internals track.

4. Which of these widely-used infrastructure tools are written in Go?

Go became the de facto language of cloud-native infrastructure — Docker, Kubernetes, etcd, Prometheus, Terraform, Consul, and more. Static binaries + cheap concurrency + a strong stdlib made it a natural fit.

5. What does the standard `os` package abstract for you across platforms?

os (with io, os/exec, os/signal) gives a portable layer over OS services. When you need platform-specific calls, drop to the syscall package or golang.org/x/sys — the rest of this track lives at that boundary.

Comments

Sign in with GitHub to join the discussion.