Tests just keep getting better, and so do the imaginary internet points!

This show is supported by you. Stick around till the ad break to hear more about that. This is Cup of Go for 04/23/2025. Keep up to date with the important happenings in the Go community in about fifteen minutes per week. I can tell you ahead of time, this time is gonna take more. We have too many items on the backlog. I'm Shay Nehmad.

And I'm Jonathan Hall.

We took last week off. I had some things to take care of, and our backlog is very, very, very full.

Yeah.

Right now I'm in a security startup, and this week is always like the most stressful week because it's one week before RSA in San Francisco, which is like the big industry conference. So my LinkedIn has been absolutely like, everybody's raising capital, like millions of dollars, tens of millions of dollars. And my even my previous company, Record, raises like 25,000,000 this week. So I'm all like overwhelmed by everything that's going on. Let's talk about like some technical topics about a boring programming language that advances very linearly and is dependable, just to balance out all the Yes.

So I wanna I wanna do a shout out to the GO team for having a a slow week with proposals. There was virtually nothing happening this week. They they had their meeting

Thank you,

GO few discussion points, nothing we're gonna talk about this week. So that gives us a chance to catch up a little bit. Thanks for making our lives easier.

I know

that's why you did it.

They were like, oh no, no, Cup of Go episode. We should we should stop because

I know that's how it works, right?

I mean, we're we're we're

that important, right? Aren't we? So, the first thing before we talk about proposals, which we have several to talk about, the first thing I want to talk about is Find Conf twenty twenty five, tapping again in Edinburgh, Scotland on 09/19/2025, and the CFP is open until June 20. So if you want to speak there, you have a chance to submit a CFP.

Yeah. Cool stuff if you're into the GUI apps in Go kinda kinda thing. They're gonna talk about new features in FINE since last year. They had a big like performance refactor as well, which I assume is gonna be highlighted. Just some project examples, tips and tricks.

Yep. Definitely.

And of course, fine is a thing by the friend of the show, Andy. Hey, Andy, what's up? Now let's talk about tests. Tests are are important, right? I think one of the things people learn when they get into Go more more quickly than other languages is how to like write tests and run the Go test command.

It's never as simple as tuberculosis on House though.

It's what's their thing? It's never lupus. ANA was negative. It's not lupus. So there's a new function. It's called output. So you do t dot output. And it gives you a writer that writes to the same test output stream as as if you did t dot log. T dot log has a few cool benefits, which maybe you don't even realize to start with. But there's a good reason we don't do fmt dot print in test, but we do t dot log instead. Do do you know any like some of the some of the reasons?

Well, yeah. Fmt Print just always prints out nonsense, so you you get just garbage on your console. Whereas t. Log will, by default, only output if the test fails.

Which is super useful for cleaning. Like, you open your CI output and you only see the logs that are relevant for the tests that failed, not all of them. I'm actually writing end to end tests with NestJS right now, and I've been itching to implement something similar, which is like only turn on the logger if the test failed. But it's gonna take so much effort where in Go you just like get the t dot log for that. But this is for prints in the test.

Or not just s log, but any other arbitrary thing that that might output useful debugging data. Right?

Yeah. Yeah. The the original proposal is because of s log t. Mhmm. The interesting part is because you do it like this and it's solved from Go side and all the third party library, it solves all the, you know, finding the caller and the right tests and all of that.

On the change list. CL, right? What you got is a change list, isn't it?

Could be a change something. But there's a lot there's a ton of comments here. Unlike most Yeah.

Change list is right.

Change list is right. Mhmm. Changelists makes more sense than pull request. I never understood pull request, by the way. And I'm I'm deep into git. I read, like, the source code.

I'm pretty sure pull request is a GitHub thing, not a

GitHub Yeah. Yeah. I mean, GitHub. Anyway, that's a different discussion. One thing that's very interesting is that there are a ton of discussion on the changelog itself.

Yeah. So that's not all. Wait, there's more.

Yeah. That sounds a bit does this ever happen to you?

So have you ever written a test where you write a file in the test or maybe you do some directory manipulation or something like that? And then sometimes you wanna examine that later, like maybe the test fails for random reasons, don't know why, and you want to look at that output. If that describes you, for only $10.99 plus shipping and handling so the the new proposal is to store test artifacts. So the idea is to give us kind of like the last one where they gave us just a general rather than solving the very specific problem of I want my S log output to go somewhere. So the proposal is to add a new function to once again TB and F this time called artifactdir, which returns a string that is the name of a directory.

