‽ Errata, Go fix բᵢₓ ᶠᶦˣ, & agent skills

The show is supported by our listeners. Stick around until after the news to hear how you could help support the show too.

This

is for 02/20/2026.

You meant twentieth. That's a mistake. Why? Because you said '20, but it's twentieth. And you make a lot of mistakes as we'll talk about in this episode. What?

I'm Jonathan Hall, by the way, and I never make mistakes.

I'm Shay Nehmad, and I love pointing out mistakes.

You know how I how I avoid most of my mistakes? By using Linux.

Oh, nice. You know how I avoid my most of my mistakes? By using linters.

Oh, there we go. Alright. So, yeah, I made a mistake.

Wait. Keep up with the important happenings in the Go community in in so and so minutes per week.

Somebody interrupted me. What a mistake. Alright. So mistake. We know that we make mistakes. The question now is can we fix them? Alright. My mistake. Last week, I talked about the new Go mod init, and I mentioned that it would admit your new modules to two versions of the past. It's actually only one unless you're on an RC.

We're gonna take, we're gonna take Jonathan to the, like, city square, flog him publicly, take off his, his rank, demote. What's the demotion from a cohost? Are you a guest now

on this show? Guess so. I don't know. That's that sounds like less work. I'm happy to take

that. Alright. So what what when I run Goemon in it, now it's gonna take one minor version back and not

two. It will do the the previous stable release. So if you're on 01/25, it will tag it for 01/20 I shouldn't say 01/25 because that feature wasn't in 01/25. If you're in 01/26, will make your module for 01/25. If you're in one

twenty seven RC, it's still gonna take one twenty five.

It will take one twenty six.

No. But if you're on the RC because prerelease is

yeah. So if you're on one twenty seven, you'll get one twenty six. If you're on 01/27

RC they released it.

Which right. Right. If you're on 01/27 RC, which is before 01/27, then you still get 01/25. That's right.

My point still stands. I don't like this. If you init the new Go model, it should be like the newest it can. That's my take on it.

I I think that makes good sense for the final product you're building, but for libraries, I think that using an older version makes good sense. But there's like, there's not like a Go mod init library feature. So, if there was, then I think that would make sense to change that behavior depending on that feature on that library flag.

Okay. So now that you fixed your mistake, you don't have to fix it again. Right?

That's right. It's been fixed once. It will remain forever fixed. Unless

Unless yeah. So the GoFix blog post is out, using GoFix to modernize Go code from Alan Donovan. It was just released, like, three days ago. We talked about GoFix a lot in our 01/26 sorry. In our 01/26, like, review episode. Right? We had a big episode reviewing all the features in 01/26. It's pretty easy. You run gofix ./ dot dot dot, just like Go build and GoVet and whatever, It'll fix all the problems. Oh, well, I guess it will modernize all the old looking code in your current directory.

Cool. Yep.

Yeah. Also list all the available fixers, which is pretty cool. So go tool fix help. We'll just give you all the registered, like, analyzers you have. And just as a reminder, if you don't know what this command does, it will take, you know, sort of old looking code that has a better way to do it today.

What does that mean?

The way I understood it was I didn't understand it, and then I just skimmed it, honestly. Yeah. And then Peter brought it up in the in the channel. Like, the moment you think about it, it means when you run the command multiple times, it might, like, because you apply one modernization, you may get a chance to apply another one. Right?

Yeah. Uh-huh.

I run go fix once. It'll take the x is smaller than zero, x equals zero, and change it to pick the maximum between x and zero. And then you run it again, and it's like, oh, now I can pick the minimum between x and a 100. Mhmm. So you gotta fix it twice. And I was very surprised because I've expected it to just work. Like, why not just run it in a loop until there are no more changes?

Uh-huh.

And, you know, it's gonna mess with people. They're running it in CI. It's like, man, I swear I ran GoFix. Why is CI telling me to run GoFix again? Oh, yeah. Generally, seems like the last mile scripting is is kind of weird, and why not? I suggested to add, like, an until done to go fix itself. Uh-huh. I guess they didn't add it and what we I'm left wondering why. Why do you think it's not there isn't, like, a minus recurse until done flag? Why isn't it that one the default?

