In 2007, Google had an unexpectedly mundane problem for a company with some of the world’s largest computing resources: some of its massive C++ projects could take many minutes, and sometimes hours, to compile. Ken Thompson, the creator of Unix and a Turing Award winner, joined Robert Griesemer and Rob Pike to design a language intended to address part of that problem by removing complexity. The result was Go, publicly unveiled in 2009 and later adopted by infrastructure projects such as Docker, Kubernetes, Prometheus, and Terraform.
The story behind Go in 20 seconds
- Robert Griesemer, Rob Pike, and Ken Thompson began designing Go at Google on September 21, 2007.
- Long build times for large software projects were one of the acknowledged motivations behind the language.
- Go prioritized fast compilation, integrated tooling, and a deliberately small language.
- Its simplicity attracted criticism, particularly because features such as generics were missing.
- Go 1.18 eventually introduced generics in March 2022.
The story is often presented as a rebellion against C++, but the reality is more nuanced. Go was not created simply because Thompson considered another programming language bad. Google was building systems containing tens of millions of lines of code, maintained by hundreds or thousands of developers and connected through huge dependency graphs. Rob Pike later explained that builds could take hours even when large compilation clusters were available.
The official Go documentation also confirms that waiting for a large Google server to compile was among the language’s original motivations. The goal was to create something better suited to the kind of large-scale software Google was developing and operating.
The Problem Go Tried to Solve Was Software Development at Scale
The philosophy behind Go becomes easier to understand by looking several decades further back.
Ken Thompson had worked with Dennis Ritchie and other Bell Labs researchers on Unix, an operating system whose influence ultimately spread far beyond the original Unix codebase. Linux is not directly derived from its source code, but reproduces much of the Unix model; Android uses the Linux kernel, while macOS belongs to a different historical branch built around Darwin and technologies derived from BSD, NeXT, and Mach.
Describing Thompson as the “father of every modern operating system” therefore makes for a compelling headline, but it is technically inaccurate. His influence is enormous, although the actual family tree is considerably more complicated.
Decades later, Thompson found himself confronting a familiar engineering problem: how to prevent a system from accumulating so much complexity that the complexity itself begins to obstruct development.
On September 21, 2007, Robert Griesemer, Rob Pike, and Ken Thompson began sketching the goals of a new programming language on a whiteboard, according to Go’s own documentation.
Compilation time was not the only issue.
Google was working with enormous programs maintained simultaneously by large engineering teams. In those environments, build speed matters, but so do the cost of understanding someone else’s code, analyzing dependencies, onboarding developers, and maintaining internal tooling.
Go attempted to address several of those problems through the design of the language itself.
Instead of continuously adding mechanisms to accommodate every possible programming style, its creators deliberately restricted the number of choices available.
That approach had an interesting consequence for engineering organizations: fewer individual choices could produce greater consistency across an entire team.
One of the clearest examples remains gofmt.
In many programming languages, engineering teams maintain extensive style guides covering indentation, whitespace, line breaks, and the placement of particular constructs. Go provides an official tool that automatically standardizes source-code formatting.
The official documentation describes automating routine tasks, including formatting, as one of the broader goals of the language.
For an individual developer, formatting may appear to be a minor issue. Across a repository maintained by hundreds of engineers for years, it eliminates an entire category of decisions and disagreements.
From Criticism Over Missing Features to the Language of Cloud Infrastructure
Simplicity came at a cost.
Early versions of Go lacked features that developers had come to expect from modern programming languages. It had no generics, for example, and did not adopt the traditional exception model or the class inheritance hierarchies familiar from Java and C++.
Those decisions attracted criticism almost from the moment Go became public.
A well-known explanation by Rob Pike about the kind of developers Google needed Go to serve also helped create the perception that the language had been deliberately simplified for less sophisticated programmers. The popular interpretation eventually produced labels such as a “language for dumb programmers,” although reducing Pike’s position to that phrase removes much of his original argument: Google needed software that enormous teams could understand and maintain over long periods.
The language found an especially suitable environment a few years later.
The expansion of containers, distributed systems, and cloud infrastructure created demand for software that was relatively straightforward to compile, distribute, and deploy.
Go fit that environment well.
Docker was primarily developed in Go. Kubernetes, originally released by Google in 2014, also chose Go. They were followed by projects that became part of everyday work for system administrators, SREs, and DevOps teams, including Prometheus and numerous other components of the cloud-native stack.
Terraform, originally created by HashiCorp, is another prominent example of Go being used for infrastructure tooling.
No single feature explains that adoption.
Go combines native compilation, built-in concurrency through goroutines and channels, automatic memory management, a substantial standard library, and a tightly integrated toolchain.
It can also produce executables that are particularly convenient to distribute in many deployment scenarios.
For infrastructure software, that has practical consequences. A vendor can provide an executable without necessarily requiring administrators to prepare an entire runtime environment equivalent to the one used during development.
Go also avoids requiring an external build system for common scenarios.
The project explains that one of its original goals was for source code to contain enough information to build itself, reducing the need for mandatory Makefiles or equivalent build configurations.
That combination helped Go find a market where its apparent austerity became an operational advantage.
Go Eventually Accepted Generics Without Abandoning Its Philosophy
The story did not end with the language permanently frozen around decisions made in 2009.
For years, one of the most common requests from Go developers was support for generic programming.
The team resisted until it found a design it considered compatible with the rest of the language.
Finally, Go 1.18 introduced generics on March 15, 2022, through parameterized types. The Go project described it as the largest change to the language since Go was first released as open-source software.
The addition is interesting precisely because it demonstrates that simplicity does not necessarily mean immobility.
Go introduced a feature it had resisted for more than a decade, while continuing to recommend using it only where it provides a concrete benefit. Ian Lance Taylor later summarized that philosophy by recommending that developers begin by writing ordinary functions and introduce type parameters when their usefulness becomes clear, rather than designing programs around generic abstractions from the outset.
The language continues to evolve.
An official Go project publication dated August 26, 2026, explains that Go 1.27 introduces generic methods, extending the generics model initially introduced with Go 1.18.
Almost two decades after that first whiteboard session at Google, Go’s history can now be viewed with considerably more perspective.
It did not “humiliate” C++, Java, or other modern programming languages. All of them continue to solve problems for which Go may not be the right choice.
What Go did demonstrate is something particularly relevant to developers and system administrators: a programming language can gain adoption not by providing more possibilities, but by reducing the number of decisions required to build, read, compile, and deploy software.
The problem Thompson, Pike, and Griesemer were trying to solve in 2007 was not how to create the most sophisticated programming language.
It was how to enable large groups of engineers to build large systems without allowing the complexity of the development process itself to become another engineering problem.
Go’s later presence in Docker, Kubernetes, and a substantial part of the cloud infrastructure software stack turned that design decision into something much more consequential than another debate about programming languages.
Frequently Asked Questions
Why did Google create Go?
Long compilation times and the difficulty of working with enormous codebases were among the motivations. Google also needed tooling suited to software maintained by large engineering teams and deployed at scale.
Who created Go?
Robert Griesemer, Rob Pike, and Ken Thompson began defining the language at Google on September 21, 2007. Go was publicly announced in November 2009.
Why is Go so widely used for cloud infrastructure?
Its native compilation, concurrency model, integrated tooling, and straightforward executable distribution are well suited to network services and infrastructure software. Kubernetes, Docker, and Prometheus are prominent examples.
Does Go support generics?
Yes. Go 1.18 introduced generics in March 2022, more than a decade after the language was first made public. The generics model has continued to evolve since then.