Static Binaries & the Go Toolchain

Node.js: runtime + node_modules

When you ship a TypeScript/Node.js application you need to provide:

The Node.js runtime (the correct version — managed by .nvmrc, Docker base image, etc.)
Every npm package your code depends on (node_modules/ — often hundreds of MB)
A transpile step (tsc, esbuild, swc, etc.) to convert TypeScript to JavaScript

Deployment means ensuring all three pieces are present and version-matched on every target machine.

Go: one binary, zero runtime

A Go program compiles to a single static binary that contains your code, all your dependencies, and the Go runtime — all linked in. The target machine needs nothing extra installed. No Go installation, no package manager, no interpreter.

# TypeScript deployment checklist
# 1. Install Node.js (exact version)
node --version   # must match .nvmrc

# 2. Install dependencies
npm install      # downloads node_modules/ (~hundreds of MB)

# 3. Build
npx tsc --build

# 4. Run
node dist/index.js

# Dockerfile must include:
# FROM node:20-alpine
# COPY package*.json ./
# RUN npm ci
# COPY dist/ ./dist/
# CMD ["node", "dist/index.js"]

# Go deployment checklist
# 1. Build
go build -o myapp ./cmd/myapp

# 2. Copy binary to target (that's it)
scp myapp user@server:/usr/local/bin/

# 3. Run
./myapp

# Dockerfile can be:
# FROM scratch          <-- empty base image!
# COPY myapp /myapp
# CMD ["/myapp"]
#
# Final image is often < 10 MB vs 200–500 MB for Node

Cross-compilation in one command

Go has built-in cross-compilation. Set GOOS (target OS) and GOARCH (target CPU) as environment variables and run go build. No extra toolchain, no Docker emulation, no separate CI step per platform.

# TypeScript cross-platform is handled by Node.js itself
# But native addons (node-gyp, .node files) break cross-platform
# pkg / nexe / sea bundle Node + app, but are complex and large

# Build for Linux amd64 on a Mac
GOOS=linux   GOARCH=amd64  go build -o myapp-linux    ./cmd/myapp

# Build for Windows
GOOS=windows GOARCH=amd64  go build -o myapp.exe       ./cmd/myapp

# Build for ARM (Raspberry Pi, AWS Graviton, Apple Silicon)
GOOS=linux   GOARCH=arm64  go build -o myapp-arm64     ./cmd/myapp

# All three commands run on your laptop — no emulation needed
# Each output is a standalone executable for that platform

Fast compile times

Go was designed with compile speed as a first-class goal. Large codebases that would take minutes in C++ or even seconds in TypeScript (full tsc) compile in seconds or sub-seconds in Go. The standard library is pre-compiled, dependency graphs are explicit, and there is no circular import detection overhead.

# TypeScript build times (realistic examples)
# tsc --build on a medium NestJS project: 5–30s
# esbuild (fastest TS bundler): 0.5–3s
# But: tsc is also used for type-checking only (no emit)
# Type-check of a large monorepo: 30s–3min

# Go build times
# go build ./...  on a medium service: < 2s
# go test ./...   (build + run tests):  2–10s
# go vet ./...    (static analysis):    < 1s

# The toolchain is one binary — no plugin ecosystem needed:
go build   # compile
go test    # test
go vet     # static analysis
go fmt     # format (gofmt — no config needed)
go mod     # dependency management

🟦 Static Binary — What Gets Linked In

By default, go build produces a statically linked binary on most platforms. Everything your program needs is embedded:

Your application code
All imported packages (including third-party modules)
The Go runtime (scheduler, GC, goroutine stack management)
The standard library packages you use

The only exception is programs using cgo (calling C libraries via the import "C" mechanism), which introduce dynamic linking to libc. For pure Go programs, the binary is completely self-contained.

# Verify your binary has no dynamic dependencies:
$ ldd ./myapp
    not a dynamic executable    # ← pure Go: static!

# For cgo programs, force static linking:
CGO_ENABLED=0 go build -o myapp ./cmd/myapp

The CGO_ENABLED=0 flag is critical for Docker FROM scratch images.

🟦 go mod — Reproducible Dependency Management

Go modules (go.mod / go.sum) are Go’s answer to package.json / package-lock.json. The go.sum file stores cryptographic checksums of every dependency’s source code — ensuring that the same source tree is fetched every time, on every machine.

# go.mod — direct dependencies only
module github.com/example/myapp

go 1.22

require (
    github.com/gin-gonic/gin v1.9.1
    github.com/jackc/pgx/v5  v5.5.0
)

# go.sum — cryptographic checksums (committed to version control)
# Ensures supply-chain integrity — no mutable "latest" pulls

Unlike npm, there is no central registry you must trust unconditionally — anyone can host a Go module at any URL, and go.sum guarantees the content has not changed after you first fetched it.

🟦 The Playground Cannot Demonstrate Build Commands

This lesson’s core feature — compiling to a static binary, cross-compilation, and Docker deployment — cannot be shown in a browser-based Go playground. The playground only runs code; it cannot produce binary artifacts.

To experiment with these features locally:

# Install Go from https://go.dev/dl/ (one installer, no version manager needed)
go version              # verify install

# Start a new module
mkdir myapp && cd myapp
go mod init github.com/you/myapp

# Write main.go, then:
go build -o myapp .     # static binary in current dir
./myapp                 # run it — no "node" prefix needed

# Cross-compile
GOOS=linux GOARCH=amd64 go build -o myapp-linux .