The Changelog: Software Development, Open Source - The State of Go in 2015 (Interview)

Episode Date: March 25, 2015

Andrew Gerrand joined the show to talk about the state of Go in 2015, how Go compares to other concurrent languages, why people choose Go over other languages, the C to Go toolchain conversion, and what's coming in version 1.5 and 1.6 of Go.

Welcome back, everyone. This is the Change Log. I'm your host, Adam Stachowiak. This is episode 148. And on today's show, we're joined by Andrew Duran. Andrew works on the Go programming language at Google. You might remember him from back in episode 100. This is Rob Pike.

This show, we're talking about the state of Go in 2015. Great conversation today with Andrew. We also had some awesome sponsors for the show, CodeShip, TopTal, and DigitalOcean. We'll tell you a bit more about TopTal and DigitalOcean later in the show, but our friends at CodeShip released a brand-new feature called Parallel CI. We're super excited about it. They're super excited about it. They're super excited about it.

And you should be too because now you can deploy your code to production 10 times faster. If you want faster tests, you have to run your builds in Parallel. With Parallel CI, you can now split up your test commands into up to 10 test pipelines.

This lets you run your code and your test suite in parallel and drastically reduce the time it takes to run your code and your test suite in parallel and drastically reduce the time it takes to run your code. They integrate with GitHub and Bitbucket and you can deploy to cloud services like Roku, AWS, and many more. Get started today by checking out their free plan. It includes 100 builds a month and five private projects. Or you can use our offer code. It's the changelogpodcast to get 20% discount on any plenty of shoes for three months.

Again, that code is the change law podcast head to code ship.com slash the change law to get started. And now onto the show. All right, everybody. We're back. We got Andrew Duran on this on the call today.

Andrew, how are you? Hey, good. Great. Andrew, we're, we're flying solo today. We have

no Jared with us, so for long-time listeners of the show, you're going to miss Jared on the show. I hope you miss him, but not so badly that you don't like the show. Right? And I think the last time you were on the show, Jared wasn't even a co-host on the show yet. Andrew

was co-hosting with me, and I think he did episode 100 with you and Rob totally solo. So that's kind of cool too. Almost 50 shows ago. Wow. Not to believe.

I'm sure you're excited to be back though, right? Yeah, it's great. One of your favorite podcasts, I'm sure. I don't even know how to respond to that. Of course it is. That's how you respond. Oh, yeah, of course. Great.

I love it. Right. Okay, guys. I don't listen to a lot of podcasts. So for the listeners, if you're not familiar with who Andrew is, Andrew works on the Go programming language, a.k.a. Golang. Or, you know, that's kind of how you say it, I guess. Yeah, we just call it Go.

Go? Okay. Although apparently I can't say it correctly because of my accent. Maybe you should cut that out. No, go ahead. Say it one more time, nice and clear. Well, I say Go. Go. Well, you've got the awesome australian accent right so yeah awesome slash ridiculous uh i think it's awesome i mean i'm glad i kind of wish i had

that accent sometimes not all the time but man there there are some really cool australian accents out there that i mean y'all have the same accent to a degree but there are just some that sound better than others. So I'm a fan. Sometimes people in Australia think that I'm not Australian because I guess I spend a lot of time speaking to international audiences. And so I sort of round out my accent a little bit. But then it just makes me sound weird to everyone. So I don't know whether I'm seeing the benefits or not.

Well, you hail from, as we said, Australia. So you work at Google Sydney. And in the pre-call, I asked you a question that we had to pull into the show because I just thought your answer was pretty neat. But just for some background, what's different about Google Sydney than plain old Google? Google Sydney is definitely part of plain old Google. It's not a separate entity or anything like that. I mean, Google has tens or probably hundreds of offices around the world, probably like tens of large engineering offices.

And Google Sydney is one of the largest Google offices outside of Mountain View, the headquarters. But Google Sydney is kind of cool because it has a long history at Google. It's one of the first overseas engineering offices. And the story behind it is kind of interesting because the team that built the product that became Google Maps, so it was a company outside of Google that built it,

and they sold the technology to Google. And they also joined Google when they sold it. And so the people who built that original, basically like a Maps prototype, they became the first employees of Google Sydney, more or less. And there's a lot more detail in there, but that's basically the story. And so I think Maps is one of the major ways

in which Google has affected the world. Search is the first one. And then I would say, for me personally, Maps was the second big revelation. I've only been to Google for five years, so it has nothing to do with me. But it was one of the things that really impressed me about Google. And so I think it's cool that Google Sydney was sort of the birthplace of that.

You said you've been with Google five years now. So that's almost the age of Go. Yeah, well, I joined Google and the Go team a couple of weeks after, sorry, a couple of months after Go was released. What was that? What month was that? That was, I started at the start of February 2010. Okay. And Go was released in November 2009. That's so crazy because that is our birthday.

The Changelog was born November 19th, 2009. Right. Well, Go was November 10th, so we're a little bit older. Slightly older. That's funny because our third show was with Rob Byke. Oh, really? Yeah, our third show. Wow.

Yeah, 3-148. We covered Ghost super early. And when we say fresh and new and open source, we mean it. So episode number three, the channel.com slash three is a show you listen to. This is way back in the day, too. So if you want to get nostalgic listeners of this show, longtime fans of this show, go back and listen to that show and hear the difference in audio quality. This is the version of a developer going back and looking at code that's five years old. Not advisable.

Great conversation, but our production value is a lot different then. Wynn and I, Wynn Netherland now, he hacks on the GitHub API, but we were so fresh and green with podcasting, I think, that it was a different landscape. This was before it was cool, too. It was a different world. Podcasting is cool now, didn't you hear?

I'm not even kidding. I'm not even kidding. Yeah, actually, I must admit I have been thinking about recording my own podcast. See? Yeah. I think it would be cool to actually have a podcast where I interview people in the Go community and talk to them about what they're doing and what they think and so on. I don't disagree. I don't disagree.

I think you should do it, and I'm going to encourage you to do it. Yeah. In fact, we may be able to help you. Oh, we can talk about that later. Yeah, let's definitely earmark that conversation. So a year and a half ago, so we've been talking about the past a little bit in preparation for talking about today and the future. But a year and a half ago, episode 100, you were on the show with Rob. You guys talked deeply about the history and the details of the language, simplicity, concurrency, productivity.

It's not just a systems language. It's sort of just given a rough summary of some of the things that I pulled out there. But recently in February, you gave a talk at – is it FOSDEM or is it FOSDEM? I guess it's, if you're pronouncing it in Australian accent, it's FOSDEM. Because we pronounce all S's like Z's. But it's probably FOSDEM. Okay, I'm going to go with either. I don't know.

FOSDEM. I'll say FOSDEM. Because it seems like, well, we had the same conundrum with OSCON. Is it OSCON or is it OSCON? See? You probably say OSCON, right? I say OSCON.

Now, I would always say OSCON as well, but even Jared, myself, and who was it that was on the show that time? Someone from Facebook. I can't remember her name right now. It's upsetting me. But anyways, we couldn't figure it out either.

So you talked about the state of go at FOSDEM. It's basically the OSCON, speaking of OSCON, the OSCON of Europe, basically, right? That's what that conference basically is. Yeah, I mean, I actually, I think, not to say anything bad about OSCON. I quite like OSCON as a conference. but FOSDEM is almost something else. It's an amazing community-driven conference that's totally non-commercial. It's hosted at a university. main track talks which were curated by the conference organizers um but they had these things known as dev rooms where people in the community could register interest in running a dev room and basically that means that they would get a day and a room and some equipment and they could run their own thing there and like it was they called dev rooms because originally it was

