Golang Co-Creator Rob Pike: ‘What Go Got Right and Wrong’

There was a treat for attendees at GopherCon AU in Sydney, Australia — the city where Go’s specification was first drafted. Original Go co-designer Rob Pike gave a talk commemorating the 14th anniversary of the day the Go programming language launched with a talk looking back on “what we got right, and what we got wrong.”

Pike began by remembering watching as the website first went live on Nov. 10, 2009, “and the world learned what we’d been up to.”

“Fourteen years later, there is much to look back on,” Pike told his audience, promising to explore “larger lessons learned.”

Pike emphasized he was speaking for himself (and not the Go team or Google). “Go was and still is a huge effort by a dedicated team and a huge community.”

But he went on to deliver a talk sharing lots of insider memories about the early history of Go — along with some useful insights about what’s important when developing a programming language...

A Better Way to Code

Go’s five original creators discussed what made Go popular for a 2022 article in Communications of the ACM. In that article Pike joined with Ken Thompson, Russ Cox, Robert Griesemer, and Ian Lance Taylor to point out that Go was specifically designed for concurrency and parallelism, leveraging the power of new multicore chips while handling at-scale workloads.

But they’d also credited Go’s ongoing “development-focused philosophy” for its success — as well as its thriving community and its contributions (including new packages).

It’s a theme Pike revisited in his November talk. Our original goal was not to create a new programming language. It was to create a better way to write software…”

“If it didn’t take 45 minutes to build the binary I was working on at the time, Go would not have happened.”

Soon Pike was sharing with the audience his detailed list of “things we got right… each was crucial to the ultimate success of Go.” For example, they made sure Go was easy to parse — which in turn made it easy to create tools like IDEs, as well as Go’s official language server gopls (which also provides IDE features).

Soon they were also augmenting the compiler with tools for automated testing and code vetting. (Not to mention the package-compiling go command.)

But that wasn’t the only thing that Go got right…

• Pike also applauds the gofmt auto-formatting tool — partly because the “guts” of tool became a library that could be re-used in simplifiers, analyzers and tools verifying that crucial code is covered by testing suites. (Not to mention that the output of these tools could always be perfectly formatted — for humans, and for machines.) “The time saved by not arguing over spaces and newlines is worth all the time spent defining a standard format and writing this rather difficult piece of code to automate it.”
• Interestingly, Go’s package library “grew somewhat as an accident, as there was no other place to install Go code at the beginning.” But now Pike sees it as another thing Go got right. “The existence of a solid, well-made library — with most of what one needed to write 21st-century server code — was a major asset. It kept the community all working with the same toolkit until we had experience enough to understand what else should be made available.”
• Another thing Go got right was its release of a formal specification. “Not only does that lock down behavior when writing a compiler — it enables multiple implementations to co-exist and agree on that behavior.” This in turn helped refine the language, Pike says — and to fine-tune its specification.
• Early on Go issued a compatibility guarantee, producing a “dramatic, documented effect” on the language’s uptake, Pike says — so much so, that “I find it puzzling that many other projects have resisted doing this.”

Pike also added, as an aside, that “it didn’t hurt that Go acquired a reputation for fast builds…”

What Go Left out

Pike also gave the audience a glimpse at a feature that never made it in, but he wished it had: allowing arbitrary precision integers, which he said would’ve eliminated an entire class of security concerns.

In a world where long integers can exceed the allocated memory, “There’s still debates going on about how we handle integer overflow. Well, what if they don’t overflow? You don’t have to think about it at all!” The runtime cost would be low, “and I just wish I’d thought of it in time and done it. People may have objected — it looks too expensive — but what it frees up is amazing. You just don’t think about integer overflow anymore.”

Later he says he’d like to see the compiler doing more automatic checking of Go’s dynamic interfaces, and also checking for the possibility of stalled-progress deadlocks that could be caused by resource sharing.

“Anything that makes your program safer at compile time is good” — although he also wouldn’t want insufferably long compile times.

The Oddities of Go’s Compiler

One other crucial thing that Go got right, according to Pike, was its portability — that is, making it easy to compile code for other platforms. It was made possible in part by Ken Thompson’s compiler — written in the C programming language, even though others argued that the compiler should’ve been written in Go itself (or using the tools in LLVM).

Pike acknowledges Thompson’s compiler was “an odd duck… using old ideas in compiler writing” (albeit modestly-sized, as well as “pragmatic and efficient.”) But best of all, it was “familiar to us, which made it easy to make changes quickly as we tried new ideas… Doing it our way, however unorthodox, helped us move fast. Some people were offended by this choice, but it was the right one for us at the time.”

By 2015 Russ Cox had written a tool to translate the compiler semi-automatically from C to Go.

“And of course, today there is an LLVM-hosted compiler for Go, and many others, as there should be.”

A Gopher for Gophers

Pike’s list of what Go got right started, surprisingly, with Go’s mascot, an unnamed cartoon gopher that he called “one of the earliest factors in Go’s success.”

Pike truly believes it was “vital” to Go’s growth — having “a recognizable, funny creature” that the community could rally around. “Its goofy yet intelligent demeanor — he can build anything! — sets the tone for the community’s engagement with the project, one of technical excellence allied with real fun.”

Yet one decision that was “perhaps not the best choice” was releasing the gopher’s design under a Creative Commons attribution license. “On the one hand it encouraged people to remix them in fun ways,” Pike acknowledged, “which in turn helped foster community spirit.”

It’s a Gopher cuddling up the engineer.#Golang #Gopher #engineer pic.twitter.com/4O14JcvGli

— tottie ｜ Designer (@tottie_designer) January 18, 2019

But Pike says there were also frustrating arguments to correct attributions (or mis-attributions), “and to be honest the attribution was often honored only reluctantly or not at all…

“So if we were doing it over, we’d think hard about the best way to make sure the mascot stays true to his ideals.”

The Concurrency Wars

Pike’s talk culminated with Go’s most impactful decision — but he started by describing what the world was like in 2002, when he’d first joined Google. Google had seemed to be avoiding the concurrent execution of process threads, if not “pretty much banning them outright,” Pike remembers — which bothered him. “I’d been doing concurrency-like things — somethings without even realizing it — since the 1970s.” In 2002 there were many people who believed threads were a bad idea. But Pike had seen papers, books, and even other languages all touting the belief that threads could be done well.

“It just hadn’t caught on as a mainstream idea yet… Go was born partly to address that.”

It ends up being one of the biggest things that Go got right. “Nowadays most mainstream languages have good support for concurrency,” Pike noted. But at the time it made Go “seem like something new… Go’s support for concurrency was a major attractor that helped grow early adoption, pulling in programmers that hadn’t used concurrency before but were intrigued by its possibilities.” Pike believes they absolutely succeeded — Go “helped popularize concurrency as a way to structure server software.” (Although he admits that it might’ve been less impressive to programmers who weren’t tackling “intrinsically parallel” problems like serving HTTP requests.)

Soon Pike’s talk arrived at his grand conclusion. “Here we are, 14 years after the launch. And it’s fair to say that overall it’s a pretty good place.” Pike succinctly summarized other factors in their success in a blog post encapsulating his talk…

👁 Rob Pike's list of what Go got right - screenshot from blog post

“And, most of all, because of the support of an unbelievably helpful and diverse community of Gophers.”

“Perhaps the most interesting consequence of these matters is that Go code looks and works the same regardless of who’s writing it, is largely free of factions using different subsets of the language, and is guaranteed to continue to compile and run as time goes on. That may be a first for a major programming language.

“We definitely got that right.”

Full talk here: