SE Radio 202: Andrew Gerrand on Go

Andrew Gerrand works on the Go programming language at Google. His conversation with Jeff begins with a history of the language, including the details behind how Go was conceived and how the open source community contributes to it. Andrew explains how Go intends to simplify problems which have been motifs as Google has scaled. The development of Go is an opportunity to fix issues that weren’t being considered when C was being designed. For example, dependencies are managed more efficiently, shortening build times. The conversation proceeds to a discussion of the unique interface model of Go, which encourages Go objects to have fewer responsibilities, allowing systems to be built with small pieces with small hierarchies. Next, the “slice” data structure is explored. A slice is a view of an array. Following this is a discussion of the concurrency model of Go, the import system, the garbage collector, and the compiler design. Andrew also explains some philosophies about syntax, development, and the standard library. Much of Go’s development is about deciding what can be left out of the language, so that it remains simplified. The conversation concludes with a discussion of the Go community and some suggested learning materials for getting started with the language.

Show Notes

Related Links

• http://golang.org/
• https://plus.google.com/+AndrewGerrand/about
• http://www.gophercon.com/
• http://tour.golang.org/#1
• http://golang.org/doc/effective_go.html

Transcript

[music intro]

Announcer:                 This is Software Engineering Radio, the podcast for professional developers on the web at SE-Radio.net.  SE Radio brings you relevant and detailed discussions of software engineering topics at least once a month.  SE Radio is brought to you by IEEE Software Magazine online at Computer.org/software.

Interviewer:                 Andrew Gerrand, welcome to Software Engineering Radio.

Andrew Gerrand:       Hello.

Interviewer:                 Could you start us off with some brief history of Go?

Andrew Gerrand:       Sure.  Well, for those of you who don’t know, my name is Andrew, and I work on the Go Programming Language, and have done for the last four years.  Go was actually started at Google, I guess, nearly six years ago, maybe even a little earlier as a sort of side project by Rob Pike, Robert Griesemer, and Ken Thompson.  They kind of hacked on it sort of on the side for a while, and then it gradually became their full time thing.  Then we added a few more people to the team over the next couple of years, and released it as an open source project in November 2009.

We actually just celebrated our fourth anniversary of that release on Sunday, so it’s now been an open source project for the last four years.  About two years after the release, we released Go 1.0.  That was actually last year in 2012 in March.  That was our sort of big table release.  Since then, we’ve done a couple of major releases.  We’re actually heading towards the second major release 1.2 in a couple of week’s time.  Yeah, we’ve seen a lot of growth, a huge amount of engagement from the open source community.

We actually have nearly 400 contributors to the project, the open source project.  We have a very active sort of non-Google development team as well.  There’s a bunch of people still working full time on Go at Google and also a lot of people outside contributing to the project too.

Interviewer:                 What were some of the objectives of the language’s founders when the project initially got started?

Andrew Gerrand:       Well, I mean there’s a joke that Go was conceived while waiting for a C++ program to compile, which is kind of half true.  Basically, Go grew from a dissatisfaction with the development environments and languages that we were using at Google.  None of them had really been designed, well, for one recently, I mean C++ and Java were more than a decade old by that stage; two in C++’s case.  None of these environments that we had were really designed to work at the scale in which we were working at Google.  Everyone knows and thinks about Google in terms of scale of users and scale of servers, but one thing that’s not talked about as often is the scale of engineering effort.

We have many, many thousands of programmers working on huge, huge code bases.  It’s largely just one big shared code base that we all sort of work on.  No language was designed to work with this kind of scale.  There were a lot of issues, I mean a lot of kind of awful workarounds that we’ve had to employ to simply function at this kind of organization scale.

So, Go was really an opportunity to think about a lot of the problems that we’ve encountered working at this scale and design a language, and also design an environment that really works.  One really good example of this is Gofmt.  So Gofmt stands for Go Format, and it’s a tool that just takes any Go Source file and freely prints it in the conical formatting style.  It means that your Go code looks the same as anybody else’s Go code.  You can easily read other people’s code bases.  You don’t have to talk about brace placement or indentation or any of those kind of nit-picky things in code reviews.  It’s all just kind of taken care of for you.