like you know all the people working on like open step for instance would get together and they would talk about all right well what are we going to work on over the next year and maybe they'd even get some hacking done or some like api design or something like that and then gradually the emphasis has really shifted over to these dev rooms and they've now become like curated mini conferences inside the greater conference and so all the action actually happens at these dev rooms and the dev rooms yeah yeah now become like curated mini conferences inside the greater conference. And so all the action actually happens at these dev rooms. And the dev rooms. Yeah.

Yeah. And so like I, the last couple of years I've organized the go dev room and curated, you know, speakers from the go community to talk about go stuff. And so it's, it's, it's really awesome in that it's, it's just totally grassroots,

totally community driven. It's very, very much a free conference. It's free awesome in that it's just totally grassroots, totally community-driven. It's very much a free conference. It's free to attend. And, you know, it's very sort of democratic in a way. And so I feel like more than any other conference I've been involved with, F and I am going to link up all of the playlists that you linked out on Twitter. I think it was a couple weeks back or something like that, maybe a month back or something like that. So all of the Dev Rim talk at FOSDEM is going to be in our weekly email this saturday so um we're recording this on a wednesday and actually the day uh i don't usually timestamp these but march 18th this show won't go live until

the 27th of march just so you know and everybody else listening so it's the 27th or after if you're a member you're listening live potentially but today today's March 28th. That's when we're recording this. So we'll actually link that up this Saturday, which will be before this. I blew somebody's mind away whenever I was like, we're recording this in the future and you're listening to this in the past because it's kind of

how the podcast is, right? We record it in the past and you listen in the future. It's kind of all jacked up. Unless you're actually listening live. But anyways, so the state of Go, FOSDEM, you know, you mentioned you've been running that room for the last couple of years. What are some of the things you've seen happen over the last couple of years running that room around the Go community? Well, you know, with regard to the room specifically, I mean, it's just, we've just seen some

a lot of great talks from people, particularly at the end of the day, we tend to do lightning talks and people can sign up for the lightning talks on the day. And, you know, it's, it's really, it's really fun to see people just pull out like their fun little projects that they've been hacking on, you know, things that they would never really bother submitting like a a full-scale conference talk. But for instance, at the conference this year, we saw a guy presented his... He wrote a backup system in Go.

And he was fairly serious about it. And so it was actually quite a nice, solid product that he produced. Another guy showed this really bizarre thing called a Phantoscope, I think, which is like an old-school way of producing moving images by sort of – it's probably too difficult for me to explain. You'll have to Google it. You need a visual. It was a visual thing.

It was kind of wild. It was pretty unexpected. So do you have the past years on video then? Yeah, yeah. So the playlist includes the lightning talks. And all of the lightning talks are in the YouTube video description. We have the timestamps of when each of the talks begin. So you can skip through them.

Awesome. So definitely check them out. Actually, last year there was a great one from one of our contributors, a guy called Remy Udomfang, who's a French guy who's been off and on contributing to the compiler and runtime. Very smart guy. But he just, I kind of like, me and Brad pushed him throughout the day to like, you should give a talk, Remy, come on. And he was pretty shy, but he ended up writing this talk,

like why you should contribute to Go. And it was a really nice little talk about why it's nice to work on the Go project, which resonated with me at least. You know, I got sort of an off question, I guess, before we actually dig into the state of Go. But we just had a conversation about Phoenix and Elixir. Phoenix Web Framework and Elixir built on top of the Erlang VM. And one of the pieces of that conversation that stuck out to me was the concurrency. And it talked about how Erlang had been doing concurrency for years. They solved this problem 20 years ago.

And I hear a lot and I've heard a lot over the last year and a half since the last time I've been on the show about Go and concurrency in that direction. What is it about Go in comparison to say like Java which you're planning to supplant and languages like Erlang or even Elixir? How does Go compete with or what is the landscape like in comparison to those other languages that are concurrent as well there's a there's a lot in that question so it's quite a deep topic but i think what

erlang gives you an elixir as well is this environment in which to build distributed concurrent systems or maybe concurrent systems and you know it's very much baked into every part of working with those languages is you think about concurrency and message passing and so on. At least that's my understanding. I don't have a lot of experience with them. Yeah, that's how I take it as well. Yeah, but with Go, concurrency is always there. You can always use it, use the concurrency features

when you want to do something that involves concurrency. So we provide really nice tools for modeling concurrent processes, but it's not uncommon to write Go programs that use no concurrency at all. You don't have to use those tools or think in that mindset if it's not appropriate for what you're doing. If you're doing. If you're writing a tool to open a text file process a whole bunch of lines and compute something

and print the output, concurrency is not really appropriate. It's an inherently serial process. So you don't need the tools if they're not there, if they're not necessary. But there's that aspect. There's also the aspect that Go is still very much an imperative programming language. It's not a functional programming language. So it's a lot more familiar to most programmers.

And the model in which you're running Go programs is also familiar. You write a Go program that runs as a process. And then that process may talk to other processes, but there's no sort of infrastructure to manage those processes or pass messages between them or anything. None of that's baked into the language, unlike Erlang,

which gives you that entire framework for doing that. And so with Go, it's very much like you program with concurrency, assuming that you're operating inside a single process. And so you know if you send a message across the channel and it's received by some other Go routine in the process, you know if you're still executing, then that other Go routine must still be executing.

If the program hasn't crashed, then the program is still running. And so it's actually, even though there are parallels, you can draw between the way you write code in Erlang and the way you might write code in Go, you can't really compare them. They're actually very, very different approaches. I see. When I was on that call, I was thinking,

Angel's going to be on the show. I should talk to him about this because I don't write Erlang code. I don't – we're actually just tinkering with some Elixir stuff as we speak, but – and I've never written much in Go besides maybe some – a hello world. So I'm actually not even a great candidate for asking you the deeper questions, but it always made me wonder about the concurrency issues about that topic there, whether or not, you know, why someone would choose

or what kind of application someone's building that are drastically different that makes someone choose Elixir, Erlang, or Go. You know, what kind of choices does that programmer go through when they're actually building the application? What makes them choose the language? For example, with Ruby, a lot of the times you are building systems

or for the web, and you're choosing it for the elegance and the readability of the language and the developer joy of the language and some of those things that come with it. So what are the reasons why someone chooses go over one of these other languages that have competing feature sets right well i mean i the reasons why like i choose go and i think other people choose go are a lot to do with that sort of programmer joy thing um you know very much uh the overriding sentiment amongst go users is that go just kind of gets out of your joy thing um you know very much uh the overriding sentiment amongst go users is that go just kind of gets out of your way and lets you write code um it doesn't really give you the

tools to sort of over abstract things and so you tend to just like write the simple code that does the thing you want to do now as opposed to you know dreaming about how you might want to abstract this so you can make it more useful later, which is a wonderful, very interesting trap that programmers fall into all the time. So it kind of resists over-engineering a lot, but I think the features that it does provide are very well considered

and just tend to work in predictable ways so you don't really spend time like looking at the language spec or you know wondering if what you wrote is going to do what you think it does um once you know the language um which doesn't take very long you you really you just know it and you can just use it yeah and that was one of the things i pulled out from to call back to episode 100 when you and Rob were on was that when they were first writing, I remember Rob saying that he had remembered the entire

