Rob Pike interview: “Go has indeed become the language of cloud infrastructure“

Introduction

We spoke to Rob Pike, the co-author of the Go programming language, about a career spanning four decades, the evolution of Go over the last ten years, and into the future.

The Interview

Evrone: Unlike many developers today, you started your career decades ago at Bell Labs. What’s been the biggest change in the way we develop software that you can think of, given your rare perspective?

Rob: The scale is much bigger today. Not just of the computers and the network, but the programs themselves. All of Unix version 6 (circa 1975) fits comfortably on a single RK05 disk pack, which has just over 2MB of storage, with lots of room left over for user software. And that was a fine computing environment, or at least seemed like one at the time. Although I can, of course, explain much of the growth, it is astonishing and perhaps not all of it is justified.

Evrone: Given the "resistance to change" and "promise of compatibility" ideas, how do you see the next 10 years for the Go programming language and its ecosystem? What is the best future you envision for your technology?

Rob: Although it's far from certain, after over a decade of work it looks like a design for parametric polymorphism, what is colloquially but misleadingly called generics, is coming in the next year or two. It was a very hard problem to find a design that works within the existing language and feels as if it belongs, but Ian Taylor invested a phenomenal amount of energy into the problem and it looks like the answer is now in reach.

How that affects the libraries, the ecosystem, and the community will be fascinating to watch.

Evrone: With "gradual typing" being introduced into "dynamically typed" languages and "type inference" into "statically typed", the line between two is now blurred. What is your opinion on a type system for a modern programming language?

Rob: I am a big fan of static typing because of the stability and safety it brings.

I am a big fan of dynamic typing because of the fun and lightweight feel it brings. (As a side note, the big push for integrated unit testing can be credited to languages like Python, which drove testing to demonstrate correctness that the typing system failed to provide.)

I am not a fan of type-driven programming, type hierarchies and classes and inheritance. Although many hugely successful projects have been built that way, I feel the approach pushes important decisions too early into the design phase, before experience can influence it. In other words, I prefer composition to inheritance.

However, I say to those who are comfortable using inheritance to structure their programs: pay no attention and please continue to use what works for you.

Evrone: Sometimes people use technologies in strange ways. For example, to generate efficient Go code from the high-level Python or Ruby code (yes, we saw that happening!) Over the years, what is the strangest, most creative or amusing Go usage have you seen? What surprised you the most?

Rob: The biggest surprise was when we learned that Go was being used to write malware. You can't control who will use your work or what they will do with it.

Evrone: You created a number of text editors. What do you think about the Visual Studio code? With technologies like LSP, the line between "text editor" and IDE is blurred now. Do you think software developers need full-featured IDEs like GoLand or using VSCode is fine?

Rob: I am from a different time, before IDEs, but there was talk early in the project about whether Go needed an IDE to succeed. No one on the team had the right skill set, though, so we did not try to create one. However, we did create core libraries for parsing and printing Go code, which soon enabled high-quality plugins for all manner of editor and IDE, and that was a serendipitous success.

More recently, we've been working hard on an LSP server for Go called gopls, which can be used by any editor or IDE that supports that protocol to improve the experience working with the language.

Perhaps because of our comfort working with simpler styles of editor, we made sure that one could work comfortably in Go without heavy lifting from the programming environment. An IDE can certainly help, though: most of those I see working in Go today use one, or at least an editor with custom Go support, and get much value from it.

The question of what style of editor to use is a matter of taste, colored by the culture of the language you work in.

Evrone: Software developers tend to label things, such as Dart being a "frontend language", and C being a "system low-level language", and so on. How would you term the Go programming language now, given its feature set and usage?

Rob: Go is a general-purpose programming language. Write whatever you want in it and don't worry about pinning the language, or any other technology for that matter, to a single problem domain.

Evrone: What other modern programming languages do you personally like?

Rob: The Go experience has taught me that people love to opine about languages, perhaps more than almost any other element of our field. And I have certainly done so myself. But I am tired of the negativity that often results, so now I try to avoid judging things for others.

There has been a real renaissance in language design over the last 10 years or so, after a period where very few new languages were arriving and succeeding. It's great to see this and the innovation it brings.

Evrone: How does being a Google employee help you develop and guide the Go language? How important is it to be able to ask "tell us how you use our language" on Twitter and get responses from the biggest companies all over the world? Is it just a nice addition or an essential part of language development? How does Google help you?

Rob: Google has been very generous in its support for the Go project, for which I am very grateful. And of course the language was created because we thought Google needed it; what became called "cloud computing" needed a language with good support for concurrency and easy deployment, among other things. But Google has not directed the project in any significant way. It supports us and lets us do what we think is best.

Regarding other companies and other users, input from the community is a vital part of understanding how the project, by which I mean the language, compiler, tools, runtime, library, environment — all of it — advances.