That was one of the things that was designed into the language from the start, and there are many other such examples in Go’s design that really make it easier to collaborate and to sort of write code bases of massive scale.

Interviewer:                 I imagine these things help when starting to build editors and maybe debugging tools for working with Go.

Andrew Gerrand:       The language is designed to be easy to pause and, by extension, easy to just sort of mechanically manipulate source go.  We have a growing suite of tools for actually pausing and processing and computing on Go source code.  That’s definitely one of the design goals of language is to make tooling really easy.  Yeah, we’ve seen a lot of really nice tools.  For instance, a recent tool that was just released by a couple of the Go team members is called Go Imports.  You can just feed a go program through it, and it automatically updates the package import statements in the file to add or remove the relevant imports depending on what other packages you’re using in the code.

It uses [break in audio] characteristics to figure out which other libraries you want it to be using and then adds those import statements to the file.  It really takes a lot of the friction out of working with other people’s code and just coding in general.

Interviewer:                 Especially dealing with large dependency libraries and waiting for the build times of enormous C++ projects was one of the motivations for creating the language in the first place.  That seems especially relevant.

Andrew Gerrand:       Yeah, yeah.  So that particular problem for all the people that don’t know is that to compile a C or a C++ program , any file that includes a header file needs to effectively re-pause that header file while pausing the file that includes it.  This kind of grows quadratically with your code base, and so it gets to the point where you’re re-pausing thousands and thousands of lines of header files just to include dependencies that you’ve already looked at in the compilation stages.

Go is designed so that each packaged object, so each actual compiled object admitted by the compiler contains all the information required to describe the transitive closure of its dependencies.  If you have a dependency tree that’s like A inputs B which inputs C, you can make changes to B, recompile A.  It will recompile B, but it doesn’t even need to look at C again.  It kind of prunes that dependency tree.  It means that your build system can more aggressively reuse all the build out effects.

That’s definitely one of the major design goals of Go is to not do more work than is actually necessary.  It’s kind of something that wasn’t really thought about when C was designed in the first place.  We got to sort of fix that issue in Go.

Interviewer:                 Can you describe how interfaces work in Go?

Andrew Gerrand:       Yeah, so Go has an interesting object model.  Go is certainly an object-oriented language, but if you come from, say, a Java or a C++ background, you might find the approach a little different because, for instance, Go doesn’t have classes.  It doesn’t have a notion of inheritance in the same way.  The way you structure programs in Go is typically qualified different, the way you structure them in sort of the classical object oriented languages.  The lynchpin of Go’s object model is interfaces.

The way interfaces work in Go is that you specify an interface type, which contains some method specifications, and so a classic one is the I/O Reader interface from the Standard Library which defines one method.  It’s a read method.   Anything which kind of provides a stream of bytes will typically implement this read method, but when they implement it, they don’t need to specify that they implemented it.  Simply the fact of implementing that method of that specific specification means that it implements the I/O reader.

There’s no implement declaration.  This has a really nice of effect of decoupling pieces of code.  You don’t sort of have this rigid system of decaling interface one place and then wherever you implement it, declaring it.  Instead, you can be a bit more loose about it.  You can declare interfaces in a sort of post hoc fashion, like when you discover that there are similarities between certain types and you want to use them in the same way.  You can just declare an interface there and then, and then use them as those interface types instead of having to go back and add your implements declarations back.

It’s kind of a difficult worldview to assimilate just by thinking about it.  You really need to sort of get your hands dirty and use it a bit.  But the end result of it is that Go objects tend to have fewer responsibilities and tend to be a lot smaller than objects in other languages.  We tend to build systems not by building type hierarchies, but instead by building small pieces that satisfy small interfaces and then composing them together.  I think this is a really kind of subtle, but ultimately profound shift in focus to the way a lot of people have been writing software for a long time.

For me personally, it’s been hugely beneficial.  I’ve found that the code that I write in Go is a lot simpler and a lot more reliable than the code I was writing before in other languages.

Interviewer:                 Were there initial frustrations when you were trying to design your code around such a different interface system?