language and he wanted to build a language that he can keep in his memory, his current memory and not have to go back and forth to docs. It's not just at the language level. I was talking to Rob about this recently.

Recently, we've just converted the whole, and I guess we're heading into talking about this. We just converted the tool chain from C to Go. It was originally written in C. Now it's written in Go. There have been some criticisms

from people in the programming community saying, you know, the Go people, they should have just used LLVM or they should have built this on GCC or something like that. And the counter-argument to that is we've just been able to do some really very interesting work on the compiler

and the tool chain, and there's a lot more to come and part of the reason that that is possible is because it's it's possible for people on the team to keep the entire tool chain in their head and that is just not possible with some of these larger compiler projects like Like they're so huge, you know, they're massive engineering projects that do a tremendous amount of work. And that is really antithetical to the entire design philosophy of Go and all of the Go tools.

And I think one way to be spectacularly productive is to keep things small enough so that you can know the entire thing. So yeah, I think that's really just a core tenet of what we're about. And it's been a source of great success for us so far. That's certainly a great transition into the larger talk we'll have here in just a second. So Andrew, I didn't mention this before the call, but I'm going to take a quick break here and do a spot for one of our sponsors for this show. So we'll be back in just a second. We'll talk to Andrew about the state of go, his talk at Fosdam, and kind of dive into what we're talking about here, transition to Git, and so much more.

So we'll be back in just a second. Top Tile is the best place to work as a freelance software developer. If you're freelancing right now. As a software developer. And you're looking for a way to work with top clients. On projects that are interesting. Challenging. And using the technologies you want to use. TopTal might just be the place for you. Working as a freelance software developer with TopTal. Means that your days of searching for long term high quality work.

And getting paid what you're worth. Will be over. Let's face it. You're an awesome developer. And you deserve to be competent like Juan. Joining TopTal means you'll have the opportunity to travel the world as an elite engineer. On top of that, TopTal can help provide the software, hardware,

and support you need to work effectively no matter where you are in the world. Head to TopTal.com slash developers. That's T-O-P-T-A-L.com slash developers to learn more and tell them the change law sent you. All right, we're back. The state of go in 2015. Andrew, you've kind of teed it off before we took that break there. So, sorry, I threw you a curveball there too, by the way. It wasn't letting you know I was going to do that.

But anyways, so C to go. You know, when I read this in your talk, when I – now listening to your talk and reading your talk was two different things. But whenever I heard you talk about the prep work for the C2Go tool chain conversion, I was like, wow, okay. So they're writing and having gone back and listened to episode 100 just to kind of prep for this call too to kind of get back into grips with what you and Rob talked about with Andrew on the show before I was thinking man Rob's gonna be excited because the the C and C++ programs he had written 20 years ago cannot be ported to Go and that's not the case so let's talk about the C to Go toolchain conversion and what you actually mean by that. Right so you know originally when Go was first being developed uh ken thompson wrote the original compiler in c um which he was leveraging a lot of the work of and the design of the plan

9c compiler which uh you know it's just a standalone c linker and assembler. And it's nicely cross-platform, or at least it was in its old form. So that was just kind of an expedient way to get started, and it was a system that they already knew, so they built it in C. And then we've just kind of taken that and kept working on it for five years. And it got to the point where

we have more and more people working on it. And it really wasn't an accessible code base at all. I mean, like, Ken is a tremendous programmer, but his code is unlike anyone else's code. And I don't mean that in like a negative way. It's not me being sort of snide about it. It's just his mind actually works in a way that is very unusual. And so, you know, first of all, there's the can factor. And then there is, you know, the fact that the code had just kind of grown over a long period of time. And, you know,

originally, it suited us really well, because we were developing a new language and making changes to the language. And if we'd written the original compiler in Go, then we would have constantly had to sort of re-bootstrap and update the Go compiler written in Go as we changed the Go language. And that would have been... It would have added a lot of friction to making any kinds of language changes,

whereas, you know, having it in C, you know, C is the language we understand, hasn't changed for a very long time. This is plain C, not C++. You know, we could make changes freely to the language without having to refactor the tool chain at the same time. And so that suited us really well at that stage of the project. Now we have so many more people working on the tool chain. It's about time that we use the nice stable language that we spent all this time developing. And so, you know, we made the decision to convert the toolchain into Go. So not to rewrite, like if we rewrote, we felt like it would just set us back.

You know, you end up in second system syndrome. You end up recreating the same bugs that you've already fixed. We were somewhat hampered by not having a really thorough set of unit tests. Like we have a lot of integration tests, but as a whole, the compiler was more or less a black box. We had these tests where we put stuff in and saw what came out. So we decided that what we would do is convert the tool chain from C to Go. That doesn't mean like by hand.

It means we actually, well, Russ Cox wrote a program to convert the C sources into Go. And it meant that work could continue on the C compiler while the translator was being developed. And when it was time to cut it over, Russ could run the translator and check in all the Go toolchain, the toolchain written in Go,

and then later delete the toolchain written in C. And so this has actually been a really huge engineering project in a way. But the end result is, like, we now today have the Go compiler written in Go. At the moment, it's slightly slower

than the C version because some things that you do in C are much more efficient in C than they are in Go. At the moment, it's slightly slower than the C version because some things that you do in C are much more efficient in C than they are in Go and vice versa. And so we're sort of gradually... Now we have a very ugly Go program, right? Because it's all written in a C style. And so

work is now being done to tidy that up and make it look more like a nice Go program. Can you talk about that a little bit, where you go from C to Go ugly and then Go pretty? Well, for instance, the whole thing when you converted it was just one big package because C just has one namespace that everyone shares, whereas Go has these individual packages that each have their own namespace. And so when you convert C to Go, you just end up with this one big package with hundreds or even thousands of names inside it.

And that's very ugly Go. You would never do that if you were writing Go from scratch. And all of the function names are not really very idiomatic, all the types and so on. In the original Go compiler, there was one big C struct called node that represented a node in the AST or a node in the generated code.

And it was kind of like a multipurpose type that was used in different parts of the compiler. And so it was this huge data structure which included unions, which is where you can have a struct that has the same kind of size, but it can be used in different ways where fields can share the same piece of memory. So you can only use one or the other of those fields simultaneously. And that's not a feature that Go has at all. And so when we converted that node type into Go,

we had to explode out all of those unions, and suddenly the nodes were so much bigger. And an interesting issue came up recently where, I apologize if I'm getting a little bit wrong, I just heard it in passing, but in C, you declare your variables up front at the top of your function and then reuse them and so on throughout the function. And there were all these functions in the C version of the compiler

that were very long that had lots and lots of variables. And the number of variables being used in there was something that you would never see in Go. And so the Go compiler, when it was doing registerization for the function to see which of those variables should be kept in CPU registers for efficiency, it just saw, oh my God,

there's like 100 variables in this function. I'm not going to registerize anything. And so these kind of core parts of the compiler wouldn't use registers to do any of the work. And so they just became way slower. Whereas the C compiler could handle it fine because it was designed to cope with that. And so it's just interesting. I think we're going to see a talk probably at Go4Con this year that talks about a lot of this stuff. So that should be

a pretty interesting talk. Yeah. And so Russ got started on this. I see the abstract that he written for the, the overhaul is a dated December, 2013. So this is, yeah,

