Cup o' Go

This show is supported by you. Stick around and find out more. This is Cup o' Go for today is 05/22/2026. Keeping up to date with the important happenings in the Go community in about twenty minutes per week. I'm Miriah Peterson, and I am the guest host to the regular counterpart.

Yeah. And I'm Jonathan Hall. I am the regular cohost, I guess, or irregular. I don't know. Strange cohost.

I don't know what I am.

All of the above.

Welcome, Miriah.

Oh, thanks for having me. Happy to be here.

Yeah. Thanks for stepping in. We have some exciting news for you today, some security releases, some AI related stuff, some proposals. Let's let's dive in. First up, we have some security three kinda important security releases that came out yesterday.

These are not in the standard library, but they kind of almost are. These are the golang.org/x packages, which are, like, semi official. I guess the main reason they're not standard library is so they can be released more frequently at different release cadence than some of the standard library.

Experimental. I think what it I don't know. I've always thought it was just like, maybe these aren't deployed in Google's back end. Like, there's some kind of, like, we haven't hit the test threshold. But yeah, every once in a while they move them over.

It should not stop you from using the package.

Right. And an interesting thing is some standard library packages depend on these packages. So it's like the definition that the the boundary is fuzzy. But anyway, golang.org/x//image, my tongue is tripping up, has some fixes in BMP and TIFF that, let's say, can cause out of bound errors when decoding. So you don't want that.

No. Or if you do, then, you know, you're crazy, but, you know, that's cool too. Xcrypto. This is probably the one you might care about the most. This is the one that Govulnchuk started screaming at me about for SSH.

It looks like these are all SSH related. Memory leaks. There's a there's a bunch here. Memory leaks, infinite loops. Yeah.

I I wonder if these are, like, found by an LLM. With with, like, 25 of these all related to SSH, that's kinda what it looks like.

So the prompt is just start with there is a zero day vulnerability. That's the beginning of the prompt. And then you continue with, okay, now let's go through this repo and fix some bugs. Yeah. So you just have to to tell the LLM it exists and it will find it every single time.

Right.

So it might have been found with an LLM, but that doesn't mean it was fixed by an LLM. It also doesn't mean it was actively breaking anything.

Right. And then finally, x slash net has a single fix in the Xnet IDNA package. I don't even know what that is, but it's a failure to reject ASCII only puny code encoded labels. That's pretty niche.

Agreed.

Won't affect most people. No. But oh, actually, I'm sorry. There's a couple there's another one on HTML, incorrect handling of character references in doctype nodes.

Because people actually use Go templating for their HTML, people that are not Miriah.

Why don't you like Go templating?

I do like it. I am just saying that for HTML specifically, I don't I think unless you're doing a static site, you're gonna be using JavaScript or TypeScript or React framework. I'm just saying the tooling is is is pretty dearly focused.

Yeah. Alright.

I love Go templating.

Okay. So there you have it. A bunch of security releases in three packages. Go upgrade. Yeah.

I think that's that. Let's talk about this blog post you found.

Oh, yeah. The yesterday, gopackage.dev API. So they put this on the Golang blog. I know I've met Jonathan Amsterdam, and so he was one of the authors listed on it. So the gopackage.dev is the official place where you can go get all your Godocs on the website.

So if you're used to using the GoDoc CLI tool, it's the web mirrored thing of it, and they now have a public API in front of it. So you can do API searching over GoDocs instead of just doing web searching or doing the GoDoc searching. Now, my personal opinion is I think that the use case of this is for skills or for sub agents and stuff that Mhmm. Have an easier time searching APIs than doing an LSP search. But LSPs are better.

I looked into them. Think well, personally personally, I am ProGraph as the tool for context engineering. So I think that it is more effective to just build tooling around LSPs than it is to go by the default curl or whatever you would do for an API scrape. But API scrapes are easier just in my opinion, not as effective.