Andrew Gerrand:       Well, I mean it certainly helps that I had the design of the language, the designers of the language sitting next to me at the time, but really by the time I’d gotten to Go, I’d kind of become a little bit dissatisfied with the kind of hoops that a lot of these OR environments were making me jump through.  I was using Python and JavaScript pretty heavily at the time, so everything that I was doing was fairly unconventional I guess by that stage.  It wasn’t a stretch to kind of move into Go and sort of adopt this different approach.

The main thing that I think people have trouble with coming into Go is just letting go of previous kind of techniques that they had used to structure things because there are a lot of design patents associated with object-oriented programming.  I think in Go, you’re sort of left more to just write the code that works and not worry so much about the structure of it, at least initially.

Then what happens typically when writing Go code is the structure kind of emerges over time, and you’re able to sort of codify things a bit more, define some interfaces.  It kind of becomes a more formal way to write instead of starting off with this kind of formal design.

Interviewer:                 Yeah, it almost sounds like it’s readability-oriented code rather than concurrency-oriented or object-oriented code.

Andrew Gerrand:       Certainly the language is a readability-oriented language for sure.

Interviewer:                 Can you tell me about the relationship between arrays and slices?  Why did you settle on using them as a way to have fixed and variable length arrays, and how does this relate to static typing?

Andrew Gerrand:       Yeah, so Go has arrays and slices, and arrays are kind of like Pascal arrays in that they have the size of the array as part of the type declaration.  If you declare a variable of type 5nths, then it’s just an array of five integers, and it can’t be grown; it can’t be shrunk.  There are situations where that’s useful, like if you wanted to declare a pixel of RGB, you might have an array of three bi-values.  I mean you’re not gonna need more or less, so that makes sense, but in situations where you want to work of arrays of varying lengths, we have this mechanism called slices.

A slice is basically a view on an array.  If you allocate a slide, it actually allocates an array, and then you get this slice value that points to the array.  The slice value includes the length of the view to the array, and so you can be seeing elements one through four, or you can re-slice to see fewer or more of those elements in the backing array.  To grow a slide, you either re-slice the slice to see more of the backing array, or if you are out of space in the backing array, you reallocate and copy to a new backing array.  You get a slide value that points to this new backing array.

It’s kind of a compromise between the real felicity of programming that you get from, say, Python’s lists, which have a very simple program model, some strange rough edges in places, but mostly you can just use them and don’t really think about them very much.  But Go’s slices kind of make you think a bit more about what the machine is doing.  What you get in exchange is absolute control over the allocation characteristics of your program.  You know whenever you may be allocating more memory or copying or not when working with slices.  One of the few novel things in Go as a language, and I think they work really well.

Interviewer:                 How does Go manage concurrency?

Andrew Gerrand:       Well, so concurrency is one of the big features of Go as a language.  I mean the concurrency model is based around two fundamental elements.  One of them is Go routines, which are a lightweight thread, like a grain thread that are managed by the Go runtimes.  Typically, you’ll have tens, hundreds, even thousands of Go routines multiplexed across fewer operating system threads, so the ideas is you would have pretty much as many operating system threads as there are CPUs in your machine.

As you know, threads are quite expensive and so you want to only have as many as you need for that parallelism, but then the Go code actually runs in these Goroutines, which were quite small.  I mean they start off around 4AK.  You can generally create and destroy Goroutines as often as you like without really thinking about it.  What that lets you do is write concurrent code is just a top-down sort of straightforward style, but you get the behavior of like an event-driven framework.  Your code can block, but the runtime just immediately moves any blocking code away from being executed, and then executes some code that can run.

You get that kind of really nice, high-performance concurrency that you get from, say, Node.js, but you can run across multiple threads, and you can just write your code in a normal top-down style.  You don’t need to get into callbacks upon callbacks upon callbacks.  It leads to a really comprehensible programming model, but with efficient runtime characteristics.  So that’s the Goroutines part.

Then to communicate between Goroutines, we have another primitive code channels, which are basically just like a typed pipe where you can end where you can send Go values through.  If one Goroutine does a send on a channel, and another Goroutine can do a receive from that channel, and in a fairly safe way, they can pass data back and forth, and they can also synchronize because the send and receive must happen simultaneously.