Evrone: After 10 years of Go development and observing how it is used, what can you name the biggest design success and, opposite, biggest design failure for the language? It's strongest and weakest points, respectively?

Rob: I would like to call out two things, one technical and one political.

The technical one is first-class support for concurrent computation. Go is only a decade or so old, but when it was being developed, "threading" and concurrency were not widely appreciated in the programming community. In fact a major reason for creating Go was the difficulty of doing concurrent computation in C++ at the time. It became clear shortly after launch that the concurrency support was a major attraction, one that compensated for what some felt were weaknesses in other parts of the language. Concurrency struck a nerve. And once people played with the concurrency, they started exploring the other things about the language and learned that there was more there than they originally thought. Support for concurrency was the gateway.

As John Graham-Cumming of Cloudflare says, "I came for the easy concurrency, I stayed for the easy composition".

Go changed the conversation around how to program multicore computers.

The political success was the firm promise made about compatibility for Go version 1. Once we, and the community, had used Go for a few years, we had a long list of things we wanted to fix, but change is disruptive. So we did a careful program of updates, with the "go fix" command to pull the community along, and once that was done, not only did we stop, we promised to stay stopped. That stability — Go programs written in 2012 will still compile and run perfectly today — was a huge enabler for growth. Companies could use the language with confidence that we would not break their software. The adoption rate increased dramatically after version 1 and its compatibility promise appeared. And although we have since learned of many other things we would like to change, we can't break existing programs, and we are fine with that.

Evrone: What does your work-life balance look like? There are lots of talks about "burn-outs" right now, and the epidemic situation does not help at all. Any hints from your 40-year journey for new generations of developers?

Rob: The best way to avoid burnout is to do something you truly enjoy in an environment that supports you. I've been very lucky in that regard through my whole career, but I realize not everyone is as fortunate. If you're feeling stressed by work, you should feel free to take a break or change direction, especially in our current situation.

Evrone: In hindsight, the popularity of many technologies is credited to so-called "killer apps" that made them popular. Can you name such a "killer app(s)" for the Go programming language and what do you think about such a "killer app" idea as a whole?

Rob: A few years ago, Danny Berkholz called Go "the emerging language of cloud infrastructure," and that is no accident. Go was designed by people working at Google to make it easier to write Google-relevant software, in particular network-resident servers. That's what we call "cloud" today. (Some of the motivation for the design is in my Splash keynote from 2012, Go at Google: Language Design in the Service of Software Engineering.)

So although it was gratifying and important to see Docker, Kubernetes, and many other components of cloud computing written in Go, it's perhaps not too surprising. Go has indeed become the language of cloud infrastructure.

Evrone: What competition do you see for the Go programming language right now and in what area? What is your opinion about Rust with its "no-garbage-collection" ideas and compile-time guarantees?

Rob: Rust is an intriguing language and I watch its development with interest. Beyond that, I offer no opinion, as I said above.

Evrone: Go has just reached 70k stars on GitHub! How do you see different social activities like GitHub, Reddit, Twitter, offline and online conferences, webinars etc influence the language? Are they important for the language's success or they just reflect it?

Rob: The people we have met through conferences and social media have been a critical part of the development of Go and all its elements. Many, many contributors have affected the development in positive ways, including the original port to Windows and a number of non-x86 architectures, development of tools and libraries, thoughtful discussions of technical proposals, and much more.

And it goes the other way, as the Go team reaches out to the community to start discussions, pose questions, and ask for help and guidance.

One thing that I think is important is to engage with the community as one voice, to speak as a team rather than as individuals. A consistent message is more easily understood.

Evrone: How being the author of one of the popular programming languages has changed your life?

Rob: A correction: I am a co-author, not the author. Ken Thompson and Robert Griesemer started the project with me, and many others contributed massively. So please don't single me out as "the author".

To answer your question, Go has certainly raised my public profile and introduced me to a new and vibrant community but beyond that it hasn't had much effect. I've had a long career with other successes (and innumerable failures).

Evrone: Imagine that you have an opportunity to travel back in time and give only one piece of advice to your younger self, at around the time you’ve started to design the Go language spec. What advice would you give to yourself and your colleagues?

Rob: That's easy: Ignore the haters. Just listen to the voices that understand and share your goals; they're the ones to care about. Not everyone agrees with what you're doing, and that's OK. But those who engage in advancing what you're trying to do can be a fantastic source of ideas, energy, and inspiration.

We will always be thankful to our passionate community.

At Evrone we pride ourselves on using the best tool for the job, whether that’s Ruby on Rails, Python, Elixir, or, of course, Go. We strive to stay at the forefront of a range of technologies to be able to provide the best and most appropriate solutions to meet our clients’ needs, and we’re very happy to do all we can to help bring developer communities together.