Rob Pike

This is the story of four videos by Rob Pike, one of the creators of the Go programming language, each marking important milestones throughout the past 15 years: from the introduction of the language to the world in 2009, to its time of meteoric growth during 2012 and 2015, and finally to a review of the first 14 years of existence in 2023.

2009

The first video is the introduction of the Go programming language at Google on October 30th, 2009. This video is part of the Google TechTalks series we have talked about in a previous article of this magazine.

There are various interesting aspects to this video, starting with the opportunity that web video brings as a store of recent historical references; where are the introduction videos of languages such as FORTRAN, C++, or even PL/I? Going back in time provides, such in this case, the possibility of understanding the why of the language, the reasons and the needs that it fulfilled, which in turn gives quite a bit of background to l’air du temps at the time of its birth.

Rob Pike starts the presentation calling Go “experimental”, setting expectations up front, in a clear example of what I call “honestization”, but in a vain effort to contain the inevitable hype that surrounded the language. (And hype around Go there was, even a lot.)

The gist of the situation in 2009 was clear and dramatic: the new world was all about computers that have stopped getting faster (or, as Herb Sutter said, the free lunch was over), lots of networking, the rise of computer clusters, the need for scalability, and the dramatic destruction of developer productivity generated by slow build cycles.

The tension between strong typing and long compiler cycles was dragging the whole industry down. According to Pike,

You can be productive or safe, not both.

The backlash against Java around that time (which we discussed in a previous edition of this magazine) was strong, and translated in the rebirth of dynamic programming languages (with Ruby, JavaScript, and Python leading the charge). But as Robert Griesemer said (quoted by Rob Pike),

Clumsy type systems drive people to dynamically typed languages.

The idea of Go was from the beginning to find an equilibrium and to provide a decent type system that would also yield a good developer experience. In contrast, Rust chose to ditch that requirement, pushing the envelope of what a type system could do to the extreme, at the expense of compile times.

Go became, then, an object-oriented language without type hierarchies, with a clean and concise syntax, with zero-initialized variables, a garbage collector based on the IBM Recycler design, featuring concurrency with channels, interfaces, and a strong compatibility promise.

But what did Rob Pike say about generics support? Well,

Would definitely be useful: in short, not yet.

Sorry people, you’ll have to wait until the 2020s for that.

2012

Comes next “Concurrency is not Parallelism”, a talk by Rob Pike given at the Waza 2012 conference, precisely the same year when Go version 1.0 was released.

This talk starts with an appropriate observation:

You might think the world is object-oriented, but it’s not, it’s concurrent.

But as the title suggests, Pike explains that concurrency is not exactly the same as parallelism; actually, concurrency is much more than just programming code that runs on multiple CPUs at once.

Concurrency, for Rob Pike, is a way to think about programs, as small independent processes that do their own thing, communicating when needed, reporting back when they are done. Concurrency is about structure and composition.

The architectural ideas embedded in Go (as well as those in Erlang and Crystal) were originally explained by Tony Hoare in his “Communicating Sequential Processes” 1978 paper.

Parallelism, on the other hand, is about the execution itself, when various parts of a program happen to be running at the same chronological time. There is no structure implied in this concept. We don’t have to worry about parallelism when doing concurrency: a design might be concurrent, but not work in a parallel way. The issue is to design solutions as concurrent, not as parallel, per se.

Developers must not think about running things in parallel, but instead should concentrate in breaking the problem into things that can run concurrently, doing different tasks at once. Concurrency is not parallelism, but enables it.

For those unfamiliar with the language (this was 2012 after all, the year Go went 1.0) Rob Pike provides a short intro to the language around 14:00, in particular, comparing Go coroutines with the ampersand on the Linux shell. To provide some context, Rob Pike also links to a paper by Russ Cox that connects the historical dots between Go (among other languages) and communicating sequential processes (CSP) as described by Tony Hoare.

Rob Pike’s phrase at 05:40 appropriately summarizes the talk:

These ideas are not deep, they are just good.

Maybe what is not that good is to use “Gophers burning C++ books concurrently” as an example program to demonstrate this way of thinking. Can we just stop using these backward and passive-aggressive kind of language?

2015

Rob Pike’s “Go Proverbs” presentation at Gopherfest 2015 is our third video. From a historical point of view, this was the time of the rise of containers and Kubernetes, and with them, the rise in prominence of Cloud Native technologies and microservices as a dominant architectural paradigm.

It turns out that the name of the programming language is not entirely unrelated to the game of the same name, in particular because both feature easy rules that are hard to master. Pushing the analogy a bit too far, Rob Pike takes inspiration from the 1960 book “Go Proverbs Illustrated” by Kensaku Segoe and its list of traditional go proverbs to state his own list of 18 proverbs for the programming language.

(This is an exercise not too far removed from that of Geoffrey James’ “Tao of Programming” which, by the way, we have discussed in a previous issue of this magazine.)

Without boring the reader, here are some of the most salient of Pike’s Go Proverbs:

Don’t communicate by sharing memory, share memory by communicating.
(…)
Make the zero value useful.
(…)
A little copying is better than a little dependency.
(…)
Clear is better than clever.
(…)
Don’t just check errors, handle them gracefully.

Needless to say, many of the 18 proverbs apply not only to Go, but to pretty much every programming language you can think of. Precisely about this point, there is an interesting observation of Pike toward the end of the video:

Go created a community around a certain way of programming

2023

Finally, the fourth video of this edition is Pike’s “What We Got Right, What We Got Wrong” talk at GopherConAU 2023, coinciding with Go’s 14th birthday.

Let us start with the things that Pike is happy about: the formal specification and the portability of the language; its compatibility from 1.0 onward; the tooling and libraries provided since day one, in particular gofmt; interfaces, which are Pike’s favorite feature; and the support for concurrency (of course!)

Goroutines in Go, coroutines in Lua, and fibers in Ruby are perfectly adequate.

What was not so good? Engaging with the community took some time (and friction) to get right; the process of developing the package manager was suboptimal; and the quality and quantity of documentation and examples, at least at the beginning, left a lot to be desired.

What about generics? According to Pike, “Generics” is the wrong word for what Go ended up providing: “parametric polymorphism” is a better description.

In general, the original goal of the project was not to create a new programming language, but rather to create a new way of programming large production systems with large teams. In this sense, yes, the project can be considered a resounding success.

This session ends with a somewhat terrible question and answer session at the end, to which Pike tries to answer in the best possible manner, providing some interesting cues at the same time:

(35:21) There will be no such thing as Go 2 in the foreseeable future.
(36:07) One wish, a feature we should have done but didn’t: arbitrary precision integer types.
(41:10) Anything that makes your program safer at compile time it’s good, but I don’t want to spend 2 hours waiting for it to build.

2009

2012

2015

2023

More Videos