The Changelog: Software Development, Open Source - The Go Programming Language from Google (Interview)

Episode Date: November 27, 2009

Rob Pike is a Principal Engineer at Google and Tech Lead for Google's Go team. Rob is also a co-creator of the Go programming language. We talked with Rob about Go — Google’s new open source programing language!

This is ChangeLog Spotlight 0.0.3. We spoke with Rob Pike of Google. He's one of the principal engineers at Google and also one of the leads behind their open source language called Go. I'm Adam Stachowiak. And I'm Winn Netherland. And yeah, so we had a really awesome interview with Rob Pike. Very candid guy. It was a super awesome interview.

Very passionate about this new language. Yeah, had a lot of good things to say about it. Which I'm not sure yet if it's revolutionary or evolutionary. I think it's attacking some problems on a couple of fronts, developer productivity being one of them. You mentioned being able to do builds faster internally at Google. And if you watch the video on golang.org, the build times for this language are incredibly fast.

The concurrency also looks to be eating into some of Erlang's promise as well. Although, Rob, in the interviews, as you'll hear, kind of downplayed any plans that they have for Go to attack any language. But you can't say concurrency without thinking Erlang. You talked about Google and infrastructure and how they want to use Go to gain productivity with building out their infrastructure softwares and stuff like that. That's kind of awesome.

For a new language or a new software project, for me, that's the proof. That's where you eat your own dog food, so to speak, as someone at Microsoft once coined. You know, as a.NET developer back in the day, that was one of the things that I always found interesting is how very little Microsoft used their.NET platform and C Sharp in building their apps. I think if Go is going to make a go of it, no pun intended, they're going to have to get some inroads at Google and start building out some of these projects internally. Yeah, absolutely.

I liked how he was talking about writing server software too, with the concurrency in mind to make them more faster too. That's a very good play. And also piggybacking off another product of theirs, which is a Google app engine. So eating their own dog food is something that Google does a lot. And it's nice to see them do that with go. Absolutely.

Cool, man. Uh, anything else? No, it's a great interview. Let's get to it. All right.

All right. So we're here with Rob Pike. He's a principal engineer at Google Inc. Everybody knows Google, and they've come up with this awesome new programming language that is getting lots of buzz. It's called Go. And Rob, why don't you introduce yourself and tell us a bit about who you are. I'm Rob Pike. I worked at Bell Labs for many years with the original guys who did Unix, worked with Dennis Ritchie, Frank Kernaghan, Ken Thompson, people like that.

And then we did a number of interesting things over the years, including the Plan 9 operating system. Ken and I did what is now known as UTF-8 for international character support. And about seven years ago, I came to Google and been working here in the infrastructure department, building new pieces of the stuff you don't see at Google, although I did do a little work on the math project early on. Can you give us kind of a brief history of Go, kind of where it came from, sort of the inspiration from it?

A couple of years ago, Ken and Robert and I were doing a lot of work in C++, which is the main systems programming language here at Google still, and became frustrated at the scale at which Google operates. There's a tremendous amount of overhead in building software because of the dependencies, the libraries, the speed of the compilers. And it seemed like the language was holding us back in terms of productivity. And so as an just sort of for purpose of discussion, we started talking about what we would do if we were trying to solve those problems linguistically. And it occurred to us there's a lot of things that have changed since C++ and Java and so on were designed in the areas of hardware, networking, multicore processing, things like that.

And so before long, we decided that there was not only sort of something to talk about, but there's actually an opportunity to design a language that would be much more nimble for software development and also be more up-to-date in regards to some of the changes in the computing landscape. But at the same time, there were obviously things that we wanted to think about differently. We didn't want to just be another version of C++ or C or any other language. So we started from the ground up and just wrote down what we wanted the goals to be and then tried to construct a language that met those goals. And then that was like two years ago. And by the middle of last year, 2008, the original three of us, Robert Griesemer,

Ken Thompson, and I were working on it full time. And then Ian Taylor came in with a GCC front end for Go. And then Russ Cox, who's a relatively newcomer to Google, joined our team towards the end of last year. And that was the sort of core team that rolled it out, although we've had a lot of other help from a lot of other people. I was going to ask you what the team size was because one of the quotes that I like most, actually Winn and I both like most about what you said when releasing Go was that we understand that a significant fraction of computers, and I like that, significant fraction of computers in the world run Windows,