like 18 months ago, almost. It's a while. So this is an undertaking for sure. Oh yeah. Yeah. And you know, I think Russ is looking forward to the compiler being more accessible to more people so that, you know, the responsibility is on his shoulders so much anymore.

Yeah. You know, we have some great people that we've hired at Google to work on the compiler recently and the runtime, like Garbage Collector and so on. And Russ has really been spinning up that team of people. And also there are people in the community who are just really interested in working on this stuff and doing great work. And so far they've been doing great work despite the fact that it's this really inaccessible C code base. Now that we have this Go code base that's only going to get nicer, I'm excited to see what people will do.

So I guess we're sort of chicken and egg kind of, in a sense, because you'll be compiling Go with Go. So if you don't have Go, how do you compile Go? Well, what you do is you download a binary distribution of Go. And when you build Go, you just give it the location of that distribution. It's the same thing as if you build GCC or any C compiler. You need a C compiler to build a C compiler. I know that GCC actually has a

pretty elaborate bootstrapping process to build itself from something very simple, but we don't have that. The baseline for us is Go 1.4. So we're requiring that the compiler be written in Go 1.4 compatible Go

so that if we add new libraries or language features, even though that's unlikely, but if we add things in Go 1.5 and above, we're not going to be able to use those in the compiler. We're sort of guaranteeing that the compiler will always build with 1.4. You mentioned the garbage collector in there, and I think that you got something to mention about that as well. So you've got a

concurrent garbage collector now. You've got new work on that that's going into 1.4. Can you talk a bit about that? Yeah, that'll go into 1.5. Oh, sorry. 1.5. Yeah, that'll be in August. Yeah, there's some really 1.5. Oh, sorry, 1.5. Yeah, that'll be in August. Yeah, there's some really encouraging numbers coming out. They have an implementation of the concurrent collector. So the major distinction when I say concurrent collector

is between that and what is the garbage collector in 1.4 is that 1.4's collector is just to stop the world, like Mark and Sweep collected, which means that once your program allocates twice as much memory since the last garbage collection, it triggers a collection. The whole program stops. The garbage collector walks all of the data structures

that are allocated and finds data structures that are no longer accessible by the application code. And then it marks all of those data structures. Actually, it does the reverse. It marks the ones that are accessible. And then it collects all the stuff that's inaccessible. And then it deallocates them.

And that happens quite quickly, but the program does pause while that happens. And so it means the larger your heap is, the more stuff you have allocated, the longer those garbage collection pauses will be. And that can be an issue for interactive applications. You can imagine, if you've ever played Minecraft, for instance, you'll notice that after you've been running around for a while, there'll be a few seconds where everything just chugs, the framework plummets, and it gets kind of awful and janky.

And that's because the JVM is doing a big garbage collection at that point. What the concurrent collector in Go will do is it does a lot more of the work while the application code is running. And then it's able to incrementally collect unused memory by making very, very small pauses in which to do that. So basically you're kind of smearing the larger collection over a longer period of time, And we're able to sort of specify an upper bound for like the, the longest your program will actually pause.

So it still will pause, but the size of the pauses should be predictable. Drastically less. Yeah. Drastically less. It comes at the cost of some runtime performance. So, cause obviously if you're collecting at the same time

as you're running the program, then the program must therefore run a little bit slower. But on balance, I think, you know, for most Go programs, the net effect will just be a simple positive or just neutral. And then it also makes Go useful for a wider variety of applications. There are some people who have more interactive applications or applications that have stringent latency requirements that just couldn't go near Go because of those.

But I think the 1.5 release will really make a lot more possible for a lot more people and make Go something that they can actually viably choose as opposed to ruled out simply because of the old garbage collector. You also talked a bit about the HTTP2 server being in Go. Is that planned for 1.5 as well? I know you got one point soon. Yeah, probably not 1.5.

I think the standard is the standard now, so that's encouraging. But it's probably not ready for 1.5 it's not really battle tests that are anything i'm not i'm not i'm not really sure um it could be but it's more likely to be in 1.6 but so on the release cycle does that mean the following august or is that spring and sort of yeah that means like like fe February, six months later. Gotcha, okay. But the nice thing is, you know, if you write Go programs that are HTTP servers, when we do bring HTTP2 support in, they'll just become HTTP2 servers.

So you won't actually have to do anything different in your application. There's also an active development repo out there from Brad Fitz. Is that something that someone can kind of use in tandem and sort of use it before 1.6? Absolutely. Yeah. We have a demo site at http2.golang.org where you can, you know, if you have a browser that supports it, which at least Chrome and Firefox do,

you can see what it's like to talk HTTP2. Also, if you use google.com or anything, you're probably already using HTTP2. Not the Go implementation, of course. But yeah, if you go to github.com slash bradfit slash HTTP2, you'll see his sort of work in progress. And it's pretty solid. It's very, very well tested.

Brad's very good about writing comprehensive tests. So he actually found a bunch of bugs in the spec and other people's reference implementations as he was writing his own implementation, which is a sign that you're doing a decent job, I think. We just had Ilya Grigorik on the show not too long ago, actually. We were talking about our new Nightly email. We shipped out this email called ChangeLogNightly. is actually the github archive email that ilia stopped shipping started

this year and uh ilia came on the show and said i'm an internet plumber that was his title because he was like i just i make the internet fast that's what i do and he was just talking about the new spec being out there and it was just a few weeks back, so it was fresh and new then. I think it's really cool. I think people criticize HTTP2 because it's version 2. They expect it to be something amazing, whereas I'm happy with just quantitatively better. That's a great goal. If you can achieve that, then I think

you're doing well. And really, I feel like it was the sort of the biggest incremental step we could take that people would viably adopt, right? I think some people disagree, but that's my take on it. And if you look at the demo site which i guess you'll link to um there's a gopher tiles demo where you get to see you know a whole bunch of images um loaded concurrently over http versus htb2 and you can artificially like add latency to the requests and um htb2 lets you pipeline like all of those requests simultaneously and so you can fire off like you know 100 get requests down one tcp connection and then get all the responses back and the demo is startling and i think particularly on high latency connections

like mobile connections it will really make the web a lot better i'm. That's a perfect segue there into talking a bit about mobile. We'll talk about Git here in a bit too, but let's start with talking about mobile. I know that it's some new stuff happening in 1.5, and you've got Android support coming out or deeper Android support, and you also have plans for iOS support. So what is the state of mobile for Go right now, and what are people building with Go in mobile?

Well, I mean, it's still really nascent. The libraries are still very Spartan and in flux. I'm not really aware of anyone doing anything serious with Go on mobile at this point. But what we're hoping to have

in 1.5 is a basic toolkit for writing Go programs that run on Android and iOS. So you'll be able to write the same Go code that runs on either platform. And there's a huge amount of grunge work involved in making this possible, which I've been tangentially involved with. The other part of it that's really cool is we'll have this Go mobile tool that

when you, it's a bit like the Go tool. You can just say, you know, Go mobile install and it builds your app and then uploads it to your phone. And, you know, if you're familiar with either the Android or the iOS tool chains, you know, you know how painful that can be. Very. And so, you know, I personally look forward to the day