Channel is derived from cores communicating sequential processes, which is a seminal paper on concurrent programming from, I guess, the ’70s, maybe even late ’60s.  If you haven’t used them before, it’s kind of a bit of an eye-opening experience to write a concurrent code with channels because it really lets you model concurrent processes, which are typically real-world processes in a way that is just very straightforward and easy to understand.

Interviewer:                 Are they analogous to any features in other languages?

Andrew Gerrand:       Erlang has mailboxes, which are kind of similar.  You can communicate between processes in Erlang in a similar kind of way, although their execution model is quite different.  There have been some previous languages that provide these kind of features that Rob Pike worked on.  One of them is LF and another is Newsqueak.  There’s libraries that provide very similar kinds of concurrency mechanisms in other environments.  I think there are – I think live event for C might provide something similar.

None of them really work in precisely the same way as Goroutine’s channels do.  The particular implementation message in Goroutines is quite unique, I think.

Interviewer:                 You touched on this a little bit earlier, but could you talk a little more about how imports work in Go?

Andrew Gerrand:       Yeah, so basically, one of the goals of Go as a tool chain and as an environment is that you shouldn’t need to maintain make files or other kinds of metadata files to define the way to build your programs, and so the Go tool chain kind of uses a convention of all of the files that comprise a Go package.  A Go package is a unit of Go code.  It contains types and functions and variables and constants.  Go has adjacent package.  It has an HTTP package.  It has a string formatting package.  All of these packages each live in their own directly and the directory is relative to some root of a tree.

When you important that package, you actually import it by the path of that directory relative to the root.  So, all of the standard library packages have these short input parts like the stream formatting packages is just FMT.  The HTTP package is net/HTTP.  When you’re writing your own packages, you’ll typically put them inside what’s called a workspace in a directory that somehow uniquely identifies your organization.

Me, personally, for my own code, I keep things on GitHub, so my input piles typically being with GitHub.com/myusername/whatever the repository name is.  When I import my code, I’m actually importing it by its full universally-unique path.  The first major benefit of this is that from the source code, the tool, it’s called the Go tool, which you use to build and test and so on – the Go tool can resolve all of those dependencies just by looking at the source code because the import paths describe completely everything that’s needed to locate those packages.

That means that you don’t need to maintain many files.  You don’t need to maintain any kind of buildable files.  The code says everything it needs to about that.  One of the really nice benefits of this is that you can use the Go tool to fetch remote code from their repositories.  If someone imports one of my packages using the GitHub import path, I can use the Go tool and say, “Go get this package,” and it will resolve the URL from the import path, fetch that package from the repository, and then do the same thing recursively, and so resolve all of the dependencies in that way.

We get this kind of nice decentralized mechanism for fetching third-party code.  It has its limitations, like it doesn’t support any kind of versioning.  It relies on people keeping the head revision of their repository in a useful state and in a consistent state.  It’s not perfect, and there are tools for help managing versions after you fetch the packages.  But as far as identifying code and identifying packages, I think it’s a really nice design, and one that people tend to really like once they’ve gotten used to it.

It does actually force you to keep your code in a prescribed place in your file system, and some people don’t like being told to put their code in a specific place.  They have their habits and they want to keep things where they’re used to keeping them, but I think once you kind of let go of that and just adopt the same convention as everyone else, things become remarkably straightforward.

Interviewer:                 What about garbage collection?  How does the garbage collection system in Go compare to that of other languages?

Andrew Gerrand:       Well, so Go is a garbage collection language like a lot of the scripting languages like Java.  Go’s garbage collector is pretty simple.  It behaves pretty predictably.  It’s a stop-the-world garbage collector, so no user code runs while it’s collecting garbage, but it’s a very efficient stop-the-world garbage collector.  It tends to perform pretty well.  I mean it hasn’t seen all of the engineering effort that’s gone into, say, Java’s JVM garbage collector, but one distinct advantage that Go has over a lot of the other garbage collector languages is something that I mentioned before, which is control over memory allocations.

As a Go programmer, it’s very easy for you to see when garbage is being created, and the language gives you the tools you need to reuse memory where appropriate and to avoid allocations.  So, even though Go’s garbage collector isn’t as advanced as that of some other environments, you also don’t need to put as much pressure on it in Go.  You can simply avoid creating a lot of the garbage in the first place.