and then you talk about your team size, that you have a small team and you don't have a lot of resources. What is the team size now? It kind of depends how you count, but six-ish. Some people, a couple of you aren't full-time, so call it six or seven. But it's a pretty small group. Can you maybe just enlighten us on why you said a significant fraction of computers?

Is that something you said? I don't remember that quote, but let's be clear. The majority of computers run Windows. There's actually a Windows port of Go running now. Some on the outside, the open source community has got one up and running. We hope to kind of have it officially installed in our release branch sometime very soon. It's one of the great things with open source software, things that we aren't good at doing. Other people out there are, and they can come in and contribute and really make a big difference. Absolutely.

Hi, Rob. This is Wynn. A question around some of the goals that you mentioned going into the project. How much of the actual syntax of the language was designed up front, or did you really know what you wanted when you started? We actually put syntax pretty low down at the beginning, but, of course, it rapidly becomes a point of discussion. So early on, Ken suggested that one of us just own Syntax for the beginning

and we'll not worry about that, just so we have something to talk about. And so Robert sort of owned the Syntax for a while. But then, you know, Ken and I came in with things we wanted different. And so it became more collaborative later on. But the thing about it is that it wasn't, it was designed from the beginning, like everything else. We obviously borrowed a lot of stuff, but, you know, there was nothing sacrosanct in existing syntax that we thought we had to keep. It's important when you're doing something like this that you want to think of as a replacement.

You have to thread this interesting line between making something that is really familiar to people so that they want to use it, but different enough to be interesting. If you make it look just like the other languages, then it's sort of harder to see that it's different. You are not reminded that you were in a different world. But if you make it too different, then people don't want to try it because it looks too weird.

And I think we did a reasonable job there of making it feel like it belongs in the C family, but not actually be just like C. So when you're writing Go code, you're aware that you're writing Go code, right? Whereas in the middle of a Java, JavaScript, or C++ program, it's kind of hard to tell which language you're in. I think we did a nice job there

of getting some of the details different, but for good reason. You know, that's an interesting point. I remember when c sharp came out microsoft's language you know the comparisons to java were were pretty rampant i think for for good cause what other languages influenced go i don't know that any languages exactly influenced it so much as the languages that we've worked in inspired how we think about programming. So some of the languages that the group of us have worked on before,

obviously Ken was involved in actually D, the language that predated C, but he also had a big hand in helping shape C. I've done work in several languages before, mostly around concurrency, languages called N Newsqueak and Limbo. And Robert has worked a lot in Smalltalk, and he did a big part of the Hotspot code generator for Java. And so he also did a lot of his training, you know, university work in the languages out of the Itihau and Zurich, languages like Oberon. So it was a pretty interesting mix of stuff, and you can see bits of those languages inside Go,

but it would be wrong to say that they were exactly inspirations. They more sort of informed us how things would work if we used them a certain way. What types of software projects do you see being the sweet spot for a language like this? That's a tricky question. We definitely started the project because we wanted to write Google infrastructure in a language that was more productive. And so we definitely have in mind things like web servers and web front ends and storage systems and things like that. But in developing the language and bringing some of the details of the type system and stuff like that. But in developing the language and bringing some of the details of the type system

and stuff like that in, we found that it's actually pretty nice for a lot of other things too. And text processing, it's almost a nice scripting language. You can see it doing some things Python does. And I really don't know what the sweet spot is going to be. I think people will find that as they use it more and more.

At this point, I think not enough people have really played with it in depth to know where it really belongs. We're certainly going to try to use it internally to build some infrastructure, but a lot of other pieces of stuff look like they're really good fits for Google using Go. An example is that the concurrency model in the language makes it really easy to use what we call Go routines to do client handling. That makes it possible to write servers in a much more easy to understand and flexible way than the kind of event-driven or callback-driven mechanism