So I just thought of one reason not to do that. I don't know if this is their reason, and that would be I could imagine won't GoFix look at third party GoFix directives as well. Right?

Oh, you can, like, add more analyzers?

I think I can add my own fix rules to say replace this construct with another construct. I bet you could bake a recursive loop. Like, I don't know if you would intentionally do that or if you're trying to build some sort of bomb, but, like, I could imagine a situation where, like, this thing says fix yourself to that, and that says fix yourself back to this, and you could end up with a infra recursion. I don't know if they thought of that or that's the reason that they did that or if it's just laziness or something.

No. Probably not.

I will mention, though, that there there's one other place I'm aware of where this already happens in the go to go go tool chain, and it's happened a lot for a long time, and it's in GoFumped. In particular, with regard GoFumped? So, like,

the FU50 or the normal The

official one and GoFumped, the the unofficial one that we talk about a lot, is a fork of that one. They both have the same issue, and that is that they are not idempotent necessarily, in particular with regard to line wrapping and comments. So you can run it once, and it will re rewrap certain lines or comments or whatever and run it again. It'll do it again differently. I don't I don't think that you could get under with an infinite recursion case because it's just line wrapping.

Yeah. And just just to double make sure, yes, you can write your own. There's no nothing is stopping you from writing a modernizer for for your own public API, but you can't, like, get your users to automatically run it.

Right.

In the future, they'll think about adding modernizers directly from the sources. So if you have, like, a library that's like, don't forget to do x after UI, like, don't forget to close my connection or whatever Mhmm. The GoFix for that library might be included in the in the libraries, like annotations or whatever, which I don't know how much I'm excited about because it seems like a great way to introduce security vulnerabilities. Oh, just run this GoFix command on your machine. Don't don't worry about it.

But if you trust this but but is that really a problem? I mean, if you trust the source itself enough to run it, you know, whatever whatever process you do, whether it's reading the code directly or just trusting the author, whatever process you do you take to to trust the source code, shouldn't you also trust the GoFix directives?

I assume they're just not scanned by, like, GitHub, Dependabot, and all these other tools, which are the actual way I have trust. It's either I know the person who's building it, like, personally or through, you know, media or whatever, or it's extremely popular, so the trust is like, oh, a lot of people are in it. That's interesting. And I'm locking down to a specific version and, like, never upgrading unless I have to. Supply chain's hard.

the attack vector would be to write a benign function that, you know, replaces strings or something. Right? Put a fixed directive on it that that swaps that for something that sends all your crypto wallets somewhere else.

Yeah. Luckily, I don't have any crypto

wallets. And and

hopefully, something installed on my on all my machines because I'm trying to learn Russian. And I assume, like, 90% of these malwares are check the languages first and, like, oh, if Russian installed, never mind, guys. He's one of ours. Let's drop this person.

Alright.

Alright. Go fix, fix, fix, fix. I guess I'll just, like, hard alias my Go fixing into running it multiple times. What else has been happening in

Goland? Speaking of Go fixing, ESR, Eric S. Raymond, famous open source advocate, posted on Twitter this last week. Can I still say Twitter? Yeah. Of now, but I don't like that. Not that not that anybody cares about my opinion, but I think Twitter is a better name. Anyway, so he wrote a program, apparently long ago, imagine, in C called CVS Fast Export. I guess it exports CVS as fast? I don't know. Or maybe it's related to the pharmacy I

have to admit, until I read this tweet again, I was sure this was CSV, and I was like, oh, it's a tool to expert CSV. No. Like, my mind just glossed over it. And now I read it slowly. Realized it's CVS, that old, like, you know, source control thing.

Yeah. Yeah.

Man, I love that stuff. CVS and SVN. Ugh. So good.

So he rewrote it in Go. Well, sort of. I shouldn't say he wrote it Go. He has a Go port of it that he rewrote with LLMs, and he he's just sort of raving about how well the LLM did at this. And I suppose that's because it had such a good test suite to begin with.

I think it's a good demo that, like, can clean out old technical debt in old code bases if you have a good test harness around it.

Mhmm.