So what you're saying is I have a test and, you know, it might produce some files and then we compare it to a snapshot. So these are the test artifacts and you wanna store them only when it fails, basically?

Yeah.

Cool. Cool. Cool. This seems like something I would implement if I needed it.

Mhmm. I I had implemented it before. Yeah.

Is it a lot of, like, heavy lifting? Seems like a this this has been accepted. Right?

Yes.

So this might be late joining the discussion, but it seems pretty, like, simple. Right?

I don't think it's that conceptually difficult. I don't see a CL yet, so it's still waiting. It's not even targeted for a specific version of Go. So if you wanna go implement this, I think you have the opportunity to. But I don't think it's actually as hard. Like I said, I have implemented the same sort of thing a couple of times. Of course, I wasn't trying to target the general public. I was trying to target my very specific case. So I'm sure I didn't consider all the edge cases.

But but there are like I don't know. There are just equivalent, you know, packages like Ghostnaps that give you, like, match snapshot, which save like a snapshot This is not necessarily for snapshot testing. Right?

Not specifically. It's more general than that. Yeah. Maybe you're building a new YAML parser because the old ones were deprecated, for example, and you wanna write some YAML to a directory somewhere. And then during the testing, it's not working for some reason. So you wanna write that to a directory that you can later examine.

Or maybe the reason this is becoming prominent is because all these LLM apps are so unpredictable. They're like inherently indeterministic, right, because they have probability built into them. Then you want to, like, you run your benchmark, but you wanna store the artifact to the side of like, the actual prompts that return. So you can visually inspect the the benchmark without logging every single prompt into the We had something similar at Orca. Yeah.

Yeah. I agree. Yeah.

Cool. Cool. Cool. And it's been accepted and you said, change list. You don't have a change list?

I don't see a change list yet, so it's still waiting for an implementation.

Alright. Interesting. That

could be you. For just

$10.99. And if you implement it in a week, we'll also throw in a set of steak knives. Talking about predictability, there's another blog post we wanted to talk about that's related to testing.

Yes. Yes. There is. So we're a little bit behind on this one. Also, this came out April 2.

No, again, this is fine.

Not too bad, yeah. But this is from the Go team. So one of the official Go blogs. I think they threw out like three of them at us in the last couple of weeks and we haven't even gotten to most of them. But this one, more predictable benchmarking with testing. V. Loop. Have you written many benchmarks in Go, Shay?

I've not written many, but I've really enjoyed the ones that I have. Mhmm. I've written one for, like, a JavaScript, like v eight engine running within Go Mhmm. Where we try to run JSONata stuff. And the benchmark discovered I did benchmarking and fuzzing. It was like the first time both of these features have been relevant to the same endpoint.

Mhmm.

And bro, that was so cool. I felt so smart. Even though it's like so easy. You just replace testing t with testing b and like add a for loop and it's just like you're done. I felt so smart. I felt like the most elite programmer on the face of the earth. So not a lot, but when I did, I I had a lot of fun.

Did you run into any pitfalls building your your benchmark?

Not me. But I've

because you're superhuman.

No. I just I'm like, I ran it and then it was like, this is the number. And I was like, fine. And then they commented it out because the number was fine.

Alright. Well, some people run into problems and I have too. Basically, it's easy to do your benchmark loop wrong. Right? So especially if you have something, and I imagine this might have applied to your situation where you have to do some setup that you don't want to be included in the benchmark. Right? So you want to create your V eight engine instance, for example,

I'm imagining Oh, for sure. Like you set up everything and then the

only GPU And then you wanna execute that code 10,000 times or whatever, not the setup 10,000 times. Yes. So you have to be careful about ordering things and and start and stop and all that stuff if you're doing benchmarks, if you want them to be valid. Well, Go 1.24 added a new loop method to the testing. B type that makes a lot of that a little bit easier for you.

The interesting like, the the small thing is that you don't have to remember the reset timer trick anymore. Which is after you used to, after you do your setup, have to call reset timer. But it seems like it solves even more subtle problems with like, you know, the compiler looks at stuff and the stuff looks like dead code and then it

Oh, right.

It, blah blah blah.

Yeah. It