when I can actually do mobile development because I simply don't have the time to just, like, get into that and figure it out. You know, it would take me way more spare time than I have. But I have all these great ideas about little games I want to build or, you know, little tools. You know, I would be writing lots of programs for my phone that I use all the time. But I just don't have the time to actually learn how to make that work. So, yeah, I'm very excited about that.

It's funny because over the weekend, or I guess this week too, but over the weekend we had some family in, and just sort of a side story on the desire to do some gaming. I never really thought that I would ever have a desire to build a game, but when I was sitting there with my niece, this is not a plug, and they're not paying us to say this, but coolmath-games.com was pretty neat. We went there on the iPad. We were just sitting there just playing games for like an hour or whatever,

and I was just thinking like here's this little impressionable kid loving these games, and she doesn't realize that you can build these things with HTML, CSS, and JavaScript, and it's pretty – some CSS animations and stuff like that. But going a little further to actually build an app part of it, you know, is what you're talking about. But I never really had that desire to build a game yet. And that was the moment where I had this moment where I'm like, I wish it was a little easier to jump into that or I'd sort of learn that. Well, I mean, even in the web world, like, it's insanely complicated to understand HTML, CSS, and JavaScript. You know, a lot of us have grown up in this environment,

and so we've kind of learned, we've wrote learned all of the stuff we need to know to be productive in that environment. I spent a lot of time as a web developer before I was at Google. And I think it's astounding, really, the complexity that we put up with. And so one of the things I'm excited about this Go on Android and iOS stuff is we'll have these simple toolkits for doing stuff like putting images and text on the screen, moving them around, animating them, handling user input, handling audio, and it would be a nice

little environment that just works. I know there are similar projects in other languages and so on. It goes the language I like using, so obviously this appeals to me. You've got to take what's happening elsewhere and bring it into your camp. That's how it works. Yeah.

Let's take a quick break and hear from one of our sponsors. When we come back, we're going to dive deep into Go's transition to Git from Accurial. Kind of hear about the details behind that. A lot of details shared. And I got some questions for you there, Andrew. So let's take a break. We'll be right back. And we'll go through that.

Over 400,000 developers have deployed to DigitalOcean's cloud. DigitalOcean is a simple cloud hosting provider built for developers. In 55 seconds, that's all the time it takes, you'll have a cloud server with forward access, and it just doesn't get any easier than that. Pricing plans are super inexpensive, just $5 a month for half of your RAM, 20 gigs of SSD drive space,

one CPU core, and one terabyte of transfer. All DigitalOcean servers run on SSDs. That means they're blazing fast. They have Tier 1 bandwidth support and come with private networking. Use our special link to get a $10 hosting credit when you sign up. Head to thechangelog.com slash digitalocean to get started.

And now back to the show. All right, we're back. So, Andrew, I think it was a hot topic for you to kind of cover anyways, which was the transition to Git. I know it made headlines. Well, it made hack and use. Well, I mean, headlines, right? It's good stuff.

It was in your talk, so that's a headline. Yeah, I mean, in retrospect. I was excited to hear this too. I think everybody else was, but it also, you know, in the wake of that, you know, how long has it been since the transition to Git? Oh, well, a few months, I guess. It was December, so a couple of months. And so then the next question that came on the minds of those who follow Go and obviously follow Google Code was like, was that, did you all know about Google Code or is that just by happenstance? Oh, no. Of course we knew as a team because, you know,

they're going to tell like their biggest clients about it in advance. But in a way, our transition to GitHub was kind of part of their preparing this automated migration tool that they've now given everyone access to. So if you don't know, they shut down Google Code and now there's this one-click tool for migrating your project from Google Code to GitHub, which is pretty nice.

It works pretty well. That's awesome. Yeah, and the team were really adamant that they didn't want to announce the deprecation of Google Code until they had the plan totally worked out, they had a tool that worked, that they were able to make the process as painless as possible. And so we wanted to make the jump to coincide with the very beginning of our development cycle.

So our release was for the 1st of December or the start of December. And we really wanted to make the cutover directly after that. And so, yeah, we did make the transition sort of motivated by the impending shutdown of Google Code. But really, I think all the reasons that we gave at the time were genuine. Like, there are a lot of good things about making the switch to Git and GitHub and Garrett. But yeah, if Google Code wasn't going away,

maybe we wouldn't have done it. I mean, it was a tremendous amount of work and, you know, nobody wants to do busy work. That's what I'm curious about because you got some pros and cons in your list here that you talked about in your talk. But as I was listening, I'm like, there's something deeper into that story there. And obviously, we know now that Google Code is sunsetted. So there had to have been some reason there. So you kind of throw a nugget in there of whether or not you may or may not have transitioned if Google Code didn't move away. Oh, well, no, it's just that I spent like two months of my life dealing with this problem of trying to seamlessly migrate all of our stuff from one service to another.

And it's not something that I would have chosen to do, like, if I had an option not to. It's like torture, right? Well, I mean, it's just work that I could have not done. Right. I feel like we're definitely in a better place now. So, you know, I don't really feel bad about it. And, you know, I respect the reasons for Google wanting to shut down Google Code. I can totally understand that as well.

I think, you know, like Chrome was, or even Wave, I guess, was like a reason to try and shake up, like, you know, the world of web browsers or the world of like online collaboration. I think Google Code was really, you know, at the time, if you remember, like, SourceForge was the thing. Yes. Yeah. And SourceForge was terrible, you know, so bad. And Google Code was like, just this breath of fresh air. And it made it, I think it made a lot of people realize, oh, hey, you know, we can build better, like, open source code hosting sites. And that paved the way for like, GitHub and Bitbucket and other services of that nature. It served its purpose

and it's obviously no secret now that it's not the place to be for open source projects now. GitHub seems to be that place now. That's fine. We don't feel bad about it. For us, it's mission accomplished.

There's something that people think is better. They should be using that. When Google Code came along, that wasn't the case. Well, this transition for you guys wasn't, it was a lot of your life, but it's not a big deal for your, it is a big deal, sorry, reverse analogy there, but it's a big deal for your contributors.

So those who actually contribute back to Go or ForkIt and try to push pull requests. We'll get into that in a bit. But it's not so much important for Go users. So nothing's changing with Go. It's just a matter of how you actually track versioning. Yeah, it's purely a project development process. How you do things.

Yeah, and the only really end-useruser facing thing is they use the GitHub issue tracker now rather than the Google Code issue tracker. And that actually is generally better for our users because most users are more accustomed to using GitHub's issue tracking system. Something you had said in your talk was that it was a steep learning curve for coming from Mercurial to Git. And Facebook back, I think about a year and a half ago, so I think almost the last time you were on the show,

they had made a choice of Mercurial or Git, and they chose Mercurial for speed reasons, but you chose Git. Do you think it's mainly for, because of Google Code obviously, but then also because of GitHub and the community? Or is it Git itself that attracted you? I wouldn't say I'm particularly attracted to Git,

nor am I particularly attracted to Mercurial. The main reason we switched to Git is that the code review system, Garrett, is built on Git. And Garrett is partially maintained by people at Google. And there is a team at Google that supports Garrett instances for Googlers to use. So they use it on Android extensively. And if it's developing infrastructure that is supporting Android,

we know it's not going to go away. Like our code review system, ReadFeld, that we were using with Mercurial, we were basically the last people maintaining the instance that we were using. It used to be used by a lot of people. And so we didn't really want to be in that position anymore. We wanted to be using something that was well supported by a team of people working full time on making sure it works. And so the Garrett team were already doing that for the Android people.