Which I think was always true, but now it's like, oh, you only need to build the tests. You don't need to do anything Yeah. Yeah. Do you do you do you agree with this sentiment or does this fit obviously, Eric, you know, you said he has, like, legendary programmer status. I actually don't know. Maybe maybe I should do more research.

But You probably need to spend more time in the, the open source community. You probably need to use Linux.

Yeah. That sounds about right. But the oh, man. His website is, like,

so Does it look like from old 1993. Yeah.

Man, I love it. It it just brought me back to, like, you know, school, sitting with a in the computer lab at school.

Mhmm.

He does have a a whole page dedicated to firearms and guns.

Oh, okay.

So I I understand what sort of a freedom open source guy we're talking It's not a San Francisco, latte drinking open source, person with a MacBook. It's a Texas, you know, I have my Linux machine on one hand, and my gun in another. Cool. Ed hominem aside, do you agree with the sentiment that if you have a good test harness, you you let loose an LLM on your code base and fully rewrite it in a static language, static modern language?

I mean, in principle this kind of goes back to the conversation we had an episode or two ago about whether we trust LLMs to write pull requests. Right? In in principle, I suppose that could be true, but, like, there there's a lot of a lot of edge cases that are hard to codify in tests, especially around performance and security. It's not to say they're impossible to do. So, you know, if you have a test suite that's been built from the ground up with performance and security in mind, then, yeah, I probably would trust the LLM to do it correctly or or at least not do it too badly.

I think I I generally agree with you. In principle, it's possible, but and, you know, this library had, like, a big suite of tests anyway with all the edge cases. Mhmm. There were just a few to add for, you know, some command line arguments that were were very bespoke. But I'm I'm comparing it to, like, you know, how, Anthropic said, oh, we built a C compiler, just using Clawd, and then, like, a couple of weeks, it built a fully working C compiler in Rust or whatever.

And it's nice to know ESR is using Go, I guess. I I don't know.

Is he?

Oh, his LLM is.

His agent is.

He must have a reason to wanna con to to trans or to to convert this to Go. I I don't know what it is, but

Why not? It's better. Talking about not trusting AI, I've been introducing agent skills in my Claude setup.

Yeah. Me too.

What's your what's your favorite one that you've added?

So I added a red, green, and re a red four, let me red, green, and refactor to make the TDD cycle.

Oh, nice.

I added one a commit skill because I found that it would get it would just get ahead of itself, start making all sorts of random commits when I didn't want it to. So I I created a commit skill and a hook that would prevent it from committing without me explicitly saying to run the commit skill.

That's that that seems useful. Does doesn't it take well, you gotta you gotta actually read the the test it's generating and, like, look at the colors. Right?

Yeah. So, basically, after I let it do the TDD cycle, then I wanna review everything, make sure it makes sense, make sure it tested the right stuff. Off it goes. I've had it create tests that were completely bogus, you know, testing nonfunctional changes and stuff like that. So in my instructions, I've discovered that claud.

do that,

but I violated the rule. So skills have been helping with that quite a bit.

Unrelated, but I would highly recommend for the rules you actually care about, copy and paste them, two times, because the usual model that you it would use is non reasoning, but if you copy and paste the same, instruction two times, it literally does what a reasoning LM would do, which is like, oh, I'm thinking about it. Let me copy these tokens again. Anyway, so that's one option. I have a cool skill I wrote, but I wrote it like, again, sounds like you, like a a bespoke skill. Run all my current company's stack manually, grab random ports, like a a fully a very annoying process that I would do manually before.

know what that means to me? That means that the person had Claude write the skill for them because I've had Claude try to write skills for me, and it does a terrible job.

Mhmm.

I've had to create hooks, like, in a wrong format, and, like, it'll it'll tell me it I remember it told me once, this is a common hook format. I'm like, I don't care about a common hook format. What's the hook format you understand? Oh, let me go look that up. Claude is insanely brain dead about its own capabilities.

And if you have one bad skill that's what happened to me, right? I had one badly formatted skill in my repo, and then that's like that looks And then

copies it.

Yeah. Yeah. Other than badly formatted, you know, super table stakes, you don't understand the format, this analysis also looks and, you know, this is not Go specific, obviously, but it also looks into, you know, is it a low value add because it repeats stuff that's already in the, training data. So 50 skills out of the the seven odd 700, that they looked into are just not useful. Like, adding them just takes up context for no reason.