So let's talk let's dig that apart a little bit. Dig that apart. That's not a phrase, but tear that apart a little bit, especially for people who maybe aren't familiar with what an LSP is and and what you're talking about. First off, what is an LSP?

So since our language server protocol was invented by Microsoft, I'm surprised that I even know that Microsoft was the one that wrote the paper on this. But essentially, the idea is you should be able to navigate a code base using a protocol that allows you to do traversal of that code base. So they essentially things like source graph did this before LSP, and then they integrated with LSP. Like, so the idea is it creates a graph of your code base that you can use the LSP protocol to navigate. So, like, those fun little things when you're in Versus code that says go to where is the function defined?

Go to definition. Go to all the callers. Do all those things. That's essentially the LSP graph telling you how to navigate the code where things are called and referenced and used so that you can find things and navigate it really quickly. Mhmm.

The nice thing about this with Godocs is because Godocs are generated from the strings itself. You could theoretically not theoretically, literally, this is how Miriah does it. You can go to the definition and then just go the lineup and get the doc. So you can do LSP navigation as opposed to doing doc scraping from an API, or you could do the CLI, go doc, and reference a function. But like I said, I do think if you're anyway, so that is the that should have answered the the LSP question.

So

I I can imagine two possible places where the LSP approach might break down, and maybe this API solves that. One is some Godoc isn't tied to to a thing. That's usually like the package, you know, like preamble or whatever. It's not tied to a function or something.

No, it's at the package. It is at some package file. Yes. Correct.

Right. So you can find it there, but it's not as easy as go look up the function and then go one line up. It's not that simple. And the other probably more interesting use case would be your agent is trying to evaluate which of three possible libraries to use that aren't installed yet. Does LSP help with that or is that a place where

No. You would not be able well, if they're not installed and don't have dependencies, you wouldn't be able to do LSP. I think for searching for packages that don't exist, yeah, that would probably be the use case. And then I don't think that the GoDocs CLI, right, that's only on docs for your things that are installed in the Go path is my understanding. So, yeah, that would be in evaluating a future tools.

Then that poses the question, if they're on GitHub, why not just use the GitHub API to search their docs? Which is what I have also done. I'm not saying this is a bad thing. I'm saying I'm just I'm just poking at workarounds. I think this is great.

Like, it's a very it's already was API based. Otherwise, the GoDoc tool wouldn't work. So it's a low hanging fruit. I think it makes it way more accessible. I just am nitpicking on the agentic use case over, like, the actual value.

And I do think they're 100% our values. Like, if you have an API, you could have public docs that you serve internally. Right? If you're trying to have an internal doc site, but you also use public tools, you can reference those in. So there's lots of other values there, but it's a I I do see it being agentic motivation.

Not a in other words, it's not a huge unlock, but it's it's a nice sort of obvious incremental change.

Well, I agree. I that's where I I think it's a good it's a good step forward.

Cool. Moving on with the theme of agentic coding. It's gonna be a theme, I think, today. I wanna do a shout out Miki tebeka, who was, I think, our very first guest on this show, like, three years ago. He is doing a one hour webinar that's free on practical Go development with AI agents.

It's hosted and sponsored by Arden Labs. This will be on Wednesday, May 27, twelve to one p. M. Eastern Daylight Time. Link in the show notes so you can translate to your local time zone.

Overview is stop treating AI like a like a GRU tool. I don't know what that means. What is a GRU tool? Is that a is that

I have no clue.

Is that a typo or is that

I don't know.

Like lead slang I don't understand.

I I 100% I don't know either.

Learn to build ghost systems with agency of context engineering for high velocity coding. Who doesn't want high velocity coding? Cover planning, memory, context engineering, and skills. So I don't expect this to be a deep dive in one hour, but probably a really great intro to the topic if you Well, I mean, we've talked about

it before. You probably you have custom skills you've built. Mhmm. Right? We all have our things.

