A 45-Minute C++ Build Helped Start Go. Very Few of Its Early Programmers Came From C++.

Around September 2007, Rob Pike’s C++ compiles at Google were taking about 45 minutes, and before one of them finished, he and two colleagues had decided to start what became the Go programming language.

Pike was doing what he later called “minor but central work on an enormous Google C++ program.” His compiles took that long even on Google’s “huge distributed compile cluster.”

During that period he went to a talk by a couple of Google employees who served on the C++ standards committee. They were describing C++0x, the next version of the language, later known as C++11. “In the span of an hour at that talk,” Pike recalled, “we heard about something like 35 new features that were being planned.”

He left with a question. Did the committee really believe that what was wrong with C++ was that it didn’t have enough features?

Back in his office, by his own account, “I started another compilation, turned my chair around to face Robert, and started asking pointed questions.” Robert was Robert Griesemer. “Before the compilation was done,” Pike wrote, “we’d roped Ken in and had decided to do something.” Ken was Ken Thompson. On a whiteboard, the three wrote a list of what they wanted.

That compile is where Go’s founding story usually starts. What came out of it was a decision, not yet a design.

Why 4.2 MB of C++ became 8 GB of compiler input

In a 2012 talk, “Go at Google,” Pike described a measurement that shows why such builds were slow. In 2007, build engineers at Google instrumented the compilation of a major Google binary. Its roughly 2,000 files totaled 4.2 megabytes if simply concatenated. By the time the #include lines had been expanded, more than 8 gigabytes were being delivered to the compiler: “a blow-up of 2000 bytes for every C++ source byte.” That build also took 45 minutes, on a precursor of Google’s distributed build system.

An #include line in C or C++ pastes the text of a header file into the file being compiled, and headers include other headers. In a large program, the compiler ends up reading the same declarations over and over.

Go’s designers treated the blow-up as a language problem, not only a build-farm problem. In Go, an unused import is a compile-time error, so a program cannot quietly keep dependencies it no longer needs. The compiler also writes a package’s export data — what importing code needs to know — into the package’s object file. Because that data includes type information from the package’s own dependencies, an import means opening exactly one file. When the team later measured a large Google program written in Go, the same ratio was about 40 to 1, which Pike called “fifty times better than C++.”

What they actually did after the whiteboard

The Go FAQ (frequently asked questions) dates the whiteboard session to September 21, 2007, when Griesemer, Pike and Thompson “started sketching the goals for a new language.” Within a few days, the goals had settled into a plan. Design then continued part-time, alongside other work.

By January 2008, Thompson had started an exploratory compiler that generated C code. By mid-2008, Go was a full-time project, and Russ Cox joined late that year. Go became a public open source project on November 10, 2009. Go 1 followed on March 28, 2012, with a promise that Go 1 programs would “continue to compile and run without change.”

That timeline puts the famous compile in proportion. In “Go at Google,” Pike wrote that “the origin myth for Go states that it was during one of those 45 minute builds that Go was conceived,” and his own account of that compile largely supports it. The decision fit inside one compile. Turning it into a released language took about two more years.

Most of Go’s early programmers came from languages like Python and Ruby, not C++

In June 2012, Pike told a Go user group in San Francisco that someone had recently asked him about the biggest surprise of rolling out Go. He knew the answer instantly: “Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.”

His explanation, which he admitted was oversimplified, came down to what each group would give up. Python and Ruby programmers, he said, “don’t have to surrender much expressiveness, but gain performance and get to play with concurrency.” C++ programmers, in his view, have “fought hard to gain exquisite control of their programming domain, and don’t want to surrender any of it.”

The Go FAQ describes the same split. In mainstream languages, it says, one had to choose between efficient compilation, efficient execution and ease of programming, and programmers who could were “choosing ease over safety and efficiency by moving to dynamically typed languages such as Python and JavaScript rather than C++.”

Pike ended the San Francisco talk bluntly: “People who are excited about C++11’s new features are not going to care about a language that has so much less. Even if, in the end, it offers so much more.”

Fewer features had a price, and Go paid it

Go launched without generic types. Generics arrived only with Go 1.18 in March 2022, when the Go team wrote that “supporting generics has been Go’s most often requested feature” and that the release included “our biggest change ever to the language.”

The language still found its audience. For Go’s tenth anniversary in 2019, Russ Cox listed Docker, Etcd, Istio, Kubernetes, Prometheus and Terraform among the projects written in Go, and wrote that “every major cloud provider today uses core cloud infrastructure written in Go.” The FAQ now speaks of millions of Go programmers.

The useful number is 2,000, not 45

The 45-minute compile makes the better anecdote. The 2,000-to-1 blow-up is the better lesson. A build that feeds the compiler 2,000 bytes for every byte programmers wrote is not only a hardware problem. It comes from how the language lets files depend on each other. Before you add machines to a slow build, measure what the compiler actually reads.

The second lesson is about audiences. Even Go’s creators guessed wrong about who would switch first. The programmers who came were mostly not the ones who had fought for control, but the ones who had traded speed for convenience and wanted some of it back.

The question Pike took away from the C++0x talk still works on any system you maintain: is what’s wrong with it really that it doesn’t have enough features?

Explore

Stay connected