And so it just seemed like a natural choice to go with that. And there's a lot to like about Garrett. It has its rough edges, but it's definitely a superior tool to what we were using before. And so it was really Garrett that motivated the choice to switch to Git. And then once we decided to switch to Git, GitHub seemed like the obvious choice for hosting our issues, mostly. GitHub is mostly just used for hosting issues. What role does Garrett play in this process of building Go and maintaining Go?

Well, it's the code review system. Sorry if I wasn't clear about that. Every single change that goes into Go is reviewed and Garrett is the system a web-based code review system that we use to look at the diffs and leave comments upload new revisions. So they're like pull requests, but the workflow is a lot more focused on doing detailed code review.

I find that GitHub's pull requests are not very well suited to paying attention to all of the details. I find it very hard to keep track of different revisions of a change. So as you're working on something that's coming in, you'll make changes based on reviewer feedback. And GitHub makes it very hard to see what changed between one revision and the next. It also forces you to do things like look at all of the files that have been changed in one big fell swoop.

And actually probably the most crucial thing that I like about Garrett and the other code review tools that I've been using in the past is that when you're reviewing something, you make a series of comments on all the code, like on lines and so on. And then when you've done the review, you then send all those comments as one big atomic thing. And it comes as one mail message. And then the author of the code responds to those messages.

Whereas on GitHub, I start commenting on the change and the author of the code is already receiving my comments by email. And so if I get halfway through the code and I'm saying like, oh, why did you do this here? Like, this is confusing. And then I get to like the next file and it's like, oh, I totally understand why you're doing this now. And like in Garrett, I could go and delete those old comments or edit them. But in GitHub, I suddenly have to send more comments to the author and say, oh, oh, oh, ignore my other comments.

You're like, I didn't mean that. I understand now. Meanwhile, they're giving you a deep dive, and they're wasting their time commenting back like, no, I fixed that down here, and you're both crossing wires. Yeah, and I think that approach, it probably works for some people. It probably works for people on small teams.

But I do dozens of code reviews a day and there are people on my team that do more. And it's crucial that the process be as efficient as possible. And there are just too many inefficiencies in the GitHub way. So that's why we didn't go with pull requests, essentially. That's another mention I want to mention here is, why don't you accept pull requests? And we're kind of answering that, so I won't ask you that directly.

So let's sort of roundabout answer that. My thought is that you use Garrett because it gives you a better user experience around code review, accepting pull requests that aren't actually GitHub pull requests, but reviewing code changes and for the reason you just mentioned there. But if GitHub

improved their pull request processes to, let's say, match the Garrett process, let's say that became the new GitHub way, would you stop using Garrett? Well, I mean, there's a lot of hypotheticals in that question. Right, of course. Plus you've got the CLA or the – yeah, the CLA is involved in there,

so the Contributors License Agreement that is part of contributing to Go. Yeah, we actually – Things are happening. Yeah, so licensing is obviously important. We need to make sure that the people who are contributing code actually give the project the license to use that code. That's an important legal protection for us as a project, and it's an important legal protection for our users as well.

And with Garrett, you can't actually send a change until you've signed that agreement electronically. And so that's nice. It means that if I'm reviewing someone's code, it means that I actually legally am allowed to look at that code and submit it. On GitHub, there's no

built-in support for that, but we do have this Googlebot that we can enable for projects that when a pull request comes in, it checks whether the GitHub user has signed the CLA. And so that's not actually a problem for us using GitHub. I have a couple of projects, like the code base for godoc.org,

the Go documentation website. That is hosted on GitHub, and I use pull requests for reviewing code because that predates the transition of the main project to GitHub. And I use the Googlebot for processing CLIs there and it works fine. It's great. But look, I could imagine if GitHub was able to give us a workflow that was, I guess it would have to be better than Garrett at this point

because we're not going to just change things again. But it would definitely be preferable. I don't like getting pull requests. Incidentally, there's no way to disable pull requests on GitHub. You can't opt out. You can't opt out. And I don't like having a contributor send a pull request and me having to say, I'm sorry, we don't take pull requests. Yeah, that's a bummer too.

I almost feel like there should be like, if you're not going to, not so much turn them off, but point them elsewhere. If someone forks it and sends a pull request or wants to go through the process, rather than going through the GitHub way, it points to, say, a different public URL through Garrett or something else that still gives you the same abilities, just not using native GitHub. Yeah. I would love if anyone from GitHub listening, you know,

there are a lot of small things that could be done to provide essential information to contributors early. Like if you put a contributing.md file in your project route, when a user goes to file an issue, they see a link at the top that says, please read the contribution guidelines before filing an issue. And that's nice. I would actually prefer it if they just showed the contributing file, you know, on the issue filing page, because our contributing file is very simple. But it says, like, for instance, if you're filing an issue report, please tell us these essential pieces of information.

And on Google Code, we actually had a template. It would say, what version of Go are you running? What platform are you running on? What did you see? What did you expect to see? What did you do? There's kind of like these five essential questions. And not having that template in the issue tracker means we get less informative bug reports

and they require more handling and more follow-up, which means that they're less likely to get addressed. And with the pull request thing, as far as I'm aware, the contributor doesn't get shown that link to the contributing doc when you create a pull request. And the essential line in that doc is we don't take pull requests.

Here's the contribution process. And so I feel like if GitHub would just surface that contributing file more readily in these processes, we could really reduce the double handling that happens for a lot of these issues

and reduce frustration. Because I think our contributors, they want to contribute in a way that works for the project. Nobody wants to be doing the wrong thing. But I think it's frustrating and upsetting to people when they think they're doing the right thing by sending a pull request and then they're told, sorry, that's not the way we do things.

And they can't be faulted for not knowing that. But at the same time, I get tired of telling people the same thing every day or two. I think it's surprising, though, when you have a disclaimer saying we don't accept pull requests. I think you've got to put a parenthesis in there and say, kind of. It's not exactly true. There's some steps that require

the CLA being signed to hand the rights over to the project and whatnot. So I think it's just kind of funny that you said we don't accept pull requests, but it's not exactly true. It is strictly true because we accept contributions, but they're not in the form of pull requests.

Pull requests, right. Yeah. I think – I almost feel like those are interchangeable terms to a degree. I mean I know GitHub coined the phrase, but because open source is becoming more and more in the public's eye, GitHub is the place where people think open source happens. So to the untrained hacker eye or developer eye, trying to erase hacker from my lingo because it's just not inclusive. I want to be inclusive to everybody. But anyways, to the untrained developer eye, everyone else thinks that GitHub is sort of the epicenter, which it, you know, reasons you're there too, with Go, is that it's become the place where the community is. And so to send a pull request

is like saying, I contribute. And so that sort of becomes the somewhat interchangeable terminology, at least in my opinion. Well, you know, I just hope that GitHub takes the feedback from people like us. And, you know, we're definitely not alone. There's a lot of people who have similar issues

with their pull request system. And I hope that they take this on. And being the kind of de facto center of the open source world, I think they have a responsibility to respond to these kinds of requests. But ultimately, they are a business and personally i don't believe that um it's healthy for everyone to have this kind of dependence on one large business and obviously working for google that might sound somewhat ironic coming out of my mouth but yeah a little bit but you know i feel you i know what you mean i i am a big fan of running your own infrastructure

