Coding By Numbers - Episode 20 (Interview with Andrew Gerrand about Go Programming Language)
Craig A: In this episode of “Coding by Numbers”, Steve interviews Andrew Gerrand about the programming language “Go”.
Steve: Hi this is Steve from Refactor.
Andrew: And this is Andrew Gerrand from Google.
Steve: Thanks Andrew for joining us today. I’m here in Google Sydney and we are hopefully going to have a chat about Go Lang. I guess before we get to Go Lang I just wanted to ask you a little about yourself. How did you get to work here at Google?
Andrew: Well I have a long background in the IT industry in Australia. I originally worked for internet service providers as an application programmer. From my late teen to my early twenties. I then got into web development for a small web development company and then joined a web startup who did social media data mining. That was the last thing I did before coming here. I ended up doing quite a lot of heavier weight data processing.
Steve: Any particular languages or tools that were used?
Steve: Is that one of the things Google look for? People that have had a lot of exposure to lots of different languages. I know they’re pretty polygot with a lot of the stuff they do...is that one of the things they look for?
Andrew: I think, having a variety of language experience shows adaptability and shows that you’re interested. We don’t actually have a prerequisite that you should know a certain language. There are plenty of people that joined Google who know no C++ for example and then go to work on very C++ heavy projects. It’s understood that you can learn...
Steve: Someone did tell me that you had to know Java to work at Google.
Andrew: I don’t know any Java.
Steve: Maybe that was for me. I know a few people saying to me, “I want to get a job at Google, I got to learn Java”. Is that why you’re learning Java...it seems...it’s good that it’s not the case. I guess the ones that I hear about in Google Java and Python, seems to be...
Steve: I’ve also heard of Noop as well - I heard of. Google - possibly funded or started. It’s a JVM language - maybe I misread - but it’s a very dynamic language - it’s a bit like Groovy - taken to the nth degree - it’s written for maximum readability and testability. I thought that was a Google one but maybe not. Leading into the Go Lang stuff, how did you get into that?
Andrew: I actually joined Google specifically to work on Go. I started about 2 months after the project launched. That means I applied shortly after it launched. A good friend of mine referred me for the role. I have a huge interest in programming languages, their history, and in my spare time I use quite a range of them. I work in developer relations which is still part of engineering - I still spend a great deal of my time writing code - but I also spend a lot of time preparing presentations and writing blog posts...
Steve: Talking to developers?
Andrew: Talking to developers on forums and IRC and that sort of thing. I’ve always just been a developer - I wasn’t sure whether this role was for me. I applied and it went really well. It’s now been a really great fit. It’s been a year now.
Steve: Was there a precursor to Go? Did Go come out of something else that Google acquired or was it just something that started?
Andrew: Go originated...it was designed by Kev Thomspon, Rob Pike and Robert Griesemer and the three of them are some very senior engineers here. Rob and Ken had worked previously at Bell Labs where they developed some operating systems and other languages. Some of those previous languages were Limbo and LF. Those language have a lot in common with Go - particularly the concurrency patterns and some of the more esoteric features. Go’s pedigree comes from that Bell Labs thing - it’s also steeped in the history of Pascal and Oberon to a degree.
Steve: For those people who haven’t heard of Go before, how would you summarise it?
Andrew: Go is a C like language in its appearance. We’ve called it a systems programming language - which means that there’s only a thin layer between you and the operating system there’s a lot of control over memory and generally the code that you write is the code that’s executed by the processor. It’s thin on abstraction in that way. It has a built in concurrency model which makes very easy to write reliable concurrent software. So you don’t have to worry about locks or memory fences or all sorts tricky things that concurrent programming with a traditional threading model usually requires. It has a lot of niceties in a statically typed compiled language that are typically only found in dynamic languages. Like really nice support for closures.
Steve: Yeah I saw that.
Andrew: It’s garbage collected as well. So you don’t have to worry about freeing things and all of the complexity in having to managing your own memory.
Steve: So it’s a completely compiled language - there’s no sort of script version - no dynamic bit.
Andrew: No it doesn’t have an interpreter or a...what do they call it?
Steve: A virtual machine?
Andrew: No no like in Python...
Steve: A shell?
Andrew: It is just fully compiled - it doesn’t have virtual machine. It compiles down to the x86-64 chips and also ARM.
Steve: Can you link it to existing code?
Andrew: There’s pretty good support for linking it against C code. We have support for SWIG if you want to wrap C++ code. Depending on the libraries - it’s quite easy to build a Go wrapper to a C or C++ library.
Steve: I guess you can do it the other way too so if you wanted to expose it to a Java program you could use standard JNI type stuff as well?
Andrew: It’s kind of difficult - with C you just build an object and it has it’s symbols exposed in the object file and you can call straight into them. With Go it has a runtime so when you initialise a Go program there’s actually a bunch of stuff that happens like setting up the memory manager and the process scheduler that happens before your main function is called.
Steve: There is almost like a bootup of a virtual machine...
Andrew: Well it’s not a virtual machine it’s a runtime by necessity.
Steve: I guess it’s pretty fast because it’s not doing all the things...
Andrew: A virtual machine interprets instructions. That’s not what Go does. The runtime is simply there to service the code that’s running so if you have some - if you need to allocate some memory - you ask the runtime to allocate it for you it happens and the runtime will keep track of that and free it when it’s free.
Steve: What sort of developers do you think are coming to Go? Do you think it’s a fairly broad spectrum. I’ve noticed that some of the Linux people have been looking at it as a replacement to C++. You mention Perl before...and people do those sorts of things...is there a particular group of people?
AndreW: There’s no specific group - it’s interesting for us because we initially thought a lot of people who are writing C++ and Java code would want to come to Go. And there’s certainly been some interest from those camps. But there’s also been a bit off Stockholm Syndrome there. What we’ve actually seen some interest from the dynamic programming camps showing a lot of interest because Go is as arguably as easy to use as Python or even easier in my opinion. But you can actually squeeze a huge amount more performance out - in some instances an order of magnitude. Certainly in my previous role, doing a lot of data processing, we were doing that in Python and I had to write a lot of C modules to do certain things. When Go was announced, it was like, “If only I had this 6 months ago”.
Steve: I can imagine in some previous jobs that I was in I was using Tuxedo - and there’s quite a few big banks that were doing lots of crunching of things that were writing Tuxedo services in C and then they had Java stuff calling into the Tux stuff - the Tux stuff never really got touched. This is the stuff that we have to do fast and it’s ugly but it’s just what we do - something like Go would have a pretty good niche there. I’m seeing less and less people who know C. The people coming out of Uni now are doing Java or even PHP. I did engineering, I did C. A lot of my colleagues were doing a lot of languages like that.
Andrew: I think it’s a great shame that people aren’t doing C. It certainly teaches you about the craft of programming in general.
Steve: There’s a little bit of reoccurrence. You coming to LCA next week? People like Rusty Russell they often do some talk about C. I know there’s a lot more libraries in C that were once hard - it’s changed now - you can even do scripts in C. It sounds funny.
Andrew: It’s a lot better than when I was a kid that’s for sure.
Steve: I’ve seen a little bit of interest from my perspective from the Java community - maybe I’m reading too much into this - a lot of it might of it might be coming from what’s been happening with Oracle and Java stuff and people are thinking, “Ahh shit I need a backup here”. If the whole rug gets pulled from Java and people are starting to look at things like Go. It’s not really much of a jump from Java to something like Go. I had a look and thought that this was quite intuitive some of this stuff. I’ve got a plugin in IntelliJ - I can use it in IntelliJ - it’s my normal IDE. There might be a little bit more interest into depending on what happens.
Andrew: That’s true - I haven’t really thought of it that way. One of the really appealing things with Go, while it feels like it’s very lightweight to use - it doesn’t have the Java stuff - Integer i = new Integer(something) - it’s very lightweight and small on the page. It also requires you to - it enforces a bit of structure. Generally the things that I tend to write in Go that would usually be throwaway things end up being quite nicely structured and reuseable things in Go. I used to write just one off scripts in Python. But now I do it all in Go and I’ve got all these little useful things that I can reuse and extend. It turns out quite nicely.
Steve: Because it puts you on the right path already.
Andrew: The type system is very of hands off. It sort encourages you to - being a statically typed language you have to define things. That’s one of the great strengths of Java and and the whole C++’s style object oriented thing - it was a set of rules that people would build software. That resulted in a lot of verbosity - the way that was implemented - Go makes you structure your code but it doesn’t make it awful to work with.
Steve: Are there different styles of Go? I can’t think of the word - you know some languages give you - like Perl for instances you can write lots of styles in Perl - whereas other languages can be more rigid - they send you down a path - I do a lot of Groovy and Groovy you can write it lots of different ways - you can make it very like Java like you can make it look like Ruby...
Steve: There isn’t really a canonical way to do it. Does it exist with Go?
Andrew: In Go the feature set is so simple it actually very difficult to write in it in an unusual style. It’s not as malleable language - that’s one of its great strengths really. Of all the Go code that you might look at - it’s very difficult to tell who wrote it. Even on our core team of about 10 people - when I look at Go code - maybe there are a few telltale techniques - but generally it’s very difficult to tell who wrote what. In other software projects in other languages I’ve always been able to get an inkling...
Steve: You got that kind of signature people leave.
Andrew: But with that’s said the Go idiom is still evolving it’s only been in the public in a year. We’re still discovering new and interesting ways to use the languages. The language features are so simple and paired back - we designed it with a goal of orthogonality - any one feature exists on its own in isolation and doesn’t interact with other features in unpredictable ways. The goal is not conflating concepts. As a result you have a very plain way of doing things and it tends to be pretty obvious what you should do.
Steve: I’m quite into automated testing and tools and things like that. Does it have any particular support for automated testing...that comes with it...libraries that have been developed for that?
Andrew: There have been a large number of testing libraries developed since we launched. We did launch with gotest which is very simple - it’s not a like a big featureful testing framework. It’s basically a tool that lets you - you’ve got a Go package and it’s kind of the unit of Go code. You have a Go package and then you have test files that are part of that package and what gotest does is it actually builds the package and links in these test files and builds that as a stand alone application. And the test files have main [function] in them and it can - because it’s built into the package - you can test all of the internals of your package as well as the external interfaces. Writing unit tests and everything is very straightforward. We use this heavily throughout our standard library and for all of our tools and everything. A lot of other people use it as well.
Steve: I guess there would be plugins for continuous integration servers, IDEs and all sorts of stuff in the works.
Andrew: There’s lots of IDE support. I haven’t tended to look too deeply into the testing side of things. There’s lots of activity on the testing of Go. It’s vital for people to have good testing framework.
Steve: As far as Go’s concerned could you write a web application in Go?
Steve: I know there’s a RESTful web service example - on the web site. Could you take that? I guess as a compiled language - you can write CGI...is that’s the way you would do it?
Andrew: The Go standard library has an HTTP package in it. It’s about 4 lines to setup a HTTP server that says “Hello World”. The way I’ve written and deployed web applications in the past has been to write the Go Application to service it and I’ve deployed it behind nginx simply so I that I can use nginx to do virtual hosts and to forward multiple requests to multiple Go applications.
Steve: What about GUI bindings? What if you want to write a GUI app? Is there anything around that at the moment.
Andrew: There is a library that links against GTK. So you can write GTK apps and there’s also some STL bindings if you wanted to do a game or something like that. They’re all a bit difficult to use. But then most UI libraries are pretty difficult to use - I haven’t really gone there - other people certainly have - there’s some interesting projects around. There is no officially sanctioned UI toolkit or anything.
Steve: I guess you might see little mashup apps on the client side - where people write a GUI in one thing and they write some core engine that has to do some crunching and they might write that in Go and you can connect to that using HTTP or RPC or whatever. There seems to be a little bit of that around. Particularly with big things, where they’ve got different teams, different teams might have their own preferences with languages. Even though it’s only a year old there’s been a fair amount of work done. It’s open source. What license is it?
Andrew: It’s a BSD licence - so it’s totally free.
Steve: Do you have a lot of contributors that don’t work at Google?
Andrew: We’ve had more than 100 non-Googlers contribute. Of that 100, probably about 20 have more than 20 commits - and then there’s probably a group of 5-15 that contribute on a regular basis. I think they’re a real asset to the project. Particularly in the Windows realm - because none of us knows much about Windows. There’s been a group of 4 or 5 people that have taken it upon themselves to make Go support Windows. We’re 95% of the way - to saying it’s done. You can certainly run a lot of stuff under Windows with Go now which is really cool.
Steve: It seems pretty well put together. I was hunting for a Ubuntu package but there wasn’t one so I just built it again today. I hadn’t built it for a while. I had my other laptop with me today so I thought I’d install it before I chat to you. There was a Lucid package but for Maverick, which is the latest Ubuntu, there wasn’t one. Even on my crappy little Atom you only have to wait 5 minutes for it to build it all and everything. So it’s pretty good and it’s simple to follow. The documentation seems very good. It’s always a sign of a good project. I always ask how many people commit but I also how good the doco is. Is it just one person writing the doco, how many people are behind it.
Andrew: Everybody who contributes code also contributes documentation. We also have the emphasis of always correct documentation even if there isn’t enough of it - and there’s never enough - but it’s always of a high quality.
Steve: That’s one of the worse things when you have misleading doco. Or two pages that are the same but say contradictory things.
Andrew: We regard the quality of the documentation - it has to be the same quality as the code - no compromise - they’re both equally important.
Steve: As far as the language goes itself, is there a spec?
Steve: If someone wanted to propose a change to the language or an addition is there a path that they have to go through? Is there...not a committee...is there some sort of board there that will look at it?
Andrew: There’s no official process. The way of contributing anything to the project goes - if it’s a small contribution just code it up and send it in - and we’ll review it - we do code reviews on everything, in public. If it’s a larger change you’re encouraged to discuss it on the mailing list first and refine the design and when we arrive at a consensus then it’s time to start writing code.
In terms of language changes, a lot of people have proposed things, but it’s been an interesting year in terms of educating people about what the language is about. The team had been working on it for more than two years before it was released. When you first look at it, you have an impression of it, it’s not until you’ve written a sizable amount of Go code that you really start to understand what the real purpose of the language is - what the ethos is. When we first announced Go there was a huge influx of people suggesting, “We want to have optional parameters on functions”, or this and that. Everybody has a must have language feature. And it can become a bit exhausting saying, “No, that doesn’t really fit.”
Steve: I guess with all of these things it’s hard - it’s a big balancing act. And if someone really, really wants it they can fork it and do their own version. And things do come back into mainline - it happens in every open source project. If they fork it and no one else follows them it’s just their own thing. If they fork it and half the team goes then it’s like oh actually maybe they did have a point. By nature of the way those projects - I guess that’s the strength of that model.
Andrew: I don’t think there has been a case of anybody outside actually implementing a language change. There certainly has been changes to the language that has been motivated by discussion with the community and by the needs of the community. Whenever you have an open dialogue. It’s the baby of the core team and as far as the language proper they’re the guiding force of that.
Steve: It’s good that there’s a company like Google behind it and you know that there’s going to be a core team of people paid who are actually paid to do this. And Google don’t own it by the same token. That’s why I asked how many other people are involved. There seems to be a lot going for it. And the developers aren’t just going to disappear all of sudden. Recently with the Apache Harmony project - IBM pulled six tenths of the team away. I don’t think that anyone wants that to happen - with anything...
Andrew: As I said before, we have a very liberal licence. We also grant indefinite use of any patents that Google might own. I’m not a lawyer so I don’t know the proper language. The assurance is there if you want to use Go or want to take Go and use it in a commercial project there’s nothing that we can do or want to do to stop you from doing that.
Steve: Do they have patents on the actual technology?
Andrew: Not that I’m aware of. Google does hold a lot of patents, it’s possibly that we own some that may apply to Go. I have no idea.
Steve: That would be the same for a lot of products I guess. If people want to get involved with Go - you mentioned the mailing list and the web site - what other things can they do to engage in that community?
Andrew: So there’s the user group here in Sydney, the first one being held tonight. And another to be held in March.
Steve: And we’ve got listeners all over the place. Have you got other groups in other countries as well?
Andrew: I know that there were a group in London - I don’t know if they continued to meet. We host some or start some directory for these sorts of things. It’s still very much in its infancy. A great way to get a feel for the people that are out there. If you’re an IRC kind of person then the IRC channel is a pretty interesting place at times. I sort of hang out there generally and answer people’s question and all that. The mailing lists is reasonably high volume and may or may not be of interest - it’s a great place to read everything - it’s a great to go to if you have any questions. What I would love Steve is more Go people organising community events. I spend about a quarter of my time visiting other countries trying to spread the word. You can only do so much as a single person.
Steve: Yeah it’s hard. I do a lot of Bar Camps and things and they’re always good places to go. It doesn’t have to be yourself - it can be one of your people - if get get some lieutenants they can do presentations at Bar Camps or at meetup groups. We have a Java meetup group - a lot of it is Groovy at the moment. Later in the month where’s doing Clojure. People just say I’m kind of interested in this. I maybe even do a Go even though it’s nothing to do with Java. I might learn Go a bit more. I might do a little Go thing. I’m striking this all the time. Everyone is interested in other languages even if they don’t program in that language there’s a lot to learn. I don’t know Python but I like looking at it. It inspires you.
Andrew: It’s the best way to learn more about programming as a craft as a thing. It’s like that famous quote, “Everybody should learn Lisp, because even if you never write anything in Lisp learning it you’ll become a better programmer for learning it it.”
Steve: I’ve just started looking at Lisp. I don’t know what I thought about Lisp. I had this idea that it was a esoteric, academic, high in the sky, weird language. I just knew that it did recursion a lot and lots of parenthesis. I started learning Clojure and it suddenly clicked at how cool it is. All my friends who did Computer Sciene they all knew Lisp. I just thought it was a stupid language - why would you want to code in Lisp. Looking at it now - it’s now really cool. The fact - especially with the JVM languages - you can run it in the JVM - they play together quite nicely.
Lisp is one and the other is functional programming. I’ve been trying to learn Haskell. Not that I’m - I’m not going to do a load of functional programming - I want to get my head around that concept a bit more. I was going to ask that before with Go Lang - I guess all languages have some aspects of functional programming in them - Is there any of that in Go Lang?
Andrew: It has a really nice aspect of scope and proper support for closures. So in that sense it does lend itself to a kind of functional approach. But it’s very much a procedural, imperative language - it’s object oriented. It’s very object oriented not in the sense that you would associate with Java - not that kind of OO.
The thing is for a functional language to really succeed in a pure sense you need a lot of support from the language runtime in terms of lazy evaluation - it has to be tuned that way. And in Go you can’t do things have an assignment and use it as an expression for example. So it’s very difficult to write things in a stateless way.
Steve: I think a few languages, are not functional, but programmers are starting to see the value in using immutable types and trying to avoid side effects and those sorts of things. Not really a functional concept but those things that make your life easier. That’s what I’ve sort of learnt from doing functional programming. Not so much the lazy evaluation - that still sort of freaks me out a little bit. The writing the style that protects you against all those nasty bugs that can ruin...
Andrew: It’s a lot easier to reason about a functional language...functional code in one sense you can look at one piece of code and know what it does - and test it.
Steve: You might have to look at it for 6 hours...
Andrew: In the other sense, there are interesting games you can play as well...the one thing I like about Go is that it’s a hugely pragmatic language - it gives you the tools to do crazy things but it ultimately steers you in the direction of making things plain, simple, small and compartmentalised. It’s really great, there’s this kind of renaissance in language design and a proliferation of these languages. I know that the big ones like Python or Haskell are actually quite old now. It’s great that we have people writing Lisp on the JVM - like Clojure - it means that programmers are learning a lot more than just Java. A lot more than the C++/Java OO type thing. It’s really a limiting and narrow way of thinking of programming when it comes down to it.
Steve: I think you mentioned about the small - keeping things small and simple. That plays very much with Google’s philosophy in the way that they do a lot of things in small pieces and build it up that way. We didn’t really talk very much about the concurrency thing before - massive concurrency and scalability and things like that. Little pieces adding up to a big pile.
Andrew: That’s the key. Not over abstracting - just sort of writing what needs to be written and writing it in logical pieces. It’s a very pithy thing to say - it doesn’t really mean much - it’s just something you have to learn - to grapple with. At Google there’s a lot of monstrous code here as well - it’s not all like a candy land of beautifully designed code. It’s all well above average - it’s nice. Even within Google there’s some very devout Java people and we’re probably the largest concentration of C++ programmers in the world. They’re very into their languages.
Steve: It’s pretty interesting looking at the Google projects as a whole and just seeing the diversity. You can have something like GWT on one hand and other frameworks which are so completely the other end of the spectrum. All those things can still live in that same family - they can all co-exist in the one company. I find it fascinating there’s such a diversity there.
Steve: That’s good. I won’t stress you voice anymore. I know you’ve got a talk later on - so I’m looking forward to the meeting tonight. And catching a few...what do you call them...gophers...that would be good...and thanks for talking today.
Andrew: My pleasure.
Steve: I’m sure we’ll be seeing more of Go in the future.
Andrew: I hope so.
Craig: You’ve been listening to the “Coding by Numbers” podcast. Brought to you under the Creative Commons attribution licence. Please send any feedback or comments to email@example.com. Please subscribe to the blog or follow us on Twitter to keep up with the latest news about the show. Our intro and exit music was “Chopping Block” by Mike Beale. Thank you for listening.