We have some really nice profiling tools for profiling memory allocations and seeing where the garbage is coming from.  Once you know where it comes from, the language gives you the tools that you need to reuse memory where you can and avoid those allocations to avoid putting the pressure on the GC.  It’s a very different model to, say, in Java where you have an application and you really tune the JBM’s GC to get good performance.  It’s kind of harder in Java to tune the application because there’s a lot of allocations that are just impossible to avoid.  They are baked into some of Java’s core APIs.

Interviewer:                 Is it on the roadmap at all to improve the garbage collector?  Is that sort of more like an ancillary concern and it –

Andrew Gerrand:       No, it’s absolutely on the agenda to improve it, and it has improved from release to release.  We had some dramatic speedups in 1.1.  We should see some further precision improvements in 1.2 as well as some performance improvements.  These have all been incremental upon the original design.  There are plans to implement a new GC, but I think that will require some cooperation from the compiler as well.  At the moment, we’re really talking about improving the compiler and porting the compiler from C to Go because it was originally written in C.

It makes bridge dropping a lot easier that way, but we think it’s about time that we did a Go version of the compiler.  Then once we have that at some level of maturity, I think it will be easier to approach improving the GC because GC implementations tend to be pretty closely tied to the code generation stage.  I think that’s really the first thing that needs to happen.

Interviewer:                 Let’s discuss the compilation of a Go program.  I don’t know how to approach the discussion without going too deep into the weeds, but maybe you can provide some overview?

Andrew Gerrand:       Right now the design is that there’s the compiler stage, which takes in Go source files and produces a package object file.  Package object file is not machine code.  This is the state right now.  It’s not machine code.  It’s actually a kind of intermediate assembly language, and it also –

Interviewer:                 Is this similar to all the Java bye code?

Andrew Gerrand:       Yeah, except it’s not byte code for a virtual machine.  It’s like assembly instructions for a real machine, but they’re not exactly the same as the instructions that get admitted.  They are sort of halfway there.  It’s like the compiler almost does some assembly in the compiling compilation stage, but then it leave the rest for the linker.  So the linker takes these object files and discards any unused code from the packages, and then actually translates that intermediate assembly into machine code.

The translation itself is not tremendously different from what comes in, but it is different.  This is a kind of unusual design, which we inherited from the Plan 9 C compiler, which is what the compiler tool chain is currently written in now.  This was the design that Ken Thompson built, I guess in the late ’90s, early 2000s.  Well, probably in the ’90s, yeah.  As we do more work on the compiler, we’ll probably move to a different approach, maybe a more traditional approach of actually having the compiler emit machine code rather than this kind of intermediary format.

It’s not my area of expertise, and so I’m not sure which direction we will go there, but it certainly is unusual the way it works now.  It’s a very unconventional compiler design, that’s for sure.

Interviewer:                 I have some specific questions about the operators of the language.  I know these are all in the documentation, but probably worth discussing some quick ones that are – they stick out as soon as you kind of start messing around with the language.  There’s the equals operator, which is just the assignment operator, but there’s also a colon equals, which is the short variable declaration.  How do these two differ?

Andrew Gerrand:       Well, I mean colon equals is used to declare variables.  You’re declaring them with some initial value, so the colon is kind of important because it shows that you are creating a new name in that scope.  Equals is purely for assignment, so you have some name on the left-hand side and then some value on the right-hand side.  So they are similar in function except the colon equals also declares the name.

                                    It’s hard to do it just by talking, but colon equals is actually a short-hand for the variable declaration statement, which begins with the var keyword.  You could have var X end to declare an X variable that’s an integer.  If you wanted to give it some initial value, you could say var X end equals one.  You’d give it the initial value of one, but then the shorthand for that statement is just X colon equals one.  You can drop the var keyword.  You just have the name, the colon equals, and the initial value.

Then the type of that variable is inferred from the value that you give it.  Because I’m giving it a one, it infers that this is an integer variable, and so most variable declarations in Go are done with the colon equals operator, but it’s really just like a shorthand for the more explicit variable declarations in text that we have.

Interviewer:                 Another question; why is there no ternary operator?

