5 things Rob Pike attributes Go's success to

As the saying goes… history doesn’t repeat itself, but it often rhymes.

If you want to create a successful programming language (or at least understand how you might), it’s immensely valuable to learn from others who have done just that. On Go Time #100, Rob Pike and Robert Griesemer (two of Go’s creators) sat down to discuss the language’s success.

Here are 5 of the things Rob Pike attributed to the language’s success to while on the show.

1. They wrote a formal specification

While giving the origin story of the project, Rob stated:

But that’s when the spec happened. Yeah, a couple weeks. So we really started out for six months or so brainstorming and approximate-shaping. One of the first significant things we did - maybe THE first significant thing we did - was we wrote a formal specification of the language, and I think that’s a critical part of the success of the project.

One of the most important things of that was Ian Taylor was also at Google, saw the spec, and decided he wanted to write a compiler for it. So one day he walked into our office and said “Oh, by the way, I’ve written a compiler for your language.” That was an amazing moment for us. He, of course, became part of the team, and he’s still working on Go now. [source]

The spec is what garnered initial interest from fellow engineers, such as Ian Lance Taylor.

(Coincidentally, Ian was also on the show recently talking about his work on generics.)

2. They attracted killer apps

Unfortunately, Rob didn’t weigh in on how they attracted Docker early on. By making the language… attractive to systems programmers, I guess? 🤷‍♂️

Yeah, Docker was kind of our killer app, because it was written in Go, it worked well, and it became central to what is now called cloud computing… Which we used to just call system programming, or servers. And the fact that one of the critical pieces of technology was written in Go justified the language’s purpose to a lot of people… And I think it’s actually a really good language for that kind of thing; it’s exactly the kind of thing we were thinking about when we were putting the language together, although we didn’t do that ourselves.

Later Kubernetes was another one that came along, this time from Google. But having significant software written in your language is a really important part of making success happen with a language. It doesn’t matter how good the language is if nothing’s written in it. [source]

3. They started an open source community

Rob spoke pretty frankly about the challenges they faced navigating the open source world, which was refreshing to hear.

I do think that the team was not really prepared for interacting with the open source community and what that meant. Ian was the only one of us who’d spent a lot of time in the open source world, and he did more than his fair share of the community stuff.

It took us a long time to understand what it meant to be part of an open source community, to have a project that’s essentially paid for by a company, but with a lot of open source contributors… We actually had a lot of fantastic open source development occurred very early. The port to Windows was done entirely by outside contributors, which was fantastic… And the input of the community has been critical.

I think sometimes people think Google controls it too much, and that’s their opinion, but I disagree; I think they underestimate how much the team listens to what the open source community says, reads all the issues, handles it all very well… Sometimes not so well, but then it gets fixed.

It’s a really challenging thing when there’s thousands of people, and now it’s believed to be millions of Go programmers in the world. They all have an opinion about this thing, and how to listen, but also make sure you keep the soul of the project right - I don’t think there’s any simple answer to that. I think a lot of people think it’s trivial, and you just sort of take in what everyone wants… But then you wouldn’t have Go, you’d have something else altogether. It’s really tricky, it’s a very difficult balancing act. [source]

4. They made the language hard to change

This one is a bit counterintuitive at first. Usually with software, malleability is a virtue and rigidity a curse. However, Rob does a good job explaining why flipping that script is so important for a programming language like Go.

Well, we’ve made it hard to change. We deliberately wrote down, for Go 1, that we promise not to change anything. And that was critical to the success of the language, because it enabled businesses to trust that what we were doing and depending on us was not gonna break their stuff… And that made it much harder to make changes. I think a lot of people don’t appreciate how passionately we believe in that contract. We haven’t broken people’s programs, even though it’s a ten-year-old project now. It’s just an incredible burden to carry, but it was critical to get us to the place we are now. [source]

5. They stuck with features they believed in

When Jon Calhoun asked about community feedback and how the team’s resistance to change played against that, Rob said:

There were features of Go that are important to its success that people didn’t like, and we were very vocal about. I think the one you mentioned, compile error for unused variables, was one of them. It was annoying - you forget to delete an unused variable and your program will compile. But for us, that was part of the story we were trying to tell, which was to make a language that guaranteed better quality code as much as feasible, even though we can’t stop you writing bad code… But we can make sure that things don’t slip in that will make your build slower, or your code harder to maintain.

I think the one that really drove people mad was you’re not allowed to import a library you don’t use. That was vitally important to us, because we had spent so much time with slow builds with massive binaries, making sure that the dependencies of your program are exactly the ones that you need, and no more; it was vitally important to us, but to a lot of people it was just annoying as hell that every time you made an edit and deleted a print statement or something, the compiler would say “You’re not using this library. I’m not gonna build you anymore.”

And then Brad wrote this thing called goimports, which was a variant of gofmt that managed the imports for you, and that pretty much silenced that complaint. As is often the case, automation can get rid of a lot of whining. [source]

There you have ‘em. The 5 things Rob Pike attributes Go’s success to. The entire conversation is fascinating, and well worth a listen. Go on, now. What are you waiting for?👇