Go gets audited, and Ian Lance Taylor talks about 19 years on the Go team
This show is supported by you, our listener. Stick around to live for the news to hear some more about that.
Jonathan Hall:Cup and Go for 05/23/2025. Keep up to date with the important happenings in the Go community about fifteen minutes per week. I'm Jonathan Hall.
Shay Nehmad:I'm Shay Nehmad.
Jonathan Hall:Hello, Shay.
Shay Nehmad:This is gonna be a difficult episode to record because my body is rejecting California.
Jonathan Hall:Oh, no.
Shay Nehmad:I'm gonna try my best, but the allergies here I've never been allergic to anything, but I don't know, guess California, sequoia trees, I don't know what's going on. But we're gonna try to push through it.
Jonathan Hall:In the meantime, we have a great episode coming up for you today. We're talking about some great blog posts, some issues that have been declined, and later after the news we have an interview with Ian Lance Taylor. You don't wanna miss that one.
Shay Nehmad:Yeah. Was we actually already recorded it, so we can tell you it was it was a pretty interesting conversation.
Jonathan Hall:It was.
Shay Nehmad:But I'm I'm gonna kick things off here with Trail of Bits data audit on Golang's standard cryptographic library. And I guess we should start with like, why? Why would they do a security audit for the cryptography library? What's like, why would we even, invest time into doing that?
Jonathan Hall:Are you asking me to speculate? Yeah. All right. So I can imagine that we would want to make sure that the crypto is working correctly, that we're not leaking secrets, have backdoor side channel types of exploits because we're not doing things correctly. That's pretty handwavy.
Jonathan Hall:That's usually how my
Shay Nehmad:security works, by the way. It's very handwavy. Yeah. So you're not gonna pass the real reason they're doing this, which is to pass the FIPS compliance. Oh, yes, of course.
Shay Nehmad:I'm not gonna go super deep into FIPS because we actually have an episode about that. I don't like referring people to past episodes to learn about a topic, but honestly, the FIPS episode we had with Alex Shield was so informative about what FIPS is and how it works and all that.
Alex Scheel:Library which undergoes FIPS certification. Before that, I was at Hashbrook working on Malt. And before that, I was at Red Hat where I worked on a PKI solution called DogTag PKI, which is.
Shay Nehmad:But just in short, it is security requirements for cryptographic modules by, like, NIST, by a standard. Right? Which if your cryptographic libraries work in that, work for that like certification and follow these requirements, you know, it gives federal organizations sort of
Ian Lance Taylor:a stamp that
Shay Nehmad:you have adequate security. Have you ever been on the other side of like a penetration test or a security audit of your code?
Jonathan Hall:The other side meaning?
Shay Nehmad:Other side meaning someone is doing penetration testing on like a web service you've developed or something like that.
Jonathan Hall:A couple of times.
Shay Nehmad:So it's always a bit nerve wracking, right? Because the what's the interest of the of the company who's doing the penetration test or
Jonathan Hall:the security They to prove how terrible my my code is from a security standpoint.
Shay Nehmad:And like the more severe findings they find, the better, right, for them.
Jonathan Hall:From their perspective, And
Shay Nehmad:for your perspective, like because
Jonathan Hall:then they get my bonus instead of me.
Shay Nehmad:Yeah, basically, they get to have your lunch. The bottom line of this report, for four weeks they had three security researchers like reviewing all the code, writing Semgrep rules, etcetera, etcetera. And honestly, they basically found nothing. They found one low severity finding and five like informational ones. The low severity is a timing issue, which is always fun to discuss, but isn't really a problem to be honest.
Shay Nehmad:And the bottom line is on their Twitter, I really love that quote, so I'm gonna just say the quote. Google Go libraries are a model example of cryptography implemented the right way. The code base was designed and built with security and testing as a priority. I mean, come on. So the security audit is basically a glowing recommendation that the Go, you know People always say, leave cryptography to someone else, someone else did it better.
Shay Nehmad:You know, we had Filipa on the show. So sounds like you know a lot about Go and, cryptography. Who are you, Filippo? Why don't you introduce yourself?
Filippo Alsorda:Hi, everyone. So, I'm Filippo Alsorda. I've been, maintaining the Go Cryptography Standard Library since 02/2018. I've done that first at Google as the lead of the Go security team, and these days, I'm doing it as a independent open source maintainer.
Shay Nehmad:And when we had these people on the show, you get a sense that, like, the the crypto stuff is for real. Now you have like external third party confirmation from a consulting company who's all they wanted is to prove that it's not good, that it is good. Which for me is it's like very, you know, it's a lot of fun to just know that, yeah, I can offload worrying about crypto to someone else and not worry about it too much. It's hard to figure out. Yep.
Shay Nehmad:So the security audit was a good, got a good result. Good for you if you use Go. Way to
Jonathan Hall:go, Go.
Shay Nehmad:Yeah, exactly.
Jonathan Hall:Next up, we have a decline proposal. I wanna just do a warm virtual hug to the proposal creator who probably feels really rejected now that their proposal has been rejected. Let's see, who was it? Oh, Russ Cox. The proposal here was to add a package for iterators.
Jonathan Hall:The proposal was XEXPXITER, a new package for experimental iterators. This was proposed back when the new Range Rover Func was proposed or when it was added. The idea was sort of, I guess, a staging ground to try some experimental iterators to see what sticks, what's useful to make it into the standard library. Well, he actually last week sort of withdrew the proposal. He said this was a good discussion, but I don't think we have a consensus on really adding any of these to the standard library and encourage what in many cases is over abstraction, although not always.
Jonathan Hall:More important, we're not going to do X idr. If we're not going to do X idr, we should stop talking about it and create more space for third party libraries that we're sending in the way of. Lick the cookie, but the cookie is now quite stale. Better to toss it
Shay Nehmad:and let other people bake some new ones. So let's go bake some cookies. But iterators are such like an infrastructure thing. Would you import a third library for your iterator or would you just implement it yourself? I would just copy some code, like even from this straight up out of this proposal or something.
Jonathan Hall:Sure. So I think it depends a lot on the specific use case, right? So some of the types of iterators that were proposed to go in this were things like concatenating two iterators together, reporting whether two sequences are equal using an iterator, which is kind of a strange thing, I guess. Zipping iterators together. So you take you have two iterators, you take value one from iterator one, value one from iterator two, value two from iterator one, value two from iterator two and so on.
Jonathan Hall:Zip them together. So a bunch of things here. Some of these might eventually make sense in the standard library. Some of them are fairly niche. Like, I don't think I've ever needed to zip two iterators together.
Jonathan Hall:If I need to, I could probably write that in just a few lines of code. Like you said, copying even straight from the proposal.
Shay Nehmad:So generally you're happy this is declined?
Jonathan Hall:I suppose so, yeah. I guess I'm actually kind of indifferent, but it seems like this collection of functions are the kinds of things I would rarely reach for. So if I have to create them myself, that's fine. Yeah, I'm happy with that.
Shay Nehmad:To me, all the iterator it it definitely feels like the sort of things that if you need to use iterators already, you already know all the options and you've definitely have something that works, already. And if you're sort of a new coming to Go, you can probably find what you're looking for pretty easily. But I appreciate the carefulness in which the Go team introduces new features more than I appreciate having everything at the ready in the standard library. So so generally good. Also feels nice to they have a proposal by Russ rejected because he rejected my proposal, even though he rejected his own proposal.
Shay Nehmad:So I don't know.
Jonathan Hall:Yeah. I'll bet Russ has more rejected proposals than most people in the world.
Ian Lance Taylor:Yeah, for sure.
Shay Nehmad:If you remember, a while ago we mentioned a conference on the show, as we do, like if you have a cool conference coming up or a meetup, let us know and we'll definitely, like, it's good when gophers come together and talk about Go, I think, for many reasons. Like it advances the language and people get jobs and network and it's fun and free pizzas, blah blah blah. But we don't normally get follow ups on that, but we We got a follow-up. And if you want to see, you know, a talk from a conference we already mentioned, visit gapnotes.org. I watched the talk by Gabriel Algandre.
Shay Nehmad:I hope that's okay. It's probably not because on the blog post, he was like, no, Jonathan, that's not how my name is pronounced, but I don't blame you. But, yeah, it it was in Czech Republic. Very good talk about like how linters work and like what's the AST and specifically about, you know, the context wrap thing, where you don't wanna wrap the context. If you want to add a value to a context, you don't wanna wrap it in a new context because that can introduce performance issues.
Shay Nehmad:Mhmm. It's the sort of talk I like which has like demo code and slides and like charts. It was very It's a very good talk, So you should probably just go check it out on YouTube.
Jonathan Hall:And
Shay Nehmad:thanks for letting us know. It was like the conference is happening, like was happening. If you have a conference or a meetup coming up, let us know. We'll definitely shut it up. Well, definitely, maybe.
Shay Nehmad:I don't want to make like any strong promises, about what we will and will not shut out, but we'll try
Ian Lance Taylor:our best.
Jonathan Hall:Hey, Shai, do you remember Anton who came on the show a while back?
Shay Nehmad:Of course. The interactive code, the only way to read the Go releases now, basically.
Jonathan Hall:Yeah. I'm I'm looking forward to the interactive 1.25 release notes. But until they are here, he has a new, blog post about how do you check if you're online? How do you check if you're online?
Shay Nehmad:Are you actually actually asking? Because I do have an I go to wtfismyip.com/jason.
Jonathan Hall:Okay.
Shay Nehmad:That's my go to. It just always works.
Jonathan Hall:I usually ping. I usually ping Google.com just because it's easy to remember. Right?
Shay Nehmad:And it's probably up. Right?
Jonathan Hall:It's probably up. However, it doesn't always work because sometimes ping is filtered. Right? Depending on if you're behind a firewall, especially if I'm at an internet cafe or something, I'm out of my laptop at a hotel, maybe they don't let things through. So his blog post is about some alternatives to ping Google or whatever.
Jonathan Hall:And he points out that several services, Google, CloudFare, Ubuntu, they have URLs you can query over HTTP that will tell you if you're online or not. And he goes through some of the details about some that return a two zero four, which is the equivalent of a 200, but specifically says there's no content here. There's no body. So it's in theory, a lighter payload or some also return a 200. So they probably include some sort of minimum body that says something.
Jonathan Hall:And then he talks about how to implement these in this sort of online checks in different languages. He has Python, JavaScript, Shell,
Shay Nehmad:which is closest
Jonathan Hall:to
Jonathan Hall:what I
Shay Nehmad:most
Jonathan Hall:of
Jonathan Hall:the time.
Shay Nehmad:It
Jonathan Hall:is a nice little Go snippet. It's about 10 lines of code. So if you have a service that needs to check, am I online or not? This is one simple way you
Shay Nehmad:can do it. And my immediate thought when seeing this was, a, it's a better check than think, right? Because it's just for HTTP and if you use even HTTPS for for some of them that do work, you can check it for like your HTTPS stack works where you work locally. Unfortunately, the the main use case I found when reading this, was like, oh, this is a really good list. Check if I'm online in a malware, because I can use, like I can random pick one of these or two of these every time, and that way my behavior is not like, there isn't a very simple heuristic of, oh, if you're, if you have something running on your machine and it goes to cloudflare.com/generate204, it's Shy's malware.
Shay Nehmad:Because you can use like, you know, I've done lists a ton of links here. So you can just like pick and choose, you know, Apple, Debian, Gnome, Microsoft, Mozilla, Xiaomi, Ubuntu, Cloudflare, and of course Google to check for your connectivity, therefore making your malware less detectable. But now that I said I don't know if it's that big of a secret anymore, so maybe it's not useful. But it was just funny to me that the moment I saw this list, was like, oh, this is gonna be super useful for malware developers. This is a problem with everything that's like useful, you know, someone puts out a blog and like, here's the new obfuscation technique that's really great.
Shay Nehmad:And I'm like,
Jonathan Hall:If you are a malware developer, we want you on the show to talk about this.
Shay Nehmad:Actually, would have someone anonymously interview on the show if they're a malware developer. Like, go through a voice filter thing. Sure.
Jonathan Hall:We could do that.
Shay Nehmad:Yeah. For sure. We promise to protect your anonymity and not share your IP with with any law enforcement agencies. We promise that. I don't know if we legally can promise that.
Shay Nehmad:We don't promise anything, but come on the show regardless. Alright. And if while developing your malware, you need to do some resource pooling, I found another pretty good blog post. This is you know, that type of blog post which is technical, but obviously was written by a company. So, you know, it does have value, but
Jonathan Hall:Wait a minute. Does this have Em dashes in it?
Shay Nehmad:You know what? You know what? That's a good question. I don't think so, but it does have, like, bullet points.
Jonathan Hall:It has four Em dashes in it.
Filippo Alsorda:What do you see?
Jonathan Hall:I just searched for an em dash and I found oh oh, two of the em dashes are part of the page footer. So there's two em dashes on the article.
Shay Nehmad:Okay.
Jonathan Hall:Pay only for usage space em dash space and then zero optional overhead space em dash space.
Shay Nehmad:Anyway, I don't know what you think about these blog posts. Normally, they suck, right? They're just like SEO bait that just restates obvious things from the Go documentation, right, and then slaps a company's logo on top. This one from LeapCell is not one of these, so I wanted to shout out LeapCell, I haven't used their services, so, but the blog post itself is pretty good about like, what is pooling and like, how would you do like, I don't know, SQL connection pooling, which is a problem a ton of people have to solve. And mostly the like best practices and how to handle exceptions correctly.
Shay Nehmad:And what I was mostly interested in is anti patterns, like what practices you need to avoid when implementing, you know, a resource pool, which is like, you know, you leak connections or you the pool size is incorrectly configured or, you know, you're not handling errors. And finally, they have like both a full resource handling pattern implementation in the blog post. And one that I was wondering if you were using connection prewarming. You're like, when the service starts up, you set up a bunch of connections ahead of time and you ping the DB ahead of time so, you know, they're ready. So when a request comes in, you just grab one other pool that's already ready.
Shay Nehmad:Do you ever do that?
Jonathan Hall:I have done that before. I haven't recently.
Shay Nehmad:Is it just cool or is it actually useful?
Jonathan Hall:It's it's useful if your connection startup time is is meaningful in your application, And it can be sometimes. So if you need really fast responses, you don't wanna wait for the connection startup, you know, the TCP handshake and all that stuff. It can save a few milliseconds.
Shay Nehmad:So I guess profile first before implementing everything in this article as gospel. But, you know, articles that are mostly code and most of the code seems correct, I can't argue with. So a pretty good article. Next time you need to implement resource pooling, just reach for this is like, I think, useful for beginners or if you just want to implement it without thinking too much, it's good idea.
Jonathan Hall:Well, I think that wraps up for the news today. Stick around. Don't go anywhere after the break. We are talking with Ian Lance Taylor about the last nineteen years ago. You will not want to miss this conversation.
Shay Nehmad:All right.
Jonathan Hall:I just said it was a blanket statement. I know some people will want to miss it for whatever reason, but you don't want to miss it. It's a blanket statement. It's true. You don't want to miss it.
Shay Nehmad:All right. I really enjoyed our conversation, so you should stick around. Cool.
Jonathan Hall:See you there. Thank you for listening to our amazing news segment that we haven't recorded yet. We really appreciate it. If this is your first time listening to the show, be sure to leave a rating or review wherever you listen to your podcast on, what is it called, iTunes or Apple Music or Apple Podcasts? I don't know what it's called these days.
Shay Nehmad:It's Apple Podcasts.
Jonathan Hall:Spotify or whatever. Apple Podcasts. Yeah. Okay. Or Google Podcasts.
Jonathan Hall:No, wait, that one's gone too. I guess it's called YouTube Podcast. I don't know what it's called. Anyway, we appreciate it.
Shay Nehmad:It's an RSS feed with m p three files. Don't let all the apps fool you. It's literally an XML file behind the That's all it is.
Jonathan Hall:Also, tell your friends, your colleagues, your coworkers, your fellow students about the show because we don't advertise. So your word-of-mouth is how the show grows and boy, it's growing. I keep watching the statistics and it's fun to watch that trend upward and to the right. On that note, we also have a new Patreon this week, Afari Daniel. Thank you so much for supporting the show.
Jonathan Hall:If you'd like to support the show financially to help pay for editing and hosting fees, head over to cupago.dev. There you can find links to Patreon, to our merch store if you want to buy a t shirt or a mug with our logo on it. You can find links to email us. You can find social media links for the show and probably for us individually. Yeah.
Jonathan Hall:Kind of everything about the show lives there at cupicco.dev.
Shay Nehmad:Yeah. So if you want to support the show financially, that would be great. Like Jonathan said, the money goes to editing and hosting fees and definitely not to us not optimizing our code and just having it run on really expensive machines in the cloud instead. Definitely not to that. Right?
Jonathan Hall:Definitely not.
Shay Nehmad:Sounds good.
Jonathan Hall:And speaking of a couple of Go. Dev, we got some feedback from one of your colleagues, Shai, about show notes, and you wanted to ask our audience what's important in our show notes. Why don't you take
Shay Nehmad:that Like, when you open the whatever app, let's say Spotify, it doesn't show you the whole show notes, it doesn't respect line breaks, and it doesn't render links as links. Our line break link summary of the show is very useful if you click into an episode, but it doesn't actually tell you what the episode's like about. And I don't know if most people listening are listening like on a weekly basis, just waiting for the episode and then listening to it sometimes during the week. Or if you, you know, pick and choose episodes every now and then. So we want your feedback in the Slack channel, we'll also send it as a question, like as a thread.
Shay Nehmad:What would you like to see in the episode summaries? As long as it's not too labor intensive, I we talked about maybe we could summarize in one paragraph what the episode was about, etcetera, etcetera, before putting all the link. I definitely wanna keep all the links in, but maybe that's also bad. Like, just let us know what would you like to see in the episode, like, summary, which is the text in the, like, Spotify or whatever app that that accompanies every episode.
Jonathan Hall:And then finally, next week our show is going be different. We're going to be recording a live episode. We won't be streaming it, but we'll be recording it live at Shai's meetup in San Francisco and it'll probably be released a little bit earlier. So if you're in the Bay Area, be sure to be there so you can be part of the recording. If you're not in the Bay Area, stick around till Wednesday or Thursday to listen to what happened.
Shay Nehmad:Yeah, and I was promoting it pretty heavily on the show being like, please come, I'm afraid there aren't gonna be enough people. And now I'm like, please come. I'm afraid there are gonna be too many people. I don't know. And if you listen to the show, I might have a because we have like, I don't know, 50 attendees.
Shay Nehmad:Wow. Which is That's impressive. Right? It's a good event. Sponsored by Elasticsearch, by the way.
Shay Nehmad:Thank you, Elastic. And it's gonna have a talk by a friend of the show, Josh Bleecker Snyder and Ishai Shaw. And also we'll we'll record an episode. So it's not just like a cup of go meetup. It's a proper go meetup.
Shay Nehmad:So yeah, that's gonna be a lot of fun. Link in the show.
Jonathan Hall:I think that's it for the the break here. Stick around. We'll be talking with Ian Lance Taylor about about go, I guess. That's kind of the Yeah. Makes sense.
Jonathan Hall:Yeah. Don't miss that.
Shay Nehmad:Hey, Jonathan.
Jonathan Hall:Hey, Shay.
Shay Nehmad:You know what's been driving me nuts recently?
Jonathan Hall:I do not.
Shay Nehmad:Golang.
Jonathan Hall:Oh.
Shay Nehmad:I hope someone on the Golang Nuts mailing list, number one active person could help me figure out what's going on with this language. Oh, hey, Ian. Hey.
Ian Lance Taylor:How's it going?
Jonathan Hall:Good. Thanks for taking the time to talk to us, Ian.
Ian Lance Taylor:Yeah. Thanks for having me.
Jonathan Hall:Wonderful.
Shay Nehmad:For our listeners who might not know you, do you mind, like, presenting yourself? People, we we have Ian Lance Taylor on the show. It's pretty cool. I'm Starstruck. But, you know, some people might not peruse the issues tracker often.
Shay Nehmad:So how about you tell people about yourself?
Ian Lance Taylor:Yeah. Sure. I've been on the Go team since, twenty o eight, actually, before the first public release. I mean, we all know, Go was started by Rob Cannon Robert in, twenty o seven as an internal, project at Google. I heard out heard about it maybe eight, nine months later and, got the good fortune to join the team.
Ian Lance Taylor:And I've been, working on it, really ever since. I recently left Google, but and I'm taking some time off, I hope to continue working on Go. It's a fun language and a fun project.
Shay Nehmad:Awesome. So the Go team has a lot of work. Developing a programming language. This you know, that's basically one of the top programming languages in the world and so fast, you know, in comparison. Just involves a huge mountain of work from testing to documentation to compilers to, performance work, network, like there's a lot of different aspects of the Go language.
Shay Nehmad:Your focus, you know, over time obviously changed and you did a ton of things, but what would you say was your, like, focus or or or specialty in in inside the Go language? Because I know, for example, you know, if we think about, Filippo, which we had on the show, he's like the, in my head, the person who does cryptography for Go. Right? Right. So what would you say is your, like what were your niches or your, like, specific focus area?
Ian Lance Taylor:Well, that's a great question because, my niche was to not really have a niche, think. I have worked on
Shay Nehmad:a lot of different aspects of it. I've worked on the compiler. I've done a lot of work
Ian Lance Taylor:in the library. I I worked on our second compiler, which unfortunately is a bit out of date now, the GCC front end and Goel l l v and LLVM front end, which we call Goel l v m. They haven't they are unfortunately, fallen behind. I've worked on a lot of the tooling around Go. I've worked on internal, Google support for Go.
Ian Lance Taylor:I've done a lot of work, more recently. I've been trying to do a lot more work on the, open source side, helping, contributors get their patches in. I mean, ex contributors outside of Google, I should say. Mhmm. And, participating in the proposal review committee where we look at people's proposed changes to the language and library.
Ian Lance Taylor:Also, have a language change committee where we look at people's proposed changes to the language itself. Almost all of those get declined, but we look at each one seriously and, consider what it offers. So, yeah, my niche I'd say, you know, when I joined the team, was doing a lot of work on this other compiler, the GCC front end, but also, you know, I just kinda try to understand, what problems we were gonna run into and, what, you know, what issues we needed to, tackle, what was gonna be coming down the line. I tried to get out of those things, Tried to work on where other people were not working. So, you know, at one time I did work on the runtime, but now there's a great runtime team at Google.
Ian Lance Taylor:I've barely touched the runtime in several years. So I've been moving around.
Jonathan Hall:Very cool. You've touched on some some highly technical stuff like I imagine building GCC Go was, you know, you had to really get in the nuts and bolts of things and more soft seal stuff like helping new contributors get involved. I can imagine a lot of projects or a lot of people at least would would sort of maybe naively think, oh, we don't want to waste a technical person's expertise and have them helping newcomers. Let's hire an intern to do that sort of stuff. But as a technical person myself, I can see how that probably wouldn't work very well because there's so much technicality involved in helping newcomers come along.
Jonathan Hall:How would you say your technical, your deep technical understanding of Go helps you work with people trying to contribute patches or proposals to the language?
Ian Lance Taylor:It's a good question. I think that, I mean, comparing what I've done with what I've seen other other people do, think, that the technical help comes in just being able to more quickly work with people. I mean, someone will send in a patch and I you know, a lot of patches are great. Some patches are not so great. And I think that knowledge of the library and the language, me look at these not so great patches and just very quickly say, this is not something we're interested in.
Ian Lance Taylor:Or I can say, like, this is really exciting and I know who the best person on the team is to take a look at it and I'll route it over to them. And, let me let me flip it around too. I've been in the I mean, when I started as a programmer, it was when free software started to come about. This was back in the late eighties. And so I've been a free software programmer for most of my career.
Ian Lance Taylor:Now people call it an open source programmer and so I'm sort of familiar with how the open source ecosystem and community works. Of course, it's changed enormously over time and really gotten a lot better than it used to be. But still, you mentioned like hiring an intern and it's always tempting to say like, okay, we should hire someone to do like a first pass over, issues or, contributions. But if you bring in someone who's not familiar with the open source community, we have found that there's a struggle a lot of people have to sort of fit into the flow of things, the give and take, the fact that it's all online where, it's very easy to come off as much harsher than you really intend. And so if you're not like, if you're not familiar with that, it can be hard to sort of, be effective, I So
Shay Nehmad:you said, you know, people it's hard to be effective in these, like, online communications for issues, open source stuff like that. It's hard. Do you feel like it's gotten worse recently, because of like AI LLM generation? I feel like a lot of open source stuff I'm seeing looks on the surface like it was written with more thought because it has like paragraphs and em dashes and titles. But when you look into the details, might have like actual hallucinations or just things that are wrong, both in pull requests, like actual code and in proposals and issues, just like, you know, discussion.
Shay Nehmad:Have you seen that uptick recently?
Ian Lance Taylor:On issues, I mean, yeah. Well, I mean, yes. I'm seeing what you're saying, what you're what you're what you're talking about. On issues, it's not a big deal, I think, because, yeah, there's more text you gotta get through. That's the worst part of it.
Ian Lance Taylor:People are writing longer things. But on the other hand, in the past, people sometimes wrote too little. But you still can, dig into the core of the proposal or the issue. I don't think it's had a very, very large effect there. But on, pull requests, yeah, absolutely.
Ian Lance Taylor:There's more pull requests coming in where people are like and sometimes they don't even say what they're doing. But sometimes they at least will say, you know, yeah, we ran this code complete on this thing and it suggested this change and you look at the change and you know, it's it's just churn or it's nonsense and so you do have to it has it does take time. You do have to come in and just say, know, like, no, this is is not gonna help us and, let's just move on. I wanna mention code churn is a particular issue that is, you know, both with LLMs and without LLMs. People often look at a piece of code, you know, which has been in the standard library at this point for like, you know, ten, fifteen years and they'll say, oh, I could write this a little bit better.
Ian Lance Taylor:And, you know, it's sometimes it's a little bit better. Often it's a little bit better. But the fact is, with code that's that old, you know it's working because no one's reported any bugs on it. So the only thing a change can do is make it worse, make it break. And so unless there's some real clear performance advantage or some really dramatic readability advantage, then those changes are are just churn and not desirable.
Ian Lance Taylor:Well, there are
Shay Nehmad:there are two effects, you know. It it might break something that already works. It might like create more work for the language maintainers, but you're forgetting the really important part. It's gonna help the person, you know, bolster their CV. Isn't that what language maintenance really is all about?
Ian Lance Taylor:Yeah, yeah, maybe so. Maybe so.
Jonathan Hall:Well, on that point, let's suppose somebody is trying to bolster their CV or just make the language better for some legitimate reason. It's not just churn. Can you offer any advice or tips for people who are trying to contribute to Go? How do they get started? I mean, there's the guide you read, gives you the technical steps involved, but like from a cultural standpoint, how do you get an issue looked at?
Jonathan Hall:Because there's so many thousands of them out there and there's not time to really triage every single one thoroughly. How do you get a portal quest looked at? What advice can you offer? What would make your life easier when you're looking at one of those things if I were trying to get your attention on that?
Ian Lance Taylor:If you were trying to get my attention on fixing an issue or if you were
Jonathan Hall:not specifically, but the the Go team. I have an I have an issue I want looked at. What do I do to make it easy for you so that it's it doesn't get lost in the weeds?
Ian Lance Taylor:Well, for for a bug report, you know, try to follow the template as much as you can. Even though it seems like like it's just boilerplate nonsense. A lot of people just get rid of the template, fill in what they think is important. And then, you know, the first responses that we have to make are, you know, we need to know this, we need to know that. Mhmm.
Ian Lance Taylor:And the template's there for a reason. And and yeah, it's it's a lot of information there that is almost certainly unimportant for your particular bug report. But, you know, we're we're asking for that information because we've discovered over time that we need it. And maybe we don't need it for you, but we need it for the next person. And we don't know which particular piece of information we need from you.
Ian Lance Taylor:Then of course, the next, besides filling out the template, you know, tell us exactly what you did and tell us exactly what happened and tell us what you expected to happen instead. Those are the three issues that every bug report, every good bug report should do. Mhmm. And, it sounds so obvious when you put it like that. And yet many people don't do it.
Ian Lance Taylor:For many people, especially the problem is, you know, they've been looking at this bug, they've been pounding their head over it and they're like, they're finally said, this is a bug in Go. It's not a bug in my code. And so I'm gonna report it. But they know so much about it that they just put in what's on top of mind when they, fill out the report. So, you know, just go back to the basics, you know, or or it's like the rubber ducky bug report.
Ian Lance Taylor:Like, the bug to your rubber ducky so that your rubber ducky understands it. And that's what we need. Even though we're, you know, supposedly the experts, we still don't know what you're thinking and we don't know the thought processes that you've already gone through. And so help us help you by, explaining, you know, explaining like to a rubber ducky or explain like I'm five.
Jonathan Hall:Good advice. I'm curious. You probably don't have statistics on this, but maybe you do. What percentage of bug reports are invalid? You know, they they weren't a bug and go.
Jonathan Hall:They were never reproducible, things like that.
Ian Lance Taylor:Yeah. I don't have statistics on that. I would guess just off the top of my head, I'd say maybe twenty five percent are, invalid. Most bug reports, you know, even though I'm complaining about them right now, most bug reports are actually pretty good.
Jonathan Hall:That's impressive. Yeah.
Shay Nehmad:I would have expected the majority to be to be invalid in some way. That's cool. I've had a few cases where, not with Go, but with, like other software, you know, I would start writing a support ticket or reproduction and then suddenly I would realize like what I was doing wrong as I was typing it.
Jonathan Hall:Of course. Yeah.
Ian Lance Taylor:Yes. Absolute that's it. I mean, that's that happens a lot for me too. Absolutely. You know, you're finally like, this is a bug, and then you start writing down, going back to the basics, right, and everything you did, and it's like, a second.
Ian Lance Taylor:Actually
Shay Nehmad:Wait. Didn't I change directory? Oh. Oh, right. But usually you end up with either, like, it's really just a boneheaded move on your part and then you're like, oops.
Shay Nehmad:But many times it turns like a bug into like a feature request. Like, hey, if I'm running the street from the wrong directory, can you please like tell me so I realize what I'm doing wrong? Stuff like that.
Ian Lance Taylor:Yeah. And I personally find those bug reports very helpful when someone says, you know, I was following down this path, this well lit path and, you know, suddenly I fell into quicksand. And there's especially if you can recommend like, if you had said in the documentation here, you know, that this was gonna happen, that would help if you had just had some message here. You know, not all of those are helpful. Sometimes it's too much.
Ian Lance Taylor:Sometimes it's like you should have looked at this other documentation. But you know, especially if you can say like, if you had just added like one sentence right here, I would have been better off, then that's a great bug report or just send in a patch, you know, add that sentence. That was really helpful. It's helpful for it's helpful for us. It's helpful for the next person following that path.
Ian Lance Taylor:I'm curious, looking back over the
Jonathan Hall:last nineteen years, is there anything, that really stand out to you as a favorite project or problem you solved? Anything yeah. Anything that just stands out to you that that's, worth mentioning?
Ian Lance Taylor:Wow. It's a great question. Well, I mean, it's I think I have to say generics
Alex Scheel:for
Ian Lance Taylor:that because I spent a disturbing amount of that nineteen years working on different proposals for generics. You know, some of them were published but I had several early proposals that were so bad that they didn't make the light of day but I still put a lot of time into them. So generics, as I'm sure most people here know, did finally make it into Go in the 01/18 release. But, you know, we started I started especially working on it Right about the time that we did our first public release of Go in twenty o nine and, you know, off and on, you know, especially with Robert Grisamer who did a ton of work
Jonathan Hall:Mhmm.
Ian Lance Taylor:On it. Took us a while to really get to something that was, good enough.
Jonathan Hall:How how do you feel about the results? I think in general, generics have been well embraced, but there's always always somebody complains about this or that, you know, ergonomics aren't quite what they want or maybe it's not as flexible or whatever. How do you feel about the result, with with Ghost Generics?
Ian Lance Taylor:Yeah. Thanks for the question. I feel good about it, honestly. I think there's still a little bit of polishing and sanding that, could be done in the language. A little bit of type inference could be better and certain aspects of it aren't quite aren't not not that they're wrong but that they could be improved.
Ian Lance Taylor:But these are really details that don't notice until you really get into the weeds of it. So I don't think it's completely done, but I'm really quite happy with It's not as it's obviously not as powerful as C plus plus templates and, honestly that's a good thing for me. I think it really, it really does the job and, it doesn't get in your way. So I'm really happy with where it wound up and you know, it's by no means is it just me who did that. I mean, as I say, Robert Griesemer did a ton of work on it.
Ian Lance Taylor:He had a lot of the key ideas of his and Russ Cox also and obviously the implementation I barely touched personally. So, Keith Randall and Hans Gales, a lot of other people working on that. So it's been a it's been a, you know, a whole team effort. Mhmm.
Shay Nehmad:You think that the language evolution part of it, of generics and other things, you know, that got into the language in a while. I what I'm trying to understand is how do you decide when a language feature is go ish enough? You like mentioned the C plus plus templates and every fiber of my being was like, oh no, please not because I used to work on those like with the 12. It was just horrible, it was so hard, at least for me, I don't know, maybe smarter people than me can figure it out, but it's just super complicated. It is, you're right,
Ian Lance Taylor:it is super complicated.
Shay Nehmad:What's the cutoff point for a feature to be go ish enough, you know, like simple, not introduce too many keywords, not be complex enough, but it is the language does evolve. It does introduce new features.
Ian Lance Taylor:Yeah. It's a great question, and there's no simple answer. When, Rob and, Ken and Robert started the project, they had a pretty simple approach, which was they didn't add anything to the language unless they all three of them agreed that it should be added. And so that, consensus driven approach has been a big part of how Go has evolved over time. You know, we're not gonna we're not gonna add something to the language if there are if core people on the team are strongly opposed to it.
Ian Lance Taylor:So that's just a general guideline. And then more specifically, yeah, how do we know if it's simple enough? I mean, I think that simple is a guiding feature here. Simple for the reader, especially. We want the person reading the language to know what's gonna happen.
Ian Lance Taylor:We want Go to be I'm not sure what the right word is. We want it to sort of feel familiar to programmers. We don't want, you know, we don't I mean, obviously, it's, you know, it's it's a programming language. You know, the average person who is not a programmer looking at Go is not gonna have any idea what's going on. But we want someone who is familiar with other languages to not find it surprising.
Ian Lance Taylor:I guess that's maybe so there's so be simple. Don't be surprising. We don't wanna catch people by surprise. I know there's aspects of the language where we're not successful in that and that's unfortunate.
Shay Nehmad:So this is what makes a feature like Go ish enough. Want it to be familiar to programmers, you want it
Ian Lance Taylor:to be simple, and all
Shay Nehmad:the core team members have to agree on it, which I think are really good benchmarks because they're on the one hand, they're soft enough that, like, you know, you could bend the rules around the specific feature if it all, like, makes sense. It sounds like if it introduces three keywords in one pull request, like, we're not introducing it. But it does seem to make a lot of sense.
Ian Lance Taylor:Yeah. And let me mention, obviously backward compatibility is essential too. I mean, Rob, really pushed this in the early days. He said, you know, we're gonna be really strict on backward compatibility and we've, we've really taken that on, such that, in the whole time since the, Go one point o release, we've made only one change that was not backward compatible and that was a loop closure change and we put we put years of effort
Shay Nehmad:Mhmm.
Ian Lance Taylor:Into making that work. David Chase and, Russ Cox in particular, but a lot of other people too to make sure it was the right thing to do and, do it in a way that was, safe and, so worked for the whole ecosystem.
Shay Nehmad:Yeah. When when I started with Go and someone asked me for, like, can you explain what backward compatibility is? I only had one example, which was the Win 32 API. And in the years since then, now I have two. Like, I've worked enough years and you know what I mean?
Shay Nehmad:Yeah. Thanks. But but it's I don't know. It's it's super diff it's such a disciplined requirement. Like, I wouldn't be able to hold up an API Mhmm.
Shay Nehmad:To that standard, I think.
Jonathan Hall:So that reminds me of a question. This is a question we asked, I
Shay Nehmad:think in the first year of all of our interviewees, but I wanna ask you because, I
Jonathan Hall:think you have a unique perspective having been at Google for so long, working on Go. Aside from the loop closure thing that was, I would say, we could agree was a mistake in the original iteration, are there any mistakes that you would say have made it into Go? Something you wish you could go back nineteen years and remove of any sort, whether it's something in the
Shay Nehmad:standard library, a language feature, anything?
Ian Lance Taylor:Yeah. I'll give you two. Okay. I think that a lot of people get confused that when you store a nil pointer into an interface value, the interface value is not nil.
Jonathan Hall:Mhmm. Mhmm.
Ian Lance Taylor:The interface value is instead a non nil interface that holds a nil pointer. And I have no problem with that, but, I mean, I think that's correct for the language. I think that's how interfaces should work. But the fact that we used nil for both the zero value of a pointer and the zero value of an interface, I think I've it feels to me like that's kind of what's led to this ongoing confusion. If for example, we had had new interfaces and null pointers, then, you know, yeah, we'd have had an extra word.
Ian Lance Taylor:I don't know if that's the right answer. I don't I mean, I don't know what the I don't know if there is an answer. At this at this point in language, there's probably no answer, but I wish that we had found you know, I think for us, it was always so obvious. Yeah. Of course.
Ian Lance Taylor:The interface can hold any value. It can hold any pointer. It can hold a nil pointer. And that's you know, we didn't find that confusing, but it's clear that many people do many people new to the language find it confusing. I wish we had found a different way forward for that even if I don't know what that way is.
Jonathan Hall:I love that answer.
Ian Lance Taylor:And the second thing I will complain about is I don't I mean, it's just personal. I don't like naked returns. I think named result parameters make a lot of sense, but the fact that you can just say return without listing the values you're returning, I think it's just a little confusing. It's fine in an incredibly short function, but
Shay Nehmad:Yeah. Jonathan is smiling because he made a video, I think the top 10 worst thing about Go, and I think it was like, it was definitely up there.
Jonathan Hall:That's how I choose my friends. People who make Naked Returns, they're in my friend list.
Shay Nehmad:And, you know, recently on a programming Slack, I don't think it was the Go one. It definitely wasn't the Go one, it was like some other one. Does anybody know of a feature of a language where I can just return my things without naming them at the end because I wanna keep my things more concise? And I answer like, Go's naked returns, but universally people don't really like them. Maybe don't save on on a keystrokes.
Jonathan Hall:Yeah. Well, let let's flip that around. Is there anything you think is important to add? I know you've you've written proposals. I I read one of your more recent ones about error handling with a question mark.
Jonathan Hall:In your opinion, as of now in May of twenty twenty five, what's the biggest missing feature in Go that that if you could snap your finger away, wave at one and make it appear, what would it be?
Ian Lance Taylor:Yeah. Great question. I mean, as you say, have I have been spending time work on error handling, but none of those none of those proposals have flown. And and it may be, I think that we're gonna we're just gonna say we're gonna live with it even though it is one of the top concerns about Go in our surveys. When I say top concern, it's still only about 13% of people expressing it as a major it's their top concern.
Ian Lance Taylor:So there's just something about error handling in general that I think could be addressed in some way even if we haven't figured out what the right way is. It's not just the it's not just the syntax, which as we all know is a little bit, boilerplate y.
Jonathan Hall:Mhmm.
Ian Lance Taylor:I I mean, I've got no problem with, the sides of it. It's just the fact that it's the same thing over and over again that I wish we could do better on. But then there's also the issue of, it's a little too easy to forget to check for an error. Mhmm. And, you know, you feel you fail to check for an error, you just carry on and then something goes wrong later on and it's hard to understand what happened.
Ian Lance Taylor:We don't have good tooling to say, oh, you forgot to check for the error here. We don't have good mechanisms for that. And then, of course, there's the perennial conflict between, oh, I want stack traces for all my errors and I want simple errors. We use errors for multiple purposes. We use them both to report to the user what went wrong and we use them to report to the programmer what went wrong.
Ian Lance Taylor:We want different kinds of information for both of those cases. There have been several good ideas, like Austin had a good one, a while back. Again, you know, we haven't quite figured out, I think, what the what the best thing is. So I'm just gonna say, I mean, just the big ball of wax, error handling. I don't have an answer.
Jonathan Hall:Mhmm. Okay.
Ian Lance Taylor:Although there is an error Maybe that we'll never have an answer. We're just gonna we're just gonna go forward with this, but that's that's what I'd say.
Shay Nehmad:Well, although there is AirCheck, like, is that linter program thing that I don't know. Jonathan and I are think pretty unanimous on this, that the one of the first things we'll do on every Go project that we work on is, add Golang cilin with some default linters that do a pretty good job and error check is definitely one of them. Like, don't remember a case where I forgot to handle an error just because my that linter always did it. That doesn't solve for the like extra information and stack trace and make sure you're raise returning the right errors, etcetera etcetera. But it does solve for not forgetting to check ones.
Shay Nehmad:Right?
Jonathan Hall:There are some corner cases where it misses it. I'll I'll say.
Ian Lance Taylor:Yeah. That's great. And maybe we can figure out the right way to incorporate that into the ordinary Go flow.
Alex Scheel:Mhmm.
Ian Lance Taylor:Make it part of Govat or something like that.
Jonathan Hall:Yeah. So Ian, you've been with Go and Google for nineteen years. Looking back, what are your general thoughts?
Ian Lance Taylor:Yeah. Go has been an awesome project to work on. I'm so I'm so pleased that, the original Go team members, you know, welcomed me onto the team, and gave me the opportunity to work on this. And it's been great. I mean, as I think I've said in, in the past, I don't think any of us at the time expected it to be this successful.
Ian Lance Taylor:I mean, sure didn't. I think our dream, my dream, our dream was, we have some good ideas here and other languages will pick them up.
Jonathan Hall:Oh, yeah.
Ian Lance Taylor:And, they'll, you know, just this very simple concurrency, you know, the simple syntax if you know, we just figured, you know, let's get this out there. Let's let people try it. Let's let them pick those ideas and add them to other languages. And in fact, you know, some Go ideas have been added to other languages, in, in the time that Go's been out there. But the fact that Go itself became so successful, that was just amazing.
Ian Lance Taylor:I remember the first time I went to, GopherCon, the first GopherCon in Denver. And I mean, it was much smaller than it is now but it was just amazing. There were hundreds of people there who were happy Go users. They were so happy to use Go that they're willing to come to a convention to talk about using Go. And that was just an incredible experience.
Ian Lance Taylor:And, yeah. So I'm really grateful and, happy that I've, been able to work on this and, I plan to continue working on it.
Jonathan Hall:Great. I do have a follow-up question based on that. It's pretty hard for, I think, any of us on this call to answer objectively because we all use Go and you in particular. But do you think it's a good thing from like an ecosystem standpoint that Go was adopted as is more or less rather than people taking those ideas as you had originally intended or originally expected, would the programming ecosystem at large be better if they had just taken good ideas from Go or is it better because they adopted Go as a primary language?
Ian Lance Taylor:Well, I'm obviously incredibly biased I think I, you know, I think that Go is a good language. We've talked about some corner cases where it's not great. But, yeah, overall, Go I think Go is a very good language. I think it's the best language that we knew how to make it. And, you know, I don't wanna say we, I was a pretty small part of that we, just to be clear.
Ian Lance Taylor:But, yeah. So I think it's even though I didn't expect Go to be so successful, I think it's a good thing Mhmm. That it's so successful. But I say that while acknowledging my enormous bias.
Jonathan Hall:Sure. Of course.
Shay Nehmad:I think if they wouldn't have been that deeply adopted, it would have been hard to invest so much time into developing the more nuanced ideas. Like, you know, you talked about the hard skills and the soft skills before. Right? Just the way that Go manages its open source thing, and I remember that moment, I think it was two years ago with the opt in versus the opt out telemetry. That was like, every programming language in the future that's gonna be like, oh, we wanna add telemetry.
Shay Nehmad:They can just look at Go and and learn from that. And if the language wasn't that well adopted, and widely adopted, I should say, that wouldn't have even been an issue. Like, people add telemetry to Go and it's, you know, some niche of programmers, programming language experts language, and not just a programming language, people wouldn't even care. So, you know, these contributions I think are way more valuable to the programming community at large, other than all the great software which was already written in Go and even the bad software which is written in Go.
Ian Lance Taylor:Yeah. Thanks. And in that same vein, I would say, you know, Go's module proxy and Go's support for software build materials. I think those things, I think, you know, Go's package management in general. A lot of these ideas were originated by Russ Cox, by the way, who's just has brilliant insight into these, into these ecosystem issues and always has.
Ian Lance Taylor:And, I like to think that Go is showing a good path through these complex, through these complex topics. And I, you know, maybe not perfect, but I hope that other people will, will see where see the good ideas that Go is using, Go has, providing and adopting them like with telemetry, as you said. And I think telemetry was an interesting example where, you know, we originally were saying, let's do, opt out, but, then it became very clear from the community feedback that opt in was the way to go. And, I think telemetry has been quite successful, with, identifying, you it only helps with a certain class of problems, but it's been very great on that certain class of problems.
Shay Nehmad:One, rapid fire question from me before we do the usual stumper question. Go one dot x forever or go to someday?
Ian Lance Taylor:Go one dot x forever. If you look at other successful languages, I mean, some do a major version upgrade, many of them don't. I mean, there's no c plus plus two point o. There's no Java two point o. And, I don't see any reason for a Go two point o.
Ian Lance Taylor:We are doing, as you know, we're doing v twos on the libraries. I mean, we've done one v two on the libraries and we'll do more, but, we don't need to I think we're stuck with our bad decisions forever.
Shay Nehmad:And the good ones.
Ian Lance Taylor:And the good ones. Alright.
Shay Nehmad:Don't you want to change print? It'd be like print with a space instead of a parens? Isn't that worth a major a major language upgrade? Sorry. Sorry, Python.
Shay Nehmad:Sorry. I didn't mean
Jonathan Hall:to. Alright. Yeah. Let's let's wrap it up here. So I'm I'm really curious to hear your answer to this one, Ian, because I think you could you could be the answer to this question for many people who come on the show.
Jonathan Hall:The question is, who has been most influential to you in your Go journey?
Ian Lance Taylor:Yeah. It's hard to pick just one person. That's okay. But if I did pick one person, it would be Rob Pike. Mhmm.
Ian Lance Taylor:He's, he's really, he was, really drove the Go project, especially in the early years. He's not so involved these days and, has just remarkable insight into, based just, you know, the problem of programming and, never really wanted to settle for anything that wasn't perfect. I've learned a lot from him. I don't think I've ever learned how to think the way he does, but I've always been impressed by him. And then I'll also say, know, just, I mean, you know, the other people from the start, Ken Thompson, Robert Griesemer, Russ Cox, I've learned a lot from all of them in different ways and I hope it's made me a better programmer.
Jonathan Hall:Great answer. Appreciate it. If people are interested in getting in touch with you, is you have a social media presence or you like to live under a rock and don't wanna share that information?
Ian Lance Taylor:I I basically don't have a social media presence.
Shay Nehmad:Okay.
Ian Lance Taylor:I mean, you can always email me. I'm happy to email you. Ent@golang.org is my, is my go oriented email address and, yeah, no, I've got nothing against social media. Just don't
Jonathan Hall:You have a life probably more than I do. So
Ian Lance Taylor:I don't know
Jonathan Hall:about that. That's fair. All right. Well, hey Ian, I wanna say once again, my my deep thanks for everything you've done to help make Go the language that I enjoy working with every day. And thanks for taking the time to come talk to us about it here on the show.
Ian Lance Taylor:Well, thanks for having me. It was fun. And, yeah, it's a it's a it's a fun podcast and I, hope you guys can, carry on. Great. Thanks so much.
Shay Nehmad:Well, Ian is off the call. I just, have to say I'm really excited that we had someone who contributed so much to go on the show. I wonder how long it'll take and how persistent we'll have to be to just cover like all the, you know, all the lines of Go that have been contributed with people on the show. We can get a % Go coverage, But we definitely bumped up our, CapoGo
Jonathan Hall:It's a vanity metric, man.
Shay Nehmad:But yeah, man, that was such a such an influential character. And, you know, so many people have said it already online, but just a a really big contribution to a language we all, are interested in, to say the least. That does it for, this week's episode. Next week's episode is gonna be slightly all over the place, like we said, because we're gonna record it live. But for now, program exited.
Ian Lance Taylor:Program exited. Goodbye.
Creators and Guests