Andrew Gerrand:       Basically for readability.  Using the question mark colon, the ternary form that you see in C or JavaScript or something, it lets you write these really sort of terse, terse lines that can do quite a lot.  I mean you can put function calls in there and they get short-circuited based on the conditions.  As a result, you can kind of pack a lot of functionality into a very small piece of space.  That’s especially so when you are using multiple ternary operators in the one big expression.  You see people doing that.

Frankly, I think it’s pretty awful.  I mean I’ve always sort of felt that can be kind of taken to a natural extreme.  Go as a language, generally tries to discourage those kind of awfulnesses, simply by making them impossible to do.  I mean it’s still possible to write really ugly Go code, that’s for sure.  But generally when they’re being features like this that are very minor language features, just in tactical features, we tend to leave them out because it just makes the language more complex.  I mean it’s yet another thing you need to know, another thing you need to think about when reading the code.

The alternative is just to use an if statement.  If statements are very easy to read, very easy to do, understand.  It’s a lot easier to see at a glance what’s happening in an if statement; whereas, with the question mark colon, you can bury it a lot inside that small space.

Interviewer:                 This is the same motivation for not having the prefix operator I assume?  Having ++I?

Andrew Gerrand:       Yeah, so we don’t have a pre-increment.  We just have an increment, so you can say I++, but no ++I.

Interviewer:                 Right.  ________.

Andrew Gerrand:       Yeah, yeah, but the main reason we don’t have that is actually because I++ in Go is known as an expression, so you can’t actually take the value of that statement.  It’s just a statement that you must have on a line or in a full loop or something, but it’s not a value.  It doesn’t valuate to anything.  The notion of the pre-increment or post increment is irrelevant because you can’t take its value.  It doesn’t matter when you are pre-incrementing or post incrementing.  You’re just incrementing.

That decision not to make the increment an expression is actually very much in the name of readability.  If you want to increment something, and then get the value of it, you need to do exactly that.  You need to increment it, and then take the value of the variable.  Then you don’t have to think about, “Oh, did I pre-increment or post increment or what?”  Yeah, that’s another little syntactic thing that we did in the name of readability.  It makes code a little bit more verbose, but it also makes it a little bit more explicit too.

Interviewer:                 Tell me about the languages development process on a day-to-day basis.

Andrew Gerrand:       The development of the language itself has slowed considerably because after we did code 1.0, we’ve made a compatibility promise that we won’t break any code.  If you have a code that compiles with Go 1.0, it should compile with Go 1.x period.  We anticipate that the Go 1.x line will continue many years.  We know that Go version 2 is probably on the horizon somewhere, and we mark certain issues on the issue tracker as being Go 2 issues simply by being backward incompatible or sort of outside of the scope of Go 1.  But it means that there’s not a lot of really sort of major work we can do on the language without adding a lot of things.

A major point of Go’s development is that it tried to only include things that were really necessary in the design.  It was designed by a consensus, the consensus of the original core team and then later as more members were added to the team.  If anybody has any major reservations, if anybody doesn’t buy into the feature suggestion, then we just don’t do it.  That meant that a lot of features took a really long time to design.  Imagine how long it took to design slices, but at the end of the day it means that we have a language that is really small.  You can learn it really easily.  It’s easy to define and easy to implement.

Yeah, so as far as the development of the language, there’s not really a huge amount happening day-to-day.  We have made a couple of language changes in this coming release and in the previous release, but they’re really just tightening up what’s already there or I mean we’ve finally figured out how to do a certain thing that we’ve been thinking about for some time.  Most of the action is really happening on the compilers, on the runtime, and on the libraries and tools.  In particular, on the tools.

On the project, each contributor has their kind of area of expertise.  Some contributors just hack on like fixing bugs as they come in, just kind of doing small sort of cleanup sort of stuff.  Other contributors have sort of broader areas to responsibility where they’re working on improvements to the runtime or building new tools or building new libraries.  So, there’s a lot of work going on in the stuff that makes the language fun to work with.  It’s the tools that make it possible for you to really have a good time programming in Go.  That’s kind of where our focus is on a day-to-day basis right now.

Interviewer:                 What are some of those tools?  Are you talking about an IDE or a debugger?