benchmarks nothing, basically, which is not what you want. Right. And using the loop function, when you use it, it prevents dead code elimination and not allowing inlining and calling the re the like start and stop timer thing. Not start, reset and start, just doing it inside the loop. So it's not introducing any new feature, it's just because you could have done all this stuff with like compiler directives and and calling it manually and whatever.

Mhmm. Yep. I like it.

This is now the preferred way to write benchmarks. Right?

Yes. This is the preferred way to write benchmarks now.

So do you think the modernized Linter should support it now as well? Is that is that a thing someone needs to remember to do?

So the modernizer one of our call is actually writing simple rewrite rules. I don't think that would apply here.

Why? You look at all the places where you do for rangeb.in and you replace it with b dot loop? Super simple.

Is it is it literally that simple? It might be.

Well, some some linter rules should warn people about it somehow.

You should be able to detect that you have a benchmark that's not using b dot loop. That would be easy. But automatically rewriting it might not be as easy, at least in all cases.

Well, there might be a linter already, and I'm, like, just thinking about a great idea that someone, like, already implemented. Wouldn't be the first time.

Let's talk about popularity.

Alright. How popular were you in high school? And how is that

I was the most popular of the two nerds in high school.

Yeah. That's why I'm so good that's why I'm so good in programming, just because I was so popular. No, we're talking about popularity of programming languages, of course. The TIOBE index has They publish every now and then, so it's not like a huge news. I just found it interesting with the current macroeconomic conditions like in the world, and this is not an economics podcast, but I'll try to use, like, vaguely technical terms, and I would say it's bad.

By a big margin too.

Yeah. Yeah. And it's increased a ton, like by 6%. So now it's 23% popular. This is kind of vague. Right? Like, definition, you can read through it. Doesn't mean that any 23% of code in the world is in Python.

What's the TLDR though? Is is this like trying to measure developer sentiment about the language or

So it actually it it doesn't care about sentiment at all. Things can be really high if people don't like them. It's just looking at search engines

like

Google and seeing how many people are looking for a thing. Which is, by the way, interesting because I would think that so much of programming language searches have are not from like web searches at all, they're from LLMs. I don't search for things in like, that are JavaScript related right now because I'm writing in JavaScript, I just use Copilot. Now it does some web searches every now and then. Mhmm.

and then

Go at number seven. And all of these have been pretty solid in their places, like they haven't really changed. C and C plus plus Switch, but, like, who cares?

They're the same language anyway, aren't they? Just like Java and JavaScript.

I would say I would say that Java being, like, 10% and JavaScript being 3.7% seems just that number seems fishy. Yeah. The interesting part is that according to what they're saying, common languages are becoming more common. So, like, there's a very strong consolidation in the market right now. So there isn't a lot of room for, for example, languages like Ruby, because overall what they claim is that the top 20 languages cover 83% of the market, which was, again, this is search engine evaluation.

And that's right below Fortran.

Yeah. So I think this is very heavily influenced by people like students and things like that. I would assume that C is high up because a lot of universities teach it as well, and not just like because a lot of people write actual code in it. But it's also relevant, right? What people search, like their intro to programming and things like that.

I'm just surprised that JavaScript isn't so much higher.

Yeah. Actually, maybe because it's JavaScript and, like, JS and TypeScript, and they don't, like, calculate it correctly. Yeah. And there are some weird things here. You know, Bash is considered a programming language, and TypeScript is a separate thing from JavaScript. Although, in reality, it's not like it's the same language with typing hints. So it's again, this index is not very

Logo is above PowerShell. That that's weird.

We have we have a lot of questions about this index. The interesting part is that Go was popular, stayed popular, is still number seven, like, at a solid, like, you know, person's second language, and that there's a lot of consolidation. And I think I don't know. You tell me. But on the one hand, Go is like new ish and modern ish.

Go is definitely the newest of the top 10 languages by by a long shot.

What I'm saying is the if if there's gonna be even more consolidation, and, like, no company's gonna be like, I'm gonna work in a new programming language. I'm not gonna allow it. I just wanna use, like, proven tech. Is Go already in the in the camp of proven tech because it has enough, like, I I guess the word I'm looking for is pedigree.

I think so. I mean, but but I have a biased opinion on that, so As as the host of a Go podcast. Yeah.