um i think it makes sense to use infrastructure provided by other people where it makes sense but you know i'm a contributor to brad fitzpatrick's camley store project which is all about reclaiming control of your content and you know you could it's a storage system for things like photos or basically any kind of files or anything. And you can run it on cloud storage or S3 or whatever, but you can also run it on a server in your basement. And you can do both. You can synchronize it between both things.

And I think we need to build systems that break our dependence on large organizations and so yeah i mean i hope people don't forget that git is not github you know git is an open source tool that anyone can use to host source code anywhere um and i hope people don't you know i hope it's not quite true what you say about people thinking GitHub equals open source because. Well, I don't think that exactly means it equals. But, you know, when they think open source, they think, well, is it on GitHub? Oh, then it's not open sourced.

You know, that's that, it starts to become truthy because anything that's happening around open source tends to be pointed back to some sort of github.com slash URL. Yeah, I mean, like kudos to GitHub for building something people really love. And I think they've done a great job. But I think it's really important, particularly in the open source community, for everyone to remember to be self-reliant.

I think that's a really valuable thing, and it's kind of a core tenet of what open source is about. Let's talk a bit about, we don't have much more time here. We've got maybe like eight minutes flat, probably less than that since we've actually gone over time a bit but let's talk about uh go 1.5 is releasing uh august august 2015 with your new release cycle uh no c code will be in 1.5 you've got some new architectures supporting power pc 64 and maybe the arm 64 now when this, forgive me, but the question I asked myself was what types of machines are running on PowerPC 64 and ARM64? Because I guess I just never think about what my machine is running.

I write my MacBook, and whatever they give me, I just use it. I know it's not PowerPC because they went to Intel a while ago. So what is the PowerPC 64 and ARM64 architectures? Right. So places a consumer would see ARM is obviously phones. And ARM64, the big ARM64 platform is the iPhone. So everything from the 5S up is an ARM64 processor. Okay.

And I think Apple won't actually let you run 32-bit processes on some of the newer iOS versions on their ARM64 processors. So for this Go mobile stuff to work, we need to target ARM64. So that's what ARM64 is about. There are probably some people doing processes in the server environment, but I'm not really aware of them.

PowerPC 64 is something I don't have a lot of visibility into, but I know that there have been contributors from companies like Canonical who are pushing that support, as well as other people in the community and people from Google. PowerPC is an IBM processor architecture. And so I think the PowerPC 64 machines are very, very high spec, multi-core server machines. And so they're the kind of processes

that you wouldn't have much to do with as like an average developer. But I think it's possible that we'll see them making inroads into the server market. I don't really have a lot of visibility into it, but I think it'll make some particular sort of enterprise-y customers happy. And if you're trying to supplant Java, then you've got to do that, right? Yeah, I mean, the Go toolchain has been a cross-platform thing

since the very beginning. And part of the rewrite actually has made it much, much easier to support other platforms. Like the actual architecture-dependent part of the toolchain has gotten smaller and smaller over time. And now it's actually quite small. So we just want to support Go everywhere that we can. And if there are people willing to help contribute that support,

then we'll happily help them do that. Let's talk about the builder infrastructure real quick. I know we don't have much time, but I was really impressed by GoM and google compute engine so talk a bit about the the uh google compute engine and go mode what you were doing there that was that was pretty amazing right well so the basic backstory is you know since go is so cross-platform we need to test it on all the platforms that we support and so you know we have this sort of homespun builder infrastructure that, you know, we have a build dashboard and we have these machines, like this heterogeneous array of machines that are all around the world, like macOS machines, Linux and FreeBSD, NetBSD, OpenBSD, Plan9, Windows. And all these machines run this Go binary that fetches the latest revision of Go,

builds it, runs all the tests, reports the results back to the dashboard. But maintaining this array of machines is a total pain. They're all different. They all work differently. They're all owned by different people. You have to email someone when something goes wrong. And then if you have a problem on a particular architecture, you need to get access to one of the builder machines to be able to actually test your code on whatever that process or an architecture is.

So Brad Fitzpatrick mostly and a bit me have been working on some new builder infrastructure that uses Compute Engine. So for all of the operating systems that we can, we're running those on virtual machines on Compute Engine. And so we have this kind of like deterministic build environment that we can spin up

at will. And so we can do many, many more builds in parallel than we could before. And also now we can do speculative builds. So if someone sends a change, we can run the tri-bot on it, as we say. So you get to see whether the change builds before you actually merge it into the tree.

And so that's been really nice. Currently works for like Windows, Linux, FreeBSD and a couple of others. But we look forward to doing something similar with macOS. It'll be a little bit different since we can't run that on Compute Engine, but we have plans for how that might work. But a nice side effect from that is

we have this tool called GoMode, where if you're a Go developer and you see that your change breaks on OpenBSD, you can spin up an OpenBSD instance on Compute Engine with just one command line invocation and then push your local changes to that machine run them, see what happens and you get to actually develop on the architecture

that you're trying to support. And then you don't have to actually have a bunch of VMs sitting around or actual machines if that's the route you choose to go if you're a developer for Go. Then this makes it a little easier to build, write code for many, but not have to actually own those machines. Yeah, one of the really nice side effects is we'll be able to make this available to Go programmers in general. This will be free to anyone who's developing for Go?

Yeah, so you can just plug in your own Google Cloud project credentials and then it will spin up instances that you pay for. But you only have to pay by the minute. Like 14 cents or something maybe? Yeah, probably less even Like 14 cents or something, maybe? Yeah, yeah. Probably less even for an hour or something. So it means that if you're a Go programmer and you want to test your stuff in other places,

you should be able to do that pretty easily. And also, I think it's just a nice kind of demo of cloud orchestration stuff. Although, you know, there are a lot of tools in that sphere. I don't necessarily recommend writing tools like this. For us, it was kind of an experiment to see how our cloud libraries were and ways in which we can make that better.

Because obviously, you know, the Go team here at Google, we have a close relationship with the cloud team at Google, and we're very focused on trying to make, you know, Go the best language to use on Google's cloud platform and also other cloud platforms. And so we've found a lot of weak points, things that we want to improve. And part of building this project was just seeing how good our offerings are.

We're pretty happy with it, but obviously we find things that we want to improve and we're working on those too. All right, last question before we go into a couple of closing questions, which are really short, but I can't let it go without asking this question, which is you've been here twice now.

Has it been three times you've been? No, it's been... No, twice. Rob was on way back when, then you were back with Rob on episode 100, and then now you're back here for episode 148. It's been a year and a half since you've been on the show, so what is the future for Go? You got this last 1.4 to 1.5 we're shipping later this year.

What beyond that? Where are you seeing past 1.6 or beyond? I really think as far as the Go core is concerned, you know, it's going to get faster. It's going to run in more places. It'll be more efficient, you know, better optimization in the compiler, optimization in the libraries, you know, improvements to the tool chain, maybe, you know, some new sort of developer tools, that kind of thing.

But I think that, you know, the most exciting developments around Go are really in the greater Go community. And actually, one thing that I'm involved in is a project called GoKit, which a guy called Peter Borgon from SoundCloud has initiated. And it's an open source project that's basically trying to build a standard library for building distributed systems. So it's kind of described as like a toolkit.

The purpose is, you know, if you want to build distributed systems in Go, so a lot of the cloud services that people build are basically distributed systems. And there are, or people often call them micro-services. You have many services that talk to each other via RPC systems. If you know what I'm talking about, then you know what I'm talking about. But basically, GoKit is trying to define a set of things that people need to build these kinds of systems