that tends to get used. People are already discovering there are things they want to write where Go is actually a really good candidate language, even though it's not as mature as we hope it will be. Do you see that being a play for Erlang-type applications? I think it's – well, I don't like the word play. It sounds like we're trying to sort of, you know, supplant something. We're really not. We're just offering an alternative. But yes, I think

the kind of things that Erlang gets used for now, Go is an interesting option. I don't think it's mature enough yet, but it will get there and we're certainly trying to make it mature. Are there any tools right now that you guys are building, that Google's building using Go? We've got a few things internally, but nothing that's facing user traffic yet, with one notable exception, which is the golang.org website is entirely

a Go program. There's actually, it runs on App Engine with a Python front end that acts as a cache, just because that's the easiest way to roll it out. But all the content comes directly out of a web server running on our internal infrastructure. Would you say the App Engine is a natural place to host but all the content comes directly out of a web server running on our internal infrastructure. All written in Go.

Would you see the App Engine as a natural place to host Go applications one day? Absolutely. We want to see that happen. We're trying to make it happen. But there's a couple of steps we still have to get through first. But I think it would be a really interesting alternative language for App Engine stuff. We'll see. I found the notion of Go routines fascinating. Is there any plans for a package manager,

or how would that work, something like a RubyGems for Go? I'm sorry, I'm not really an expert on that stuff, so I just don't know. I'd be lying to you if I understood it. As far as distributing things at the moment, we're trying to keep everything in a Mercuro repository, which we maintain because we don't really want to deal with packages and so on until things are a little more mature and stable.

But I suspect sometime next year there will be sensible binary downloadable packages, but exactly what they're going to look like, who knows at this point. Is that a reasonable answer? Sure, sure. And I understand it's early in the lifecycle here. It was a natural fit, I would think, to

start sharing code with other Go programmers and want to know what kind of plans you had on the roadmap for that. We don't have any plans. We'll evolve them as we need them. You mentioned in there, you mentioned Mercurial as the source code manager. Any reason why Mercurial over Git? Yeah, a very simple reason. Code.google.com doesn't support Git. So we had a choice of Subversion or Mercurial. The advantage of Mercurial is that it was easy to write a plug-in to implement our code review process, which we wanted to take out.

Gilvan Rossum designed a really nice code review system we use internally, and he's got this sort of rewrite of it for external use on code.google.com called ReadFell. And all of the Go source code that goes into the repository goes through that process, and it's a really nice tool. And that was the reason we went with Mercurial. We could make that work with Mercurial. Awesome.

So what are the next steps? What's on the immediate roadmap for Go? We have two things we want to do in a big scale. We have to build up the libraries and the implementation both. The libraries are spotty in places just because we haven't written everything we need, and there's lots of stuff to do. And then internally, there's a lot of runtime stuff, particularly around things like memory management, garbage collection, and so on,

that really needs a redo. Now that we have the language designed and not that it's all locked down, things are still going to change, but we have a pretty deep idea about how a lot of it works. It's time to go back and revisit some of the concurrency primitives and the garbage collection, things like that, and reimplement them with more performance in mind now that we understand the semantics.

Because until we do that, it won't really be competitive as a systems language. But we think the language is intrinsically capable of being pretty efficient. Some of the benchmarks we have that rely on just raw computation seem to bring it in the sort of C regime for regular C as opposed to hyper-optimized pragmatism C. And then if we get the runtime up another couple of notches, it should be almost as nice to use as, say, Python or Ruby or something like that. But with performance, it's much closer to C or C++.

And that's really where we want to get to. As far as language design goes, there's a lot of things we've talked about. We're very careful about features because one of the things about Go that really makes it work, I think, is that language was designed as a set of orthogonal features

so that when you put two things together, you know what's going to happen. And it's very important that as we add new features, things like we're talking about union types and things like that, that they work with the existing pieces perfectly so that there's no surprises in how things interact. That's a lesson we've learned from some of the other languages that have grown organically. They tend to have features that don't quite intersect at right angles, and you get weird interactions with things. It's hard to explain what's going on. We want to avoid that very much.

One of the things I found amusing from the FAQ was the reason for the name Go, that Ogle would be a good name for a Go debugger. Yeah, that's just a little joke, but there is, in fact, the beginnings of a debugger, and it is called Ogle, so there you go. Awesome. Can't wait to see that.