And I'm sure, like, most of my custom skills at this point are like, k, on commit, make sure you've run x y z because Go's linter is invaluable. Right? So, like, there's definitely things that you should do to keep up the high quality of your Go code that doesn't come built into the agent. So I'm sure it'll be great.

Absolutely. Yep.

Cool. JSON v two is official coming with Go twenty one twenty seven. I read somewhere that they were doing the code freeze for that, so that release should be coming soon. And JSON v two is exciting. I used to work with Josiah who I don't know if he still is the tech lead for JSON package.

I think he is based on the most recent comments on this issue. Basically, he came to the the Go teams, my understanding, weekly or maybe it was a special meeting with their their meeting to discuss this, and they kinda hashed out a whole bunch of design decisions and basically settled on, yeah, the design you have here is is the right one. Let's go ahead and publish it. So

Yeah. I I it's great. It should be a lot of efficiency boost. I know the only reason I've seen people not use the JSON standard library package is they're like, it's not fast enough. So it'll be a day it's a huge win.

And hopefully, the v two we've they've doing v two for as a standard for a while that, like, says the slash at the end of the path. So there is no reason, I think, for people to not use the JSON standard library now. And Joe's great. He is I I I cannot think of somebody more qualified to lead that. So

Awesome. Yeah. I am definitely looking forward to it. I have had complaints about the the JSON package for years. This will finally solve the majority of them, if not all of them, and probably some I never even thought of.

So I'm very much looking forward to using it once it's public next should be in August. Shouldn't be too long.

August is, I think, their cadence.

Yep. We we had an interview with Josiah early on when this was early in this in in the process. So if you want a more deep dive into what this actually means, I'll put a link in the show notes to that episode. You can check that out. One other proposal that has been accepted.

This I didn't even know this was on the on the radar, but I really like it. How often do you write tests using the HTTP test package?

Every time I write an endpoint, I write those tests. Now the amount of time I write endpoints is very slim because I that my that that is not the job I do. Sure. I wrote something yesterday, though. I was like, I was writing an endpoint.

I was like, we gotta have a full suite of tests. And then the agent's like, k. Great. Happy path. 200 tests.

I'm like, wrong. Let's do the 500 errors. Let's do the four zero four and the four zero one. Come on. All the tests.

Mhmm. So quite quite regularly if I am doing API development.

So the the case that this new proposal is meant to solve may not apply to you if you don't do these very often, but have you ever found yourself trying to write a test for a timing issue related to an HTTP endpoint? Context cancellation or background tasks or anything like that where where timing is critical?

No. I only have timing issues in database calls right now. That is my world. Okay. Alright.

I'm sure that they come up more often than not.

Yes. They do they do come up. It's not like I've done a fair number of endpoints depending on the project I'm working on at the time. It's not like this comes up on everyone, but it does come up a certain amount of time and it's useful. So the problem that this new proposal is supposed to solve is if you have some timing related HTTP calls, you can't use sync test because sync test only works when a goroutine is blocked.

Mhmm. It doesn't work across network boundaries or file system calls or something like that.

Oh, and that makes sense. There are a lot of hidden guarantees in the HTTP package.

And especially if you use HTTP tests, you're actually starting

A guarantee in order to be able to do the background read write. Yeah. 100%.

So the new proposal is to make a sync test aware HTTP test server, and it's been accepted. So this is new sync test server in the I think it's in the HTTP test package. It looks like a server and it walks like a server and it talks like a server, but it isn't really a server. There's no network involved. It fakes a server so that sync tests sync test based tests can work again.

So you're no longer blocking on on a literal network socket connection. You're blocking on a goroutine.

That's actually really nice. I've I I think the only time I've ever run into anything close to this is doing a time out cascading cleanup, which would

be really nice to be able to test when you're doing

Mhmm. If you have some background process running, but you do have a time out on the call that needs to cancel the process. So yeah.

Yeah. This will be the sort of thing I will be extremely glad exists like 1% of the time.

