New rule: Every rule exists to be broken. (except this one?)
This show is supported by you. Stick around till the end break to hear more about that. This is Cup o' Go for 05/29/2026. Keep up to date with the important happenings in the Go community in about twenty minutes per week. I'm Shay Nehmad.
Jonathan Hall:And I'm Jonathan Hall.
Shay Nehmad:And I'm back.
Jonathan Hall:You're back.
Shay Nehmad:Back Is
Jonathan Hall:it already May 29? It's almost June.
Shay Nehmad:Yes. It's yesterday was, like, raining buckets in the in San Jose, and my daughter was like, when is it gonna be summer already? I was like I was like, Monday. Yeah. I I've been on vacation, and now I'm back.
Shay Nehmad:That's awesome. Thanks a lot, Miriah, for covering for me. Oh, yeah. Was really good. Was a
Jonathan Hall:cool one. Sounds like I might have convinced her to come to GopherCon.
Shay Nehmad:Oh, no.
Jonathan Hall:If you're going there, you might you get to see me and Miriah there.
Shay Nehmad:Not planning to go, but I might be convinced too.
Jonathan Hall:Oh, but you won't be convinced. You've been saying that.
Shay Nehmad:Yeah. When when it's on the moon, maybe.
Jonathan Hall:Oh, right. Speaking of conferences.
Shay Nehmad:I joined the Telegram group for GoConf, that Russian conference we spoke about last year. Luckily, my Russian is good enough that I can, you know, differentiate them just a random message from an announcement message. And they announced a new GoConf in Moscow. It's gonna be September 11. So they're gonna have another GoConference in Russia and Moscow.
Shay Nehmad:So if that's relevant for you, you know, go check it out. It's all the previous talks are on YouTube, so I assume it's gonna be this this time as well. And, you know, the call for papers is still open, so you can submit it. The site is obviously in Russian.
Jonathan Hall:I assume that means all talks are in Russian as well.
Shay Nehmad:Yeah. This seems like a fully Russian thing. Yeah. It's happening in Moscow and and everything. And, yeah, September 11.
Jonathan Hall:Very
Shay Nehmad:cool. I do wanna say, like, this is not any the show is very not political. We're not, like, supporting Russia or supporting Ukraine or anything like that. There's a Go conference there. I assume there are gophers there.
Shay Nehmad:They might even listen to the show. If you're Russian and you're thinking about you don't know about conferences, this is our way of informing you and, you know, zero politics related.
Jonathan Hall:Yes.
Shay Nehmad:And it does look really good. There's gonna be like 300 people. The pictures from last year seem like it's a really fun, sort of a serious, like, you know, capital c conference, which is really cool.
Jonathan Hall:Cool. Let's talk about some proposals. What do you say?
Shay Nehmad:Yeah. I wanna I wanna get back into the swing of things. I haven't, like, tracked the performance tracker in almost a month.
Jonathan Hall:Yeah. Yeah. So a couple proposals. One that's was just accepted and one we'll talk about in a moment that's a new one that kind of excites me. But the accepted one, this is one that's probably not gonna affect most of our listeners on a day to day basis, but it's it's kind of an important one.
Jonathan Hall:It's about the Go debug flags. Do you know what those are, Shay? Have you ever used one?
Shay Nehmad:I think so. You, like, say Go debug equals one or something, and then it turns on some deep I'm sure I used it once because I remember. So
Jonathan Hall:GoDebug is used for you know, I don't I don't think I've ever used it, but it's used for certain features that are maybe kind of experimental or or temporary or maybe one needs a backward compatibility. So I I'm pretty sure there was a Go debug flag related to the the range variable thing that was fixed in what was it? Go one twenty one. Variables were reused, and now they're not. If you need the old behavior, I think you can toggle that or maybe you could with a GoDebug flag.
Jonathan Hall:I don't know exactly. Clearly, I don't use these very often. But the point of this issue that has been accepted, the proposal, is nobody else really keeps track of these. There's a whole bunch of old, stale GoDebug flags sitting around, and there has never been an informal policy on what to do with them when they're not needed anymore. So that has changed.
Jonathan Hall:There is now a formal policy, and they they go through four classes of debug flags. Those are simply no longer used anymore. Irrelevant. The ones that are still in use but have a documented safe to relieve to remove after date, those that are that exist but are not documented with a date, and those that are documented explicitly with a permanent, like, this is forever thing.
Shay Nehmad:So what you're saying is this is not now I understand the proposal correctly. This is not about removing GoDebug. GoDebug can have a certain set of values, and this is about, okay, once we're done with one of these debug values, we should get rid of it.
Jonathan Hall:Right. So this this is basically the Go Issue Tracker version of why are all these AB tests still sitting around in production sixteen years after we stopped using them?
Shay Nehmad:Man, decommissioning feature flags is one of the best feelings. You just end up deleting a whole lot of code, whatever. But I love how programmatic it is. Like, yeah, sometimes these debug feature flags are gonna be here forever. And it's just like, they they do they are permanent.
Shay Nehmad:How are we gonna track all of all of these debug flags then? Because this is already accepted.
Jonathan Hall:So there is an official list of GoDebug flags, and it's on the go.dev/doc/godebug. If you ever wanna know what they all do and which versions they're added and supported in, just head on over there and you can find the the full current list. And so the the proposal now affects basically the deprecation of and the life cycle of deprecating the debug flags that
Shay Nehmad:Got it.
Jonathan Hall:Don't need it anymore. Yep.
Shay Nehmad:So this this is will also end up probably deleting a lot of flags and just simplifying the internal Go code?
Jonathan Hall:I think I think that's the goal. Yeah.
Shay Nehmad:Nice. I'm I'm I'm so down.
Jonathan Hall:And maybe even more important than this, like, cleaning up the code, it's just now everybody has an expectation of what's gonna happen with this. And that is that basically each Go debug flag is guaranteed to last at least two years. That's four release cycles. So you if you're using it in production, you have at least the idea that I can be certain that this is going to stick around for at least two years and I don't have to, you know, revisit this every every Go release to see if my feature flag was or my my GoDebug flag was was deleted.
Shay Nehmad:Got it. Looking at the debug flags themselves, do you look at, like, interesting corners of the runtime, I feel.
Jonathan Hall:There are some interesting things there on that list for sure.
Shay Nehmad:So it's a bit random, like HTML meta content URL escape and trace back labels for the runtime preprof and crypto custom rand and decorate mappings. And it's like, it's a bit of an everything salad.
Jonathan Hall:Yeah.
Shay Nehmad:But cool. This sounds like a great improvement. It sounds like the sort of thing that would be hard to track, but worth the effort, I guess. And what's the second proposal you mentioned?
Jonathan Hall:The second one, this this proposal was actually created back in 2021, but it was just recently added to the backlog, which means it was getting serious attention right now. And it's a new version of a previous proposal for Go two that was opened in 2017. That one's been closed because Mhmm. Go to, you know, whatever. But I I like this proposal.
Jonathan Hall:Have you ever had to create a type just so you could add an interface method to a function?
Shay Nehmad:Those were many words. Have I ever had
Jonathan Hall:So let's let's give it a concrete example. You've used HTTP handlers, I imagine, in Go.
Shay Nehmad:Yes. All the time.
Jonathan Hall:Yes. And you might be familiar with the fact that the HTTP handler type is just a function type that has a method on it that calls the function itself. Yes. Isn't that annoying?
Shay Nehmad:Yes. Now I understand what you're saying.
Jonathan Hall:So the proposal is what if we could just wrap that function itself in the in the type declaration and then poof, it satisfies the interface rather than having to create this extra type just to add a inner a method that calls this the type itself. That makes sense?
Shay Nehmad:Yeah. Like, you you add a separate type, but the only thing you care about is the function. Like, why do you need a separate type, basically? Right. And you need a separate type as as the receiver.
Shay Nehmad:Right?
Jonathan Hall:You need a separate right. You need a separate type so that the function that matches the method satisfies the interface. So the proposal is let's let's extend the language so that you can just treat that function literal as the interface as satisfying the interface so that HTTP handler func that we've all seen could just go away. You could just call h t p dot handler and pass through your function. It could be a function literal.
Jonathan Hall:It could be an anonymous function, a closure, whatever, and it would just satisfy the the interface. So that's the proposal. Of course, this is the Go community, and we're nitpickers. There's a lot of nitpicking going on, although it looks like it's headed the right direction. By that by that, I mean, headed towards likely acceptance.
Jonathan Hall:But some of the nitpicking is like, does this break interface definitions? If you have an interface with a single method on it, does this add the possibility that adding another method on the interface would would break your contract and so on and so forth? But I don't see any deal breakers here from my reading of it. Think this is likely to go through,
Shay Nehmad:but we'll see. And once this goes through, if I understand it correctly, you could if you see a type that's only used to define the receiver so the method lines up with the interface, like you said, you could just delete it. Right? So Go modernize the Go modernize or, like, Go fix would be able to automatically fix it. Or am I
Jonathan Hall:I believe I believe that's correct. Yeah. So I I think the net HTTP package, for example, could add a little GoFix syntax there that says just call this other thing instead. And then if you run GoFix, poof, all your calls to http dot handler funk get shortened to HTTP dot handler.
Shay Nehmad:Cool. And, I mean, it makes the code a little more concise, but it does do the thing that Go doesn't super love, which is two ways to do the same thing because you would still be able to do the old way. Right?
Jonathan Hall:It could. It could. And and, of course, legacy code would. And if you ever have an interface with two or more methods, you have to do the old way because there's there's an ambiguity then. Right?
Jonathan Hall:This only works for single method interfaces. But one of the points made in the proposal, which I think is a good one, is that this actually makes your code easier to read. Aside from dropping the word func from your call, you don't have this this indirection of, like, what is this function I'm passing? What is this other type I'm defining? What does it do?
Jonathan Hall:We have to go look that up. It's it just makes it more clear exactly in line, especially with a closure or something. You don't have to to figure out what's going on over there and that other type, because it's all defined right there at your single call site.
Shay Nehmad:I'm wondering why did this pick back up like this was starting to this made the rounds in 2021?
Jonathan Hall:Yeah. That's when it started.
Shay Nehmad:Why was this, like, placed on hold? Oh, it was waiting for a prototype. No. I don't understand, like, the life cycle of this. Why did this come back to life?
Jonathan Hall:It's a good question. So back in December 27, there was a comment, what needs to be done to move this proposal forward? And then crickets. Meanwhile, there were a few things that referenced it, but they're all closed PRs and so on. And three weeks ago, someone started the discussion again.
Jonathan Hall:Two days ago, it was added to the active column. So I don't know. Somehow, got the attention of the Go team in the last Mhmm. Three weeks apparently, and they decided they had the bandwidth to discuss it. So I'm happy to hear that.
Shay Nehmad:Okay. Cool. Cool. Cool. I wonder like, this is the sort of thing that at this point I know this is, like, bad form to say, but, like, you know, maybe my agent care more about it than me.
Jonathan Hall:Fewer tokens for your agent to worry about this way.
Shay Nehmad:Yeah. You know what? Maybe. Final thing I wanted to talk about today, at least in the news section, is a good blog post that I think it will take us a little while to dig through called the top 10 Go error handling commandments. This is from Preslav Raschev.
Shay Nehmad:And when we both read that name while working through the script for this episode, we're like, wait, this sounds familiar. Do we have this person on the show or no? And we didn't have him on the show, at least not yet, but we we did talk about a couple of couple of blog posts he wrote in the past. And when I say the past, I mean the distant past. Episode 23, 07/07/2023, and episode 42, 12/01/2023.
Shay Nehmad:So eons ago, we talked about great blog posts that Treslov has written. Seems to be way into error handling. He wrote a few already alongside Redo Whann, which we did have on the show.
Redowan:Hey. I'm Redowan . I'm currently working at Vault, which is kind of like a European sister concern of DoorDash in The US. So, yeah, I've been doing open source for a long time and working here for around, like, two years, and I primarily work with Go.
Shay Nehmad:We have a lot of opinions about it, and he sort of compiled it into what he calls the 10 commandments for Go error handling. And I I wanted to, like, work through them and see if you agree.
Jonathan Hall:Because Okay.
Shay Nehmad:I'm I'm always sort of worried about hard and fast rules, like never do a thing. Right? Yeah. Most of these seem pretty reasonable.
Jonathan Hall:Okay.
Shay Nehmad:The first one, thou shall not ignore errors.
Jonathan Hall:Agree or disagree? Is that is that it? Is it just agree or disagree?
Shay Nehmad:No. It's like he has the explanation. It's basically, don't ignore errors. Treat that branch as part of the program, not a ceremony to be skipped.
Jonathan Hall:So in general, I agree. Although there are exceptions, and and his description here says, if a call can fail, that's the exception. Some calls can't fail or they can't that can't fail in your context. If you know that, if and it's obvious from reading the code, then I'm okay to skip the error. It's often not obvious from context, in which case I think it's safer to return the error so that it doesn't look like a bug even if you know, like, if you've proven that it can't can't fail, I prefer to pretend that it can for the sake of any future readers of the code.
Shay Nehmad:So I I'm I don't know. There are a few that I always ignore. And if you look at my, like, Golang CI lint config, there's like, oh, what errors are not allowed to be skipped? And there's a whole list of, like, exception exceptions there.
Jonathan Hall:So I guess there I guess there are some that I skip. Like, so I'll I'll often skip IO dot write type of errors, especially if it's a standard error.
Shay Nehmad:Yeah. Exactly. Or
Jonathan Hall:a deferred close or rollback. I will skip those errors. So, yeah, there are exceptions that that's that I hadn't thought of. That's true.
Shay Nehmad:So already not a 100%
Jonathan Hall:clear. Yeah.
Shay Nehmad:That's what I sort of want to highlight about this blog post. It has good general advice.
Jonathan Hall:Mhmm.
Shay Nehmad:But you you said a while ago that the go gophers are nitpickers. Yeah. You can find counterexamples to any one of these. So I don't wanna walk through every single one because that's gonna take like a lot of time, but there are a few ones that I think are correct. Let's jump to like number four, thou shalt make errors tell a story through actions.
Shay Nehmad:Add context that said what the code was trying to do when it failed because errors don't have a stack trace with them, basically. I think what Preslove is saying is write in your error, like what happened, like placing order or reserving stock or connection refused. And then when you unwrap the whole error chain, it'll be like placing order number two, reserving stock number four, connection refused.
Jonathan Hall:So this is one that I probably most disagree with of the ones in this list. Oh. And but there's some nuance to my disagreement. So I guess that's what we're here for. Right?
Shay Nehmad:Yeah.
Jonathan Hall:I think there are two types of errors that you have to consider when considering this rule. And one is user facing errors, where I think this advice applies pretty well. And the other is nonuser facing errors, the ones that your program consumes. And there so I guess there's actually three consumers. There's the user, you know, something that actually bubbles out to the HTTP response and tells the user, sorry, that that cat dot JPEG isn't found.
Jonathan Hall:You know, that sort of thing, this makes perfect sense. If it's something that ends up in a log that an admin reads, there you actually want stack traces. So you should you should add an error type to your pack your application that includes stack traces, which is better than this for that purpose. And the third is something program itself consumes, and there you probably want sentinel errors, and you don't need all this nonsense.
Shay Nehmad:What do you mean when you say sentinel errors?
Jonathan Hall:So something like io.eof or maybe an error in your package that says thing not found or access denied, something like that. Because later in your at a higher level in your program stack, you want to see if what happened was file not found, do this. And you don't need a story then. You just need a true or false sort of situation.
Shay Nehmad:So what you're saying is this is true for like the user facing errors, but not the other two types?
Jonathan Hall:In my opinion, yes.
Shay Nehmad:Yeah, that makes sense. I do think that if you follow this rule though as sort of a general rule, what's the worst case that's gonna happen? You're gonna end up with, you know, you do have that story through actions. When you say an admin looks at it through a, in a log, it's still just a human reading it. Like having a super, super long stack trace you have to dig through, not always as useful.
Shay Nehmad:And especially if the line numbers don't line up exactly for some reason or, you know, it's an old version or whatever. Having a hint about, like, it was here. I like, like, function names and stuff because that usually is indicative enough.
Jonathan Hall:They should add function names to stack traces.
Shay Nehmad:What do you mean they?
Jonathan Hall:I'm I'm I'm being facetious because, of course, function names are in stack traces.
Shay Nehmad:Yeah. But, again, I'm just saying, like, normally No.
Jonathan Hall:You're not wrong. You're not wrong.
Shay Nehmad:The stack trace is big. It has pointers as well. It has, like, a lot of information.
Jonathan Hall:Yeah. Let me be clear. I'm not saying that the stack trace should be the only thing in your error, but I'm saying it serves the main purpose of where did this error come from, which which is part of the goal here. It's not the entire goal. Also annotate my errors with all sorts of other information to tell me what's going on.
Jonathan Hall:And I should make a plug here since we're on the topic of errors. I just released a course of boot. Dev, we talked about on the show a few months ago, that talks all about this, all about logging and error handling and all that stuff. So you should definitely check that out. And if you use my code cup o' go when you sign up, you will save 25% off your first year or your first month if you just do the monthly plan.
Jonathan Hall:So I'll link to that in the show notes, boot.dev, cup o go, to learn more about my particular opinions about logging and error handling.
Shay Nehmad:How cool. Where can I find it? Where can I find where do I put the code? What do I do?
Jonathan Hall:Boot.dev. Head over to boot.dev. The course is called learn logging and observability. Cool. Cool.
Jonathan Hall:Cool. You don't just pay for that course. You get all the courses when you pay. Nice. Which includes a course that Miriah's working on right now or will soon include it, she told me after the recording last week.
Shay Nehmad:Learn logging and observability and go new by Jonathan Hall. Cool. Cool. Cool. Sixteen hours of content.
Shay Nehmad:You know what? I'm I'm now wondering how many hours of content is Cup o' Go. Would you be better served just listening to every single episode top to bottom or doing this course?
Jonathan Hall:Let's just say we have hundreds of hours of content. That's probably not far from the truth.
Shay Nehmad:Oh, I don't know. How many episodes do we have? A lot. A lot at this point. 58.
Shay Nehmad:Eight. This is a 159. So, no, it's about like 70
Jonathan Hall:Hundreds would be a stretch, but we probably each episode isn't an hour, but some have gone over. So
Shay Nehmad:this blog post about error handling, there is one I I really, really agree with. Thou shall not log and return an error.
Jonathan Hall:Oh, yes.
Shay Nehmad:You start with one, you justify why in this particular case you do wanna log because it's useful for whatever. And before you know it, your whole code is just like, if error, log error, return error. As if Go error handling wasn't verbose enough, you're adding like another, and then you have to pass the logger, blah blah blah. Yeah. This is such good advice.
Shay Nehmad:This is really, really good advice.
Jonathan Hall:The the only semi legitimate reason I know of to do that, I and say semi because it's not really legitimate when you think about it, but it seems legitimate, is I have more context for my log at the lower level than I do at the higher level. The answer to that is put it in your error. Put that context in your error message. Yeah. Exactly.
Jonathan Hall:Put it in your error. And the only reason not to put it in your error would be if you don't want to decorate your errors with extra content that you don't want a human user to see, but there are ways around that too. And I talk about them in the course that I just mentioned. So if you actually want some more detail on that, use Cup o' Go and save 25%.
Shay Nehmad:Generally, I think the the the blog post is really good, and also I love that Preslove highlighted his sources in the beginning. He's like
Jonathan Hall:Oh, yeah.
Shay Nehmad:Oh, look at Red One and look at Proverbs and some blog posts in the past. It's like a sort of a just a best of list of all these sources. Presnov, if you're listening, we really like your blog. Come on the show, talk to us. Or if you know him, just just, like, let him know.
Shay Nehmad:We we love his stuff.
Jonathan Hall:Yeah. I I think I agree, at least with the heart of every one of these. Of course, I've already mentioned a few exceptions. But what what good is a rule if there aren't exceptions to it?
Shay Nehmad:Yeah. I mean, the the important part is to it's good to have these, like, list of general rules and then have a suspicious eye about everything. Like Yeah. You know? Same with clean code.
Shay Nehmad:You know, you read clean code. It's like, never use abbreviations. Generally a good advice. But, you know, like, you can write SQL. It's fine.
Shay Nehmad:You don't have to
Jonathan Hall:don't have to write your query language every time. I'm gonna start
Shay Nehmad:doing this. Structured query
Jonathan Hall:language driver. Just to piss people off.
Shay Nehmad:To waste tokens. All for all the tokens you've saved from the previous proposals. Alright. Let's jump to a quick ad break, and, then we have a a short lightning round for you. As mentioned at the top of the show, this show is supported by you, our listeners and beautiful Patreons.
Shay Nehmad:We wanna thank Tom Vandenberg that just became a Gopher member, the higher tier. Yeah. Patreon is a way when you subscribe or whatever, you can drop us a message. And Tom let us know that he has he's coming from a PHP background, and he has trouble convincing the company to introduce Golang
Jonathan Hall:Mhmm.
Shay Nehmad:Which is something I'm sure a lot of the listeners can sympathize with. I've done it once. I've I've tried to add Orca, push the team to use more Go. It actually worked at the end. I wanna talk about it, but I wanted to hear some take a page out of Miriah's book and like ask you.
Shay Nehmad:Mhmm. Yeah. If you if you faced this in the past, maybe share something for Tom in the Slack channel, then we'll talk about it at some future episode or we'll just forget, which also might happen. Sorry, Tom. But I I am writing it down, like we shouldn't forget it.
Shay Nehmad:Jonathan does have a habit of, like, deleting stuff from the tracker once it's been up for a bit too long.
Jonathan Hall:Yeah. Yeah.
Shay Nehmad:I like that. Don't delete.
Jonathan Hall:I like to do that in Jira too, by the way. Anything that's too old, just delete it.
Shay Nehmad:Linear has a setting for, like, auto close issues after inactivity. Yeah. And I always feel so guilty, like, creating an issue that was really a good idea and then not getting to it, and then the linear being, like, silently taking out the issue to the you know, behind the shed and shooting it in the head.
Jonathan Hall:I I really like that idea except on low volume open source projects where legitimate bug reports just get auto closed because the maintainer didn't fix it. Yeah. Anyway, I'm ranting now. Let's go on.
Shay Nehmad:Yes. So this show is supported by you. You can like Tom. Thank you, Tom. You can support us directly financially via Patreon.
Shay Nehmad:That's the best way to support the show, paying for hosting fees and editing fees, etcetera, etcetera. You can find the link to that in our Gopher Slack channel where you can answer Tom's question and the Swag Store and everything else on cupogo.dev. That is cup o go dot dev. You can also email us at news@cupo'go.dev. Other ways to support the show, sharing it with friends or coworkers or colleagues or your mom.
Shay Nehmad:Definitely your mom. We wanna talk to your mom. That's I owe some money from no. I'm just kidding.
Jonathan Hall:Why do wanna talk to her then? You should be avoiding her.
Shay Nehmad:Word-of-mouth is the only way we spread this show. You can either directly share just like this episode or an episode that's been useful to you with someone else or leave a review on Spotify, Apple Podcasts, write about us in your blog or whatever. Facebook. I don't know. Anybody still using Facebook?
Shay Nehmad:Definitely not me. We are planning to record a normal episode next week. So we should be good back to normally scheduled programming, whatever. Week after that though, we might have a little surprise for y'all. We can't we it's under wraps.
Shay Nehmad:We can't really, really talk about it.
Jonathan Hall:To your house. Oh, it's Bubba Deens.
Shay Nehmad:No. No. Coming to your mom's house. No. Alright.
Shay Nehmad:Enough. Lightning round time.
Jonathan Hall:Let's do it.
Shay Nehmad:Lightning round. A few episodes ago, you mentioned Miki tebeka's talk from our DAN Labs. He had a practical Go development with AI agents workshop that he streamed.
Jonathan Hall:Did you attend?
Shay Nehmad:Miki, of course, infamously known as Cup o' Go's first first guest and also one of the leaders of the Israeli Go community, also Python. Just a great dude in general. Miki, you're a great dude. So the whole video is up, and it has really practical advice about, like, how to turn your a, like, AI development process from autocomplete ish and a search engine ish to like how to use it as an agent and why Go specifically shines with agentic development workflows. So there's a whole lecture about that, how to use agents MD, skills.
Shay Nehmad:I'm, like, way into this stuff because I'm in an AI security startup. So to me, not a ton of this would need was new. But, you know, there's great advice here, like, notify me when you're waiting, which is something a lot of people like to do. In my office, people also like to put funny sound clips when Claude is done, which is pretty funny. Use an LSP instead of GREPs.
Shay Nehmad:How do you use resume? How do you use Git Work Trees? How do you use spec kit? Like, a lot of these agentic things that can be useful. And this is obviously by our Don Labs, which we also, you know, friends of the show, definitely.
Shay Nehmad:There is a two day workshop, which is like, you know, fully training sessions and procession, which is paid. You can go to our dunlabs.com.
Jonathan Hall:Is this a sales pitch?
Shay Nehmad:No. No. No. I'm not No.
Jonathan Hall:I don't mean from you. I mean I mean from the the webinar.
Shay Nehmad:I mean, it's useful within of its own, but then at the end, it's like it's like an upsell to the full workshop.
Jonathan Hall:So it's not a it's not a bait and switch?
Shay Nehmad:No. No. No.
Jonathan Hall:It was something legitimately useful. That's that's good.
Shay Nehmad:Yeah. Yeah. I watched some parts of it. Okay. But it's just if you want, you can buy the workshop to go more in-depth.
Shay Nehmad:Honestly, just ask Claude instead. Just like build the Practical Go Development with Agents workshop for me and then do it with Claude. But if you wanna hang out more with Miki with his Art Done Labs shirt, that's the way to do it.
Jonathan Hall:And you should.
Shay Nehmad:If you can,
Jonathan Hall:for sure.
Shay Nehmad:What's your Lightning Arms thing?
Jonathan Hall:Yeah. So Jesus Espino has written an eight part blog post or or series called understanding the Go runtime, and it just completed a couple weeks ago. So this has been going on since February. It's it's building building up. But if you're curious about how the Go runtime works and you like cute gophers and nice illustrations, check out this blog post.
Jonathan Hall:So the I'll just give you the the titles of each of the eight sections. So that'll give you a good overview of what's in here. Number one, the bootstrap. Number two, the memory allocator. Three, the scheduler, the garbage collector, the system monitor.
Jonathan Hall:I don't even know what that is because I haven't read this yet. The network polar, slices, maps, and channels in the last section. I wanna just finish the select statement.
Shay Nehmad:I just wanna note that this there is gonna be a next blog post. Is this a series that's ongoing? Yeah.
Jonathan Hall:And Yeah. The next one is gonna be about stack phrases, which you should be adding to your errors. You can learn about that in my course.
Shay Nehmad:I just wanna highlight that Jesus is working at ONA, that AI background agent company Okay. That we also had on the show. Remember?
Jonathan Hall:Yeah. I do.
Matt Boyle:Yeah. I'm I'm at I'm currently the head of engineering at a company called Ona, where we are building an AI platform using Go. I also am very, very active to the best of my ability in the in the Go community. I run a website called bitesizego.com. I try and teach people.
Jonathan Hall:It's been a while, but yes, I do remember that.
Shay Nehmad:It's all like coming together.
Jonathan Hall:It's almost like the Go community isn't as big as you might imagine or something.
Shay Nehmad:Yeah. For sure.
Jonathan Hall:Keep crossing paths with people.
Shay Nehmad:I still find myself surprised by how often I, like, you know, run across names that I'm like, oh, this person's been on the show, or I've looked at something in the show before. But yeah, episode one twenty six, we talked with Matt Boyle of ONA. And I wonder, you know, what do I gain from understanding the Go runtime? Because I don't write in the runtime, and usually this stuff doesn't affect me. But I'm a big proponent of always, like, learning how things work under the hood.
Shay Nehmad:You know what I mean? Mhmm. What I'm worried about with these sorts of blog posts, and let me know what you think, is that they run they they become outdated. You know, the garbage collector one, for example? Let's say that it was written a couple of years ago.
Shay Nehmad:It wouldn't include the whole green tea thing.
Jonathan Hall:That's a legitimate thing. And, like, the new map, what was it? In a couple versions ago, they they changed the maps or the yeah. Swiss maps. Yeah.
Jonathan Hall:So is that what it was? Yeah. Whatever it's called. So, yeah, things like that do change. I I yeah.
Jonathan Hall:It's a legitimate concern. I still think it's useful to read it to to understand the the basic concepts. So eve even if you have an outdated specific understanding of the garbage collector, you now understand how garbage collection as a concept works, and that's still valuable.
Shay Nehmad:Yeah. I recommend if you're in a company that's, like, adopting Go, which is just what Tom was talking about, doing this is like a weekly book club. That's a great you know what I mean? Everybody reads the blog post ahead of time, then you buy some beers and pizza and talk about it, and then you listen to Cup o' Go. Perfect weekly cadence.
Jonathan Hall:Making a a weekly beer drink and Cup o' Go listening meeting. Yeah. If you drink if you drink beer
Shay Nehmad:get the cups on our swag store.
Jonathan Hall:If you drink beer while you listen to our show, let us know.
Shay Nehmad:This show, you know, drink responsibly.
Jonathan Hall:Drink responsibly.
Shay Nehmad:Alright. That wraps it up for the episode this week. I'm happy to be back. Thanks for
Jonathan Hall:having Happy to have you back.
Shay Nehmad:Again, see you all next week. Program Exit Up. Program exit up. Goodbye.
Creators and Guests