and then provide a canonical set of recommendations or even libraries and interfaces that various tools and libraries can satisfy so that, you know, you can have a well-integrated developer experience for building distributed systems in Go. So that's kind of like the goal. You should check out Peter's talk, Go in the Modern Enterprise, which he gave at FOSDEM for the vision. And we're linking that up in the show notes,

so we'll definitely have that talk in there. Yeah. You know, speaking of GoKit, we were actually wanting to have Peter on the show, but I wanted to have him on after we talked to you to kind of get an update on where Go has been at for the last year and a half and what you've been doing. So I wanted to have you on there. And I didn't know you were working with Peter on this. So it might make sense to have you back on with Peter if that's the case.

Yeah. Well, when I saw his talk, I was like, oh my god, he's just really clearly articulated a lot of the same things that I'd been feeling about Go. We really need to focus on making this work. He called it the modern enterprise, which is sort of these medium-sized companies that are building these distributed systems. And I feel like Go is a great language for those companies, but we really need to focus on making it clearer and easier for people to make the right choices when building those kind of systems.

And also, I think there are a lot of people in the Go community working on these problems, and we've actually seen it with GoKit. When it was announced, a lot of people joined the GoKit project and they were like, oh, I've been working on X. everyone and try and arrive at some kind of consensus. And so I'm really excited for how this is going to turn out. I think it's really promising. Peter's a really sharp guy. I really appreciate his thoughtfulness and also his taste. I think his taste aligns very much with the taste of the Go project and sort of what that's all about. So I feel like that element of Go's community

is sort of in good hands with him and that project. And so, yeah, I've been trying to contribute. I wrote an API stability policy, which is sort of centered around versioning package management side of things. But I think you should definitely get Peter on the show and talk to him because it's always interesting to listen to. We definitely do.

I know we cover that in our weekly email. I'm not sure which one, but we share so much stuff in ChangeLog Weekly that it's just hard to even remember what we shared and when, but I know we covered GoKit because I was pretty impressed with that, and especially knowing that I wanted to have this conversation with you and sort of ask you that same question, which is what can programmers anticipate for, and he coined it pretty well, which is the modern enterprise, but the workplace. So if you're anticipating to supplant Java and those kinds of

you know those kinds of projects in enterprise now and go is going to take over that then uh you know go kit makes sense totally all right well definitely would you be interested in coming back on the show to with peter or is that something i should have peter come on his own i guess you should ask him i would be more than happy to though gotcha um okay so let's let's close up the show then i got a couple questions for you to close the show some that are uh typical that we like to ask and then uh that's that's how it goes but um one of our favorites and it certainly helps so you can kind of answer this as deep as you'd like to. It's kind of one part, which is how can someone step into the Go project? Either it's learning Go or it's contributing back to Go or supporting the efforts that you're doing and the rest of the team is doing, although they may not be Google employees, but how can one be an open source contributor?

So what's a good way for someone to step into Go? Where are some needs in the Go community right now that people can step into? My general recommendation when I'm asked this question is just to solve problems that matter to you and then share those solutions. Because programming language is way at the bottom of the stack, and so everything that happens above there in that language helps that language. And so if you want to get involved with Go, you just need to start using it,

and then sharing what you've learned or what you've made. And that just helps everyone. All right. That's a good, that's definitely a good answer. And I, you know, I actually, I kind of lied. It's two more questions, but one's really easy for you. This one, maybe not so much, but definitely a good answer. I'm hoping from you, which is, you know, what's in your open source radar. I can imagine that Go is completely your radar, but let's,

whichever direction you want to go, but if you had a weekend clear and you didn't have anything planned and you were like, I'm going to hack on something, what would it be? Would it be Go or would it be something else around Go? There's a project that I've been working on for an embarrassingly long time that I've been neglecting lately, which is called Sigourney. It's an audio synthesizer. Yeah, it's a modular synthesizer.

So, you know, it's similar to environments like Max MSP or Pure Data that people may have used. But basically I have an actual physical modular synthesizer, which is you have various modules that like produce waveforms and then filter them and then, you know, multiply them and so on. And you connect the modules with patch cables,

like actual physical patch cables. And then it makes sounds that some people might describe as music. And, you know, I wanted something similar because I travel a lot. I wanted something similar for when I'm traveling around and I also wanted to learn about digital signal processing and so I started sort of building

this thing from first principles and made a lot of progress pretty quickly but then I've kind of stalled on it so definitely if I had some free time and probably more importantly some free space in my brain to think I would probably hack on that kind of reminds me a little bit of this thing we covered a while ago

which has probably changed its name since but I think it pronounced it Keevil host K-I-E-V K-I-E-V-L-L host if that rings a bell to you. I haven't heard of it, no. It's like a digital audio

workstation kind of thing and it does similar stuff where you connect different things and patch things together. It's pretty cool. There's a lot of amazing work being done in the electronic music making world.

It's a huge cottage industry, people making both hardware and software. So it's a really exciting time to be doing that kind of thing. And I might give some of your last question now, if I recall correctly, like what would I be doing if I wasn't working on Go? And the answer is I would definitely be working in audio hardware and software. And the answer is, you know, I would definitely be working in audio

hardware and software. So speaking of audio, you would like to hack on that if you weren't working on Go. What's one of your favorite podcasts you want to mention here on the show? So yeah, my friends, Mike Bernstein, or MRB, and Aaron Quint um they do a podcast called beats rye and types and it's about music like food and drinks and uh programming languages and programming in general and um yeah they're just a couple of like a couple of guys from you know the east coast of the states i feel a great affinity to them as people, so listening to them talk about all these topics that I'm very interested in is always entertaining.

Absolutely. Obviously, I have a bug for audio, and you mentioned that you might want to do a podcast, so if you're a listener and you were you know stuck on that give him a give Andrew props on Twitter or something I don't know if people think that I should do a podcast you should tell me and that'll make it more likely

I started doing these screencasts with Brad Fitzpatrick called Hacking with Andrew and Brad and that arose because you know I thought you know what I should stream some programming sessions, you know what? I should stream some programming sessions. And the response on Twitter was overwhelming. They were like, hey, yeah, I'd watch that.

That'd be great. And so eventually Brad and I got together and did one, got some great feedback. And then we just did a second one not that long ago. And we're looking forward to doing another one soon. Is there a list of those somewhere? Because I'll link it up on the show notes if there is. Yeah, if you go to youtube.com slash gocoding. Okay.

There's a playlist of those two videos, which obviously we'll add more to when we make them. Nice. All right, we'll link this up in the show notes for sure. Well, I know that I've taken you much longer than i expected as a matter of fact my clock says we're 29 29 minutes over time so thank you for not getting angry and if you're a listener and you're still listening right now thank you for listening all the way to the end it's kind of hard sometimes though when you come into a conversation it's about the state of go and there's a lot to talk about. We did have a little bit longer intro than I thought we would have,

but, you know, hey, that's how it works out sometimes. I'm just glad you're a good sport with it and you're not upset. But you are almost getting kicked out of the room, so. Always happy to talk about Go. All right, Andrew, well, let's say goodbye to everybody and thanks for coming on the show today, man. I appreciate it. Yeah, thanks for having me.

Bye, man. I appreciate it. Yeah. Thanks for having me. Bye Andrew. Bye.