Actually, as a as a podcast host, you would be we would benefit from being like, oh, this is super exciting. I don't know if this language is gonna live or whatever. Like, if it wasn't so quote unquote boring. You know what mean? Yeah. Anyway, this index seems to think that Go falls in the it's old and and it's like mature enough to be considered consolidatable, and it also has raises a lot of questions about the nature of its data as well. Take it with a grain of salt.

I'd I'd I'd say kudos to Go for winning a bunch of imaginary Internet points.

Yeah. That's really important.

Welcome to our break. Thanks for sticking around this long, listening to the news. Quick updates on a couple things. Shay is doing the San Francisco meetup Woo hoo. With six people. And maybe you. You could be number seven. Tell us the details on that, Shay.

May twenty eighth twenty twenty five at 5PM, we're gonna do one live podcast recording with this new mic that I'm using right now. Mhmm. So I hope that's gonna work out fine. And there are already six attendees. We're looking for two things.

Also in Meetspace, I have agreed to speak at the next Atlanta Go meetup, which I think will be May 7, waiting for official confirmation. We'll mention on the show when it happens. If you wanna meet me, possibly again, if you already have, that would be the opportunity to do that. If you don't like Meetspace, you can also participate with the show by going to cupugo.dev, where you can find swag, which we can send to you in Meetspace. You can join our Patreon.

There's there's one thing I wanna add. Our Patreon has been going on for a while, and some people have been a member of it for for a pretty long time. So I wanna shout out Jens, Frederic, Andy, Jamie, Matthias, Joost, or I assume it's Joost, Josh, who's gonna be at the meetup, Leonid, Robert Burke, Will, Will Roden, Adelina Simeon, Kyle Skews, Doug, there are a lot of people here who have been around for a while. We really really appreciate it. Thanks a lot.

Sure. So I have a contract ending the end of this month. So that means that starting next month, I'll be free to find a new contract. If you could use a fractional gopher on your team, someone to help with architectural go related work, hit me up. I'd love to Fractional gopher. Fractional gopher. Isn't that a good title? I don't know what that says to people, but I think it feels fun.

None of these words are in the bible. So yeah, go hire try to hire Jonathan. I would think if you need a fractional gopher or a professional LinkedIn troll, he's pretty good at both. At Opsin, the startup where I work, if you're in the San Francisco Bay area, we're looking for engineers to join us. It's not Go, unfortunately. So I don't know how much this show is a good fit for hiring these people. But hey, if enough of us join, maybe we'll be able to rewrite the whole thing.

Although Once Go reaches 25% of imaginary Internet points, maybe it'll be

Yeah. Possible. Yeah. So if you wanna join up, then you can reach out and Or if you know someone who's a good fit.

I think we'll steal a lightning round and then call this a show. What do you say?

Let's go. Lightning round. Alright. First thing on the lightning round, it's for me. Do you know truffle hog?

I know what truffles are and I know what hogs are. I know they're related.

So there's a project called truffle hog, which you should probably like in every project, there are a few things you always wanna set up. Right? Like go langs the island, we talked about in the in recent episode. That's an always go to. At some point, some of your projects have to like be SOC two certified, or you know, you have to have some stuff on them.

My lightning round item is an update from a past item in a past interview. We had Joe Tsai on the show, gosh, a year, year and half ago talking about JSON v two. It's been officially accepted to include JSON v2 in Go 1.25 as an experiment. So you can still use the existing GitHub repo if you want to play with it in Go 1.24 or even older versions of Go. But starting with Go 1.25, if you enable Go Experiment equals JSON v2, you will have the new official JSON v2 package from the standard library available to you run your CI and experiment with, which probably means that in Go 1.26, it will be a full on official package available for everybody without the experiment.

Cool. Cool. Cool. New version of JSON. Why don't why don't they just use YAML? No. I'm kidding.

Now there is an idea. I'm sure they hadn't seriously considered it.

Last thing on the lighting round. This and, like, we talked about this. I'm not sure if this is proper news for the show, but I'm gonna share it anyway. There is a new Slack CLI, which is not for using Slack, it's for creating Slack applications from the command line. And it's written in Go.

It's perfect for Lightning Round.

Exactly. And the documentation looks pretty good as well, which is super important for this sort of thing.

Pretty cool. I think that's it.

Thanks a lot everyone for listening. We appreciate you all being here. Stay safe out there, have a good one, and we'll see you next week. Goodbye. Program exit up. Goodbye.