So I'm here at .go and my name is Andrew Jorand and I'm on the go team and I'm talking to my friend and colleague Brad Fitzpatrick. I'm also on the go team and I just wanted to ask Brad a few questions about go and his experience. The first question is what was the first go program you ever wrote? I think the first useful program that I tried to write was I was working on the Android team at the time and we were trying to sync all of our Android source code to some NFS server so it could be indexed by some code search endings system that we had. But our sync was so slow because our sync was only like doing one file or one directory at a time. So I thought, I'll use go routines and I just decided to do this massive go routine bomb that for every directory it did a go routine and for every file it did a go routine and did a copy. It kept crashing my whole machine and so I called Russ Cox up and I sent him an email being like go socks, I didn't say go socks. I was like I tried to run my go program and my whole computer crashes and he came over and it turned out I had like 20,000 kernel threads trying to do copies and stuff so I didn't really know how to use go routines yet. Did you end up making it work? Yeah, yeah. Did they use it for a while? It was actually kind of impressive even then in what was like 2009 or 2010, early 2010 that all the profiling stuff was still pretty good. Oh yeah, so yeah, we actually have the p-prof stuff in almost from the beginning so that's cool. The second question is what was the most, what's the, sorry, what's your favorite bug? Favorite bug. I'm mostly deal with HTTP bugs but I think the cutest bug that I ever dealt with was the IOUodle package has this discard thing which is kind of like the DevNull. It's a writer that if you just want to get rid of something you just Iocopy to DevNull or whatever. But it has to have this buffer behind the scenes to like write into as the destination for write. And so originally we just had one buffer that everyone shared but then when Dimitri did the RacerTector then everyone writing to that thing even though we didn't care about the result still tripped up the RacerTector. So we had to have different buffers that were shared but anyway there was a subtle bug where with the recycling of all the buffers and sharing the buffers that it was sometimes possible to make real programs not like have different behavior because of the buffer thing. It took a bunch of us looking at it a long time when we finally discovered like what the bug was it was just amazing. We have a bunch of new tests there now. Wasn't it because you were the buffer is actually used by all of the writers in the chain of writers? Yeah. And you were all the readers rather? I can't remember which way it is. Yeah. There must be writers. And you were doing Shah hashes. Yeah. And they were hashing the hashes were wrong because you were sharing the buffer. And because it was never actually like making it there or something it was like skipping something and the Shah one was being done on a buffer that didn't have the things. Yeah. I actually wrote this up for the for the go blog in the article introducing the RacerTector because this was an example of like a spurious like RacerTector. Yeah. This is a harmless bug that turned out to not be harmless. Nope. So that's cool. But we have good test now. Yeah. And you know code that works. And I think that actually uses sink pool under the scenes now to. I think yeah. Now it's a test. Yeah. Okay. And the third question is what is the worst piece of code like go or otherwise that you've ever written? Well my go code is perfect. Of course. Of course. Of course. Oh. As is mine. I don't know. A lot of hilarious. I mean I've had tons of crappy code but like the first crappy code I ever had was when I was first learning to program. So I had like one of those printers that actually like moved the head back and forth and made lots of noise. And you could tell it to print like a single letter at a time. So I wanted to make a typewriter that as I typed on the keys like you went. And I only did each letter. So I had this like loop that is like read a single key. And then I wanted to print to the printer that single key. But instead of just like doing the one line like read the key print that one. I had like 30 if statements like if the character is a print and a. And then I looked at it and looked a little redundant you know because like you know 90% of my program was the exact same if statements. And I hadn't really understood variables yet or I hadn't really. You know like surely there's a bit of way. I knew that there were variables because like I used them sometimes to read something but I hadn't really like realized when that could use them. So I replaced that all with like a single line and I was like whoa. So that's what that was that was some crappy code that got a little bit better. It's like 25 years ago or something now. Maybe more. Yeah. Well it's come a long way. Thank you Brad. Yeah.