Andrew Gerrand:       Well, so a range of different things.  I mean there’s some people who are working on static analysis tools.  Looking at some Go source code, you can ask questions like, “What is the type of this variable?  Where is it used?”  Look at a function, “Where is this called?  Does it satisfy any interfaces?”  Those kinds of things.  That will feed into support for editors and support for other development environments.  We’re not working on an IDE per se, but we’re working on a lot of the support stuff that should make that possible.

Other areas, so in Go 1.2, which is coming out soon, we include a new form of profiling.  We already had CPU profiling and memory profiling and block profiling, so being able to see where a program is blocking.  We have a nice tool for visualizing those profiles of that data that you can see a nice sort of tree of where your allocations are or where the CPU time is going.

The new sort of hotness in 1.2 is test coverage profiling.  So you can generate a profile of which code parts your test are exercising.  We have a tool that lets you view that stuff in a web browser so you can look at a kind of colorized version of your source code to see which parts are not being exercised by the test, and you can see how heavily they are being exercised as well.  That’s a really nice step towards improving code quality, just giving people the tools to see whether they’re actually testing what they think they are.  So that’s an exciting addition that we’ll see this round.

I also mentioned the Go imports tool for automatically adding or removing imports.  That saves a lot of fussing around just when hacking on code because you typically add in or remove imports all the time, and the program won’t compile unless you have the correct imports stated at the top of the file.  Not having to think about that is a huge benefit.

Interviewer:                 How fully-featured is the standard library?

Andrew Gerrand:       It’s pretty great.  A lot of people say that the standard library is probably Go’s best feature.  It has most stuff in it that I need for a lot of the things that I do.  I write web apps.  I write ___ line tools.  I mean if you want to write, say, like an open GL application or so, we don’t provide open GL in the standard library, but we do provide everything you need to write a good network server basically.  Tremendous set of networking HTTP stuff, encoding and decoding of things like XML and JSON.  There’s quite a long list of useful stuff in there that’s really just work checking out rather than me trying to rattle off a list of names.

Yeah, we kind of have what we think is a pretty nice standard library now.  It’s kind of well-rounded, but now we’re sort of focusing on development of new packages on external repositories because we sort of had this nice mechanism for importing external libraries and fetching them.  There’s very little friction between using the standard library or using any other library.

Interviewer:                 Are there some projects that company – actually companies are using Go for in production, like big companies?  Of course, Google, but I guess other companies?

 Andrew Gerrand:       Sure.  I mean I just published a blog post a few days ago where I named a few.  One of the really nice examples is CloudFlare, who are a content distribution network essentially.  You hire them to basically serve your website, and they will use their global cashing system to deliver your content really, really fast where the users are, but then it all sort of goes back to your servers eventually, and you sort of see some fraction of the overall load.  They’ve built structure in Go and recently published a blog post talking about how they’ve enjoyed using that.

Other companies that use Go include SoundCloud.  They are a big Go user.  I’ve written about it a lot.  A bunch of start-ups have started using Go, so a couple of recent examples were Poptip and Slice.  If you search for Golang Go users or something like that, you should find there’s a Wiki page, which lists a huge number of these people and some other people include like Mozilla are using Go.  Canonical, the people that make Ubuntu have written a lot of stuff in Go as well.  BBC Worldwide.

There’s a sort of growing list of people who have adopted Go for serious production work.  That’s possibly the most satisfying thing about having worked on this project is seeing all these people picking up and really enjoying using Go.

 Interviewer:                 Do you think they pick it up and they say, “Hey, well, maybe we’ll try out this one-off project and see if it works with Go,” and then they find out it happens to work really well?  Or are there certain features of the language that they say, “Oh, well, we have this project and we know it has these certain design requirements.  What languages satisfy this?”  Then they find, “Oh, it’s Go.”

Andrew Gerrand:       I mean the typical adoption process for Go is someone at the company writes some small thing or rewrites some small thing in Go just as like a proof concept.  Then they build it and they hand it to the operations people.  The operations people say, “Wow, it’s just this one static binary?  Okay, deploy that,” and then it works.  Then it’s like, “Wow, that was easy.”  That’s the story that I hear a lot.  Then it gets – the next time some larger project comes along, they say, “Hey, maybe we should be using Go for this.”  Of course, there are other people that have different approach at Splice, ____ collaboration setup.  They said that they sort of evaluated a lot of the languages that they knew and that had used.