Yeah. 1% of the time. But in that 1%, you you need it every Exactly. Single

We have made it through our planned list of news, except for a couple of lightning round things we'll get to in just a moment. As always, if you're a regular listener, thanks so much for listening. We appreciate the support. We've been getting a lot of useful comments. Last week, I was at a meetup, not about Go.

It was about AI stuff. And, like, two or three listeners of the show showed up because I'd mentioned it on on the show. So that was cool to meet some some listeners. We love the support. Keep spreading the word.

Word-of-mouth is how most people hear about this, I think. I guess some people search on the interwebs. Share an episode with a friend, a colleague. You can also support the show financially if you want to. This is kind of an expensive hobby.

We have a growing number of Patreons. You can join for just a few dollars a month and help pay for editing and hosting fees. You can also leave a comment or review wherever you listen to your podcasts. That's always helpful too. And you can buy swag.

We have the swag shop at cupo'.dev. We have a Slack channel on the gopher Slack. You can join us there. I don't know. I'm probably forgetting something, but if you ever listen to this show, you've already heard it before.

So I think we could just jump into lightning round. What do you think, Miriah?

Do it.

Alright. Lightning round. One item I have for the lightning round this week. It's called sulk, I guess. It's okay.

That or slack, but Yeah.

I don't know. You don't vowels in it.

So your kidney, silk, slick, whatever you want.

Anyway, it is a blazing fast Slack TUI. So if you're tired of using the Slack web interface or the electron I think it's electron app.

It's an Electron app.

You can use a TUI now, apparently. And, of course, it's written in Go. That's why we're talking about it on the show. Github.com/gammonsorgammons/slk. Link in the show notes if you're looking for a new way to be cool on Slack.

What about you, Miriah?

Okay. We'll move mine up. So I actually I had so background, I run a Go conference. We had Jonathan there last year. Mhmm.

And we were having a conversation literally yesterday about the value of a language specific conference Mhmm. In a time when everybody just has AI generating code for

you. Mhmm.

The my response was right now in our in our local Go meetup, we are doing standard library only. And the reason people come to that meetup is because there is no AI talk. It is just like the essence of the language. And so my question for the audience is how much would I like do you still find value in language specific things and specifically AI agnostic language specific learning or programming specific learning, stuff like that? Would you pay money to go to that conference?

Not that you have to go to my conference. Just like in general, what is what what what is the the continued value or need or desire when we just have AI vomiting code for us all day every day?

Yeah. That's a good question. I think you're gonna get a a biased sample of answers from this podcast.

I want a very biased sample of answers, and I want to be at Miriah Peterson in every single response because I think the AI hype cycle drowns out a lot of these biases that that that talented professionals and even hobbyists do have. So

Well, obviously, people listening to the show are interested in Go specific stuff or they wouldn't be listening to the show. So

100%. But like, there's also there's there's networking, there's security, there's what do we call when you're a kernel developer. Right? Kernel developers, what are they doing in the age of AI? I'm sure they have desires for very specific, you know, to their interest content.

They're mostly fighting with Linus, aren't they?

Yes. Always. That's their only job is fighting with Linus, Vovshin. But it's not my job. It's just I just there's a lot of specializations out there that I think we we ignore.

Yeah. And I I I just wanna make I I would love for to hear about that from from the audience.

Great question.

And like I said, at Miriah Peterson every time. Tell me I'm wrong or right.

And are you on the Go For Slack channel?

Of course.

The the the Go For Go one on the Go For Slack is what I meant to say. I am. So that's the perfect place to at you or send a DM if you wanna say something a little

You can send a DM. You can find me on Twitter. I don't care. Like, do whatever.

Sounds great. Well, I think we are at time. I think yeah. I think that's it. Thanks a lot, Miriah, for joining.

This was a fantastic episode.

Happy to be here. Thanks for inviting me.

Until next time. Program exited. Program exited. Goodbye.