CHAPTER 02 · FOUNDATIONS

The Story of Go

You're about to spend a lot of time with Go. It helps to know why it exists. Most languages are designed by individuals or small academic teams; Go is unusual in that it was built by a tiny group of Unix legends to solve a very specific industrial pain. Understanding that origin explains a lot of the choices you'll see throughout the language.

Learning objectives

  • Know who created Go, when, and the company behind it.
  • Identify the three concrete pain points that motivated the language.
  • Recall Go's main strengths in a single elevator pitch.
  • Name several major projects written in Go.
  • Recognize the design philosophy ("less is more") that shapes every chapter ahead.

The birth of Go

Go was started in September 2007 at Google by three engineers with serious systems pedigree:

  • Robert Griesemer: co-designed the V8 JavaScript engine and Java HotSpot's compiler.
  • Rob Pike: co-creator of Plan 9 and UTF-8, long-time member of the original Unix team at Bell Labs.
  • Ken Thompson: co-author of Unix itself, co-creator of the B language (a precursor to C), Turing Award winner.

The project was made public in November 2009. Go 1.0 shipped in March 2012 with a famous compatibility promise: any program that compiles under Go 1 should keep compiling and working under every later release of Go 1. More than a decade later, that promise has held. Code written in 2012 still builds today.

i
"Go" or "Golang"? The language is named Go. "Golang" is a search-friendly nickname (because "Go" is a tough word to Google) that the community adopted. The official site uses both: go.dev for the project, golang.org still resolves. Either name is fine.

Why Go was created

Google in the mid-2000s was wrestling with three problems on its massive C++ codebase:

  1. Compile times measured in minutes. C++ at Google scale meant builds that ate huge chunks of an engineer's day. Slow feedback loops kill productivity.
  2. Brittle dependency management. Header files, the preprocessor, and tangled include graphs made even small changes expensive.
  3. Concurrency was painful. Multi-core CPUs were the norm, but the available concurrency tools (raw threads, locks, callback hell) were error-prone and hard to reason about.

Existing languages each fixed some of these but none all three. C++ was fast but slow to compile and tricky for concurrency. Java was easier but heavy. Python was fluent but slow at runtime. Go was an attempt to keep the speed and reliability of C++, the simplicity of a scripting language, and bake in modern concurrency primitives from day one.

i
The original sketch Pike has told the story that the idea coalesced while waiting on a massive C++ build. Go's near-instant compilation was the first feature on the wishlist, and it remains true today: even large Go projects typically rebuild in seconds.

Main benefits of using Go

If you have to pitch Go to a teammate, this is the elevator pitch:

  • Simple, readable syntax. The language spec is short by design. Fewer features means fewer ways to write something, code looks similar across teams and projects.
  • Fast compilation. Even big repos build in seconds.
  • Statically typed, garbage collected. You get the safety of static types without managing memory by hand.
  • First-class concurrency. The go keyword and channels are part of the language, not bolt-on libraries.
  • Excellent standard library. HTTP servers, JSON, templating, crypto, archives, testing: all in the box.
  • Single binary deployment. go build produces one self-contained executable. No runtime to install on the target machine.
  • Cross-compilation. Build a Linux binary from your Mac with one environment variable.
  • Tooling included. Formatter, vet, test runner, benchmark runner, doc tool, race detector: all ship with the compiler.

A short timeline

2007 project starts Nov 2009 open-sourced Mar 2012 Go 1.0 compat promise 2014 Kubernetes released 2018 Go modules (go.mod) Mar 2022 Go 1.18 generics today Go 1.22+ range-over-int, workspaces
17+ years on, every program written for Go 1.0 still compiles.

Go in the wild

Go's killer use case turned out to be cloud and infrastructure tooling. A single static binary is perfect for distributing tools that need to run on many machines without depending on any runtime being installed.

A small sample of well-known Go projects:

ProjectCategoryWhat it does
DockerContainersRuns applications in isolated environments
KubernetesOrchestrationSchedules and operates containerized apps
TerraformIaCProvisions cloud infrastructure declaratively
PrometheusMonitoringTime-series database for metrics
etcdDistributed KVPowers Kubernetes' control plane
CockroachDBDatabaseDistributed SQL
InfluxDBDatabaseTime-series database
CaddyWeb serverModern HTTPS-by-default web server
HugoStatic sitesLightning-fast static site generator
gRPCRPCHigh-performance RPC framework
TailscaleNetworkingMesh VPN built on WireGuard
SyncthingFile syncOpen-source continuous file sync

The companies betting on Go are similarly broad: Google, Cloudflare, Netflix, Uber, Twitch, Dropbox, Stripe, MongoDB, GitHub, Shopify, Mozilla, Heroku, and many more use Go for production backends and internal tooling.

The Go philosophy

Go's designers made several deliberate choices that surprise people coming from other languages. Some of them:

  • No inheritance. Composition (embedding) is preferred. You'll see this in Chapter 15.
  • No exceptions. Errors are values returned from functions. (Chapter 23.)
  • No generics: until 2022, when they were added very carefully (Chapter 22).
  • One canonical formatting via gofmt. There are no style debates in Go projects, because there's no style choice. (Chapter 19.)
  • Unused imports and variables are compile errors. Annoying at first, valuable forever.
  • The standard library is enough for most things. You can build a real web server with zero third-party dependencies.

The unifying principle is "less is exponentially more" (a Pike-ism). Each absent feature is a deliberate choice to keep the language small enough that an engineer can hold the entire spec in their head. As you go through the next 32 chapters, you'll bump into these choices repeatedly. Once you internalize the philosophy, the language clicks.

The "Go proverbs" Rob Pike gave a famous talk titled "Go Proverbs" at Gopherfest 2015. A few favorites: "Don't communicate by sharing memory; share memory by communicating." · "Errors are values." · "Clear is better than clever." Worth a 15-minute watch once you've finished the course.

Check your understanding

Practice exercises

EXERCISE 1

Find a Go project you use

You almost certainly use Go-built software every day, even if indirectly. Take 5 minutes to look at the tools and platforms in your daily life (Docker, your CLI tools, your favorite static-site generator, your VPN, your CI provider, your monitoring stack…) and find at least two that are written in Go.

Goal: realize that you're not just learning a language, you're learning the de facto language of modern infrastructure.

Tips on where to look
  • Open your ~/Applications or /usr/local/bin: anything from Docker, Hugo, kubectl, Helm, Tailscale, Syncthing, gh (GitHub CLI), terraform, vault, consul is Go.
  • Look at your CI/CD: GitHub Actions runners, Drone, Concourse, Go.
  • Check your servers: Caddy, Traefik, NATS. All Go.
  • Most cloud-vendor CLIs (aws, gcloud, az) have major components in Go.
EXERCISE 2

Pitch Go in one sentence

Imagine a coworker asks: "Why are you learning Go instead of Python / Rust / Java?" Write a one-sentence answer based on what you learned in this chapter. The constraint: keep it under 25 words and avoid empty buzzwords (no "modern", "powerful", or "scalable").

A few sample answers
  • "It compiles to a single static binary, has built-in concurrency, and forces my whole team to write code that looks the same."
  • "It's the language Kubernetes, Docker, and most cloud infra are written in, and it builds in seconds, not minutes."
  • "I want C-level deployment simplicity without the C-level footguns or compile times."

Yours is probably better than these, the point of the exercise is to make sure you've internalized why, not which exact words you use.

Further reading

Got the big picture?