Sort of when they were building all their infrastructure, they decided to use Go because they said it was not specifically because of the features of the language, but because of the focus on tooling and testing and all of those sort of elements that make writing large applications more management.  That’s very much a design goal of the languages, as I was saying earlier, so that’s not a surprise.

Interviewer:                 To what extent does community participation drive development of the language?

 Andrew Gerrand:       We have many, many contributors from the Open Source community.  We have a sort of Kabul of maybe like a dozen regular contributors that do a lot, a substantial amount of work on the core.  That varies from time to time depending on how busy people are and so on.  A lot of the operating system ports that we’ve seen have been done entirely by the community.  For instance, the Windows port of Go was done by a group of volunteers and coordinated by them and led by them.  It’s a really high-quality port of Go, and it’s part of the core.  It’s part of the distributions that we put out, the official distribution.

Yeah, I mean we, as a project, we are very much a real open source project.  It’s very much not just Google throwing blobs of code over the wall.  We do all our code review in public.  Everyone’s code is held to the same level of scrutiny regardless of where it comes from.  With that said, the project is very much led by a team at Google.  I mean we are the people who are paid full time to sit and work and think about Go.  Naturally, we have more time and energy to devote to leading the project.

The biggest committers are still mostly Google employers, but there are some dedicated contributors from outside Google who are really not very far behind there.

 Interviewer:                 Are there any regular conferences?

Andrew Gerrand:       There are Go user groups around the world.  There have been two small Go conferences in Tokyo over the past year, and there are these local groups that tend to meet monthly every couple of months.  I’ve visited probably more than a dozen of those around the world.  They’re really great.  I am really very happy with the friendliness and accessibility of the Go communities around the world.  But we’re actually heading towards our first official sort of large scale Go conference, which his GopherCon.  That’s happening in Denver in late April 2014.

There’s a bunch of really interesting people speaking and also myself.  That should be a lot of fun.  I think it’s a two-day thing.  Yeah, I’m really excited for that because that’s the first large-scale dedicated Go conference that’s really been organized.

Also, if you’re in Europe, we actually have a room at FOSDEM, the big open source conference in Brussels at the start of February, and so if you’re in Europe and are coming along to that, please come and check out the Go room.  We’ll be having a sort of small mini-conference inside the conference there.  I actually really love that event.  It should be fantastic.

Yeah, I’ve also spoken to other people who are considering organizing conferences elsewhere, and I think we’re really entering the stage where there’ll be a series of dedicated Go conferences in various parts of the world over the next couple of years.

Interviewer:                 Are there any books that are currently being written on the language?

 Andrew Gerrand:       Yeah.  I mean there are a bunch of Go books.  There’s a Go Wiki page that lists them. Yeah, I mean there’s been plenty of that activity happening even since day one.  I think some people started writing books the day the language was released.  Yeah, there’s plenty of content out there.  I mean when people ask me about learning it, I still recommend visiting Golang.org.  We have a lot of articles.  We have a lot of great information there that’s just growing all the time.  It’s definitely worth checking out some of the other publications that people have done.

There are also a lot of really great Go blogs, which also linked from the Wiki.  Contributors write regular blog posts and they tend to focus on from in depth stuff to highly practical basic level stuff.  I think there’s no shortage of learning materials to getting started with Go.

Interviewer:                 All right, Andrew.  Well, thank you for your overview of the language.  Really appreciate it.

Andrew Gerrand:       No worries.

Interviewer:                 Thanks again.

[music playing]

Announcer:                 Thanks for listening to SE Radio, and educational program brought to you by IEEE Software Magazine.  For more information about the podcast including other episodes, visit our website at SE-Radio.net.  To support us, you can advertise SE Radio by clicking the Digg, Reddit, Delicious, or ___ buttons on the site or by talking about us on Facebook, Twitter, or your own blog.  If you have feedback specific to an episode, please use the commenting feature on the site so that other listeners can respond to your comments as well.  This and all other episodes of SE Radio is licensed under the Creative Commons 2.5 license.  Please see the website for details.  Thanks again for your support.

[End of Audio]