course. Cool.

Also, it's in Go, so it's super fast.

But has it been fixed, fixed, fixed, fixed?

I think you just run it once, and then you have to fix it yourself. Although, honestly, what I did is told Claude, run SkillValidator until there are no more issues.

Speaking of fixing things in Go, I think we have time for one more related topic before we're out of time, and that is a proposal to add checks for missing error calls for buff io dot scanner and SQL dot rows has been accepted. So GoVet will now warn you when you are not checking those errors. There have been linters, at least for the SQL rows, probably for the other also, but I've used one for SQL rows that comes with Golang cilent, but it's nice to have that in the main GoVet tool. Everybody will have access to it now.

And is this something I should, like, actively run on all my repos, or is this something I should be worried about? Like, what's the impact?

You probably should run GoVet periodically, but I think it automatically runs when you do Go test. So if you're running Go tests frequently, I think it'll run and maybe in a few other cases too. Cool. Yeah.

Alright. I think we're we're out of time, even though we have more things in the backlog.

We have so many more things.

But let's do a quick ad break and then jump to lighting rounds. Thanks for listening to our show and supporting it. This show is supported by listeners such as yourselves in various ways. The best way to support the show is directly via Patreon. This is a hobby.

There's a way. N e w s at

Yeah. Other than that, you'll be able to find our swag store, which we're debating if we're gonna keep up for long or not.

Yeah. We'll see if we're able to

take it down soon.

We're not selling much, which isn't to shame anybody, but, like, it's Yeah.

It makes sense. I don't I don't buy often from our

sweats. Right. You you'd only need one mug. I I bought one three years ago, and I'm I'm done.

Exactly. Past episodes, transcripts, everything you need to find. Everything Cup a Go can be found there. Other ways to support the show, we don't pay for advertising at all, so spreading the word about the show is a lot of fun for us, getting more people involved and getting more feedback. Leave a review on Spotify, Apple Podcasts, or wherever you listen to your podcasts, or share the show directly with a friend, a coworker, a co student, any other gopher in your life.

First off, the lightning round. Shy, do you use LazyGit?

All the time. I love it. Me too.

It's a little TUI git interface. Makes it easy to to rearrange git commits or squash commits or whatever. It's lot faster than a GUI. I don't like GUIs. Some people love them, I guess. I don't know what's wrong with those people.

Probably don't use Linux enough.

That's probably it. But I I do like this tool. I I it's just easy to pop it up, do some things, and close it again. And it's written in Go, and the reason it's in the Lightning Round today is if you're using it lately, you might have noticed there's a little random tip that pops up in the log section, and one of those tips is if you want to learn Go, think of ways to improve LaSigit, join the team. Click ask question and express your interest.

I agree. I literally noticed it in my terminal as I was using it. I have the screenshot. It's not only if you want to contribute, also if you have just ways you think of improving it. So, you you know, a lot of open source contribution is suggesting issues or improving documentation. One short item on the lighting round for long term listeners. If you remember, Khoyeb used to sponsor us, like, a long time ago.

Oh, yeah. I remember those guys.

Yeah. They were really cool. We also hosted their CEO on the podcast. It was a lot of fun. Yeah.

Give give us all the credit. No. Please don't.

One last item on the lighting round. How much do you like zines?

Oh, is that a word anymore? That sounds so nineteen I ninety

one to recommend you. Paged Out. It's a free experimental technical magazine by this you know, it's a very cyber tech purple cool thing. Actually, published in the first and second editions of it, and I it was a lot of fun back in 2019. It just came out with the eighth issue, so if you're looking for time They to get into it

have, like, one issue every three years or something?

They've been on and off. They I think they

took they

had two in 2019, and then the next one was 2023, managed by this, one person called Jinval, which if you're in cybersecurity, you know him. And, yeah, the eighth issue came out. I did a control f on it, and it does mention the word Golang once in in its 50 pages, so it counts for the podcast.

Okay.

Well, honestly, I just recommend it. It's always very cool.

Alright.

I think that's it. That makes the show. Program exited. Goodbye.