Do we anticipate Microsoft coming out with another language called NoGo or No or something like that? Who knows what Microsoft wants to do? I don't think we're on their radar, actually. I think they're happy with their common language runtime. I would like to see someone try to build a Go backend for the CLR. I don't know how some of the type stuff is kind of slippery. For instance, it's quite difficult to implement Go's interface model using a JVM. You might have to add a bytecode to deal with some of the type stuff.

So for some of these existing systems, it's not that obvious how Go would run with them, but that doesn't matter for us directly because Go is a compiled language. We go right down to the ROM at all. But for some environments, maybe you want to have something a little more VM-like. So for developers looking to kind of join the Go community after they go out to golang.org and get up to speed, where's the best place to get involved? That's the place to do it. There's a mailing list called GoNuts.

I think it's called golang-nuts is the full name on Google Groups. There are links at golang.org to that. Join the discussion. Try it out. My experience has been in the last couple of weeks, it's been a little bit crazy watching a response, which I've got to tell you was much bigger than we expected, but that's gratifying. The people who have actually tried to use it to write programs seem to like it a lot. There's a lot of complainers out there.

There always are. But they seem to be the people who haven't really sat down and tried it. And I think that comes back to the point I was making about how the thing is designed. It doesn't look very radical. But when you use it, you see it actually has a very different take on how things behave. And you can't really see that until you've really tried the language out. And some of the bloggers I've noticed have picked up on it. They sat down to use it, and they think, oh, this is kind of weird.

Why are they doing that? And then they use it for a while, and they say, hey, that's kind of neat. So I think people who use it will like it. I think there's a lot of room to grow performance-wise, get the libraries up to date. And it's still very early, and it's essentially an experiment. We want to make sure that that experiment succeeds, but we've got a long way to go before

it's something you would want to commit your company to or anything like that. It's a Skunkworks project and it's not even an official Google-branded product. We're releasing it as a pure open-source thing. I'm actually kind of proud that it went out on day one as an open-source project completely ready to go. I think that's a really nice way to give something back

to the community. Right. And we see Google Chrome OS come out. Now we see Chromium OS. That started out as a closed source. Now it's open source. Is that what you mean by coming out the gate? I like to think that, you know, this is because it is really an experiment for everybody to play with, there's really no reason to keep it behind closed doors any longer than you want to. I mean, we could have kept it inside for another couple of years and worked on it even more, but it's way more interesting for everybody to get it out there and make good use of it. Absolutely, yeah. Well, once you get the community involved, you start to see all brand new ways of it being used,

and you start to see a lot more growth and innovation happening once you start getting the collective involved. We see that with collective buying, everything from social networks, the way they work, to collective buying, to crowdsourcing design, or crowdsourcing code development. Lots of stuff happening, and I said there's a couple of ports that have been done to FreeBSD and to Windows,

and some library work coming in. We're getting a lot of interesting contributions. So I think it's starting couple of ports that have been done to FreeBSD and to Windows and some library work coming in. We're getting a lot of interesting contributions. I think it's starting to take off. It's pretty exciting. Awesome. Well, I think the only last question I wanted to probably ping at you real quick is besides Go and some of the things going on with Google and open source projects involving Google,

what's on your radar in terms of open source? At the moment, I'm just so overwhelmed by this. I don't have anything else on my radar screen at all. One of the things I want to do in the next few months is get more Google internal development on go, and that's going to be an interesting project, but that's not really open source. On the outside, I want to see more people use it, get more real production stuff running in the net. There's already a few websites that are based on it, which is kind of fun.

And I think the community will let us know where it's going, and that's really what we want to see. Very cool. Well, Rob, thanks a lot for coming on the show. Really appreciate it. We had fun talking to you and can't wait to see what happens with Go. Great. Thank you very much for having me. Enjoyed it.

Thank you very much for having me. Enjoyed it. Thank you. Thank you for listening to this edition of The Change Log. Be sure to tune in weekly for what's fresh and new in open source. Also, visit thechangelog.com to follow along, subscribe to the feed, and more. Thank you for listening