💯 Go 1.24 release party - LIVE SHOW FOR EPISODE 100! 🎙️

This show is supported by you, our listeners, who are joining in this episode live. Woo hoo. Stick around till the ad break to hear more about that.

This is Cup of Go for 02/13/2025. Keep up to date with the important happenings in the Go community in about fifteen minutes per week. I'm Sinek Mahad. And I'm Jonathan Hall. Do you feel

anything, special going on?

This is a unique experience. I mean, I've done some live streams before, but never for a podcast.

It's our live episode. One hundredth episode celebration. If you're listening to this offline, I well, thanks for listening to the episodes normally. If you join the stream, hi, y'all. Thanks for joining.

Jamie just commented. So are you still listening to this at, at

One x speed. Actually, the non live episode, we record the two x speed, and then we ask Filippo to, cut the speed down in half in the editor. Yeah. So we have a pretty cool show, planned for today. It's kind of the same and kind of different.

That's their that's their motive, isn't it? That's why they won't release it on Valentine's Day. They don't wanna ruin everybody's Valentine's by having people go to the Go party instead of their with their spouse.

Exactly. Their other significant other other than the Go toolchain. Yeah. So, we're gonna sort of we talked about a lot of the features, that have been, planned for Go one twenty four, But this is could this could be your, like, if you don't exactly remember, if you didn't catch these episodes, we're gonna go over, the release notes. I'm actually gonna use the interactive release notes by Anton.

on the app. It's gonna it's gonna ruin the entire show from now on.

No. It's gonna be fine. So without further ado, let's get started. Right? Let's do it. Cool. First up, Gofer Con Israel.

Tell us all about it and why you're not gonna be there.

Yeah. So, unfortunately, I'm not gonna make it

to Gofer Con Israel. Lucky because it's May in Tel Aviv, and by May, I'm not gonna be in Tel Aviv,

because I'm moving. But Gofer Con Israel is always a great event. I know the organizer personally. One of them was here on the show, Miki, our first interviewee ever, actually. And the team, includes some people that I've done other conferences with in the past, like, Nachshon Samarit, who who came to Orca to do a show, and Yerben Leifenfeld, who was also on the show, and like people that, have organized, the conference in the past.

be a live conference, in

Tel Aviv, but it's also recorded. So if you're if you will miss it like myself, you can always watch it on YouTube.

And I'm assuming it's gonna be a mixture of Hebrew and English presentations as as usual.

Yes. Yes. Most years, the keynote is in English, and the rest of the talks is, like, depends on the speaker and what's their preference.

Cool.

But most of the talks are in Hebrew. And it's a dual track. I I really hope they do the same this year. All the all the years I've been, it's a dual track thing. So you have two talks and you choose which one to attend. Right? Yeah.

Cool.

So you you get to, like you're not just stuck to whoever's talking or whatever schedule you have. If you're not interested in one topic, you can take the other. And they do a really good good job of, like, separating them. You know what I mean? So you won't have two topics about the same subject, like web development, on the same time slot. So, yeah, go for Khan Israel. It's in May. Make sure to, prep.

And if you're aware of other conferences or or meetups happening, let us know. We love to announce those on the show. I actually saw that Hanover did their meetup, but it just happened yesterday. And I heard it's not announced, like, two days before, so so we didn't have time to mention it on the show. Let us know in advance next time, and we'll mention it on the show. Maybe we can do a daily show. Here we go.

I don't know if there's enough action going on in Go to do a jet daily show. Yeah.

I don't know if I have enough time, even if there were.

Alright. Let's talk about some proposals. Let's do it.

So, attack of the clones or something. This proposal has been accepted, and it is the ability to clone hashes so we can start those clone wars more effectively or more efficiently or something. The basic idea, if you're if you're doing a hash, say, an MP5 or SHA-two 56 or something like that, You basically feed a bunch of data to this hash function that calculates a hash as it's going along. Suppose you had, I don't know, maybe I don't know, I might have a scenario, but let's say you're you're hashing an email for some reason. Right?

In what use case do you copy something like you've already hashed instead of just copying the hashed value? Like, if you're only hashing on the first few bytes and then you add some other things to the digest, you can save on some computation. Is that the thing?

Yeah. I mean, I I suppose this would happen like you're doing any sort of blockchain type of stuff, I I imagine. It's not honestly, it's not a use case I've ever needed or or if I have, I've forgotten. So, yeah, I don't know exactly, the real world scenarios where it's useful. Cool.

Who submitted it?

Silippo del Sorda, who we had on the show before.

The usual suspect.

Yes. Yes.

Cool. So if you use, hashes often and you're looking for optimization opportunities, now we can clone hashes. And if not, you can rest easy knowing the people who actually worry and sweat this, these details now have a slightly better API to do so.

Yes.

Instead of us mere mortals. Jonathan, you work on on Gopher JS, right?

Yeah. I'm one of the top engineers. To It it it transpiles Go to JavaScript. Yeah.

Not to WebAssembly. Not to WebAssembly. So the next two items on the docket are are kinda counterproductive, for you.

Well, I I can see why you say that. But, so actually the the original author of Gopher. Js is the one who added WebAssembly support to Go. So they're they're closely related projects. You could say Gopher. Js was the training wheels for for adding WebAssembly to Go.

Oh, yeah. Yeah. So that makes sense. What I was sort of my experience with, WebAssembly was I just tried to write a single web page, using Rust and WebAssembly, using YARH, and it was very, very cool technically and very unproductive compared to like how fast I could whip up stuff with like React which I know pretty well and then I dropped it and that was like four years ago. It seems like a lot of people have been doing WebAssembly since then for like myriad uses, but this is the first like production enterprise SaaS example that I've seen that that makes a lot of sense.

Is is my video frozen? It wouldn't surprise me.

It's not frozen. It's just, It's just bad. It's Prince of Persia levels of quality. Right? You look rotoscope and then pixels and then later on. It's it's actually kind of retro in a cool kind of way.

I'll take your word for it.

Yeah.

So I'm I'm on a bad network connection here. I apologize.

So Dagger Dagger replaced the React front end with Go and WebAssembly. Now I know what you're thinking. Oh my god, everybody like how do they have time? What's the benefit? Whatever.

Yeah. Mhmm.

Do do you remember a few episodes ago, you mentioned that really large JSON objects are slow to dango because of, a reason?

What was that? Basically yeah. Basically, the the I don't know exactly how this translates to to WebAssembly, but, the standard library Go or the standard library JSON marshaler and unmarshaler essentially buffers the entire object before it it starts writing or reading. So if you pass in a gigabyte of JSON, it reads it all into memory before it starts parsing it, basically.

So for for, Dagger, obviously, that, was a no go. So they fixed it by instead of using JSON, they used the Go binary format and used WebSockets to pipe that thing. And, you know, they used some React libraries that they still want to use, so they connected the NPM to their Go, which I assume is kind of ugly, but it did work. And, yeah, the it's really they they rewrote the thing in Go, which is interesting because usually front ends, you don't do Go and in the end, they recommend not doing this generally. When should you do it?

It'd be very rare circumstances. The the main thing would be if you had Go libraries that you need to run-in the front end. There wasn't a reasonable alternative in JavaScript. That would be the main thing I would think of. I suppose, like, you mentioned some corner cases around performance and stuff that that that wouldn't jump to mind as the solution.

Yeah. For sure. They they say that if their UI is very complex and React doesn't scale well for it, then you should do so. If you have a team of very strong Go engineers and that's everybody you have on your team, which tends to happen in like very, like, if you have a very topic centric company. Let's say you have a very AI research type company, everybody there is gonna know Python and just Python.

think about it.

No. I don't want you I don't want you all to leave the tab, so I'm not sending it. You'll have to wait until the episode comes out.

Sneaky. Just like IKEA. Once you enter, you can't leave.

Oh my god. I love IKEA. IKEA, please sponsor us. Can I do a side note? Can I do, like, a Yeah?

I I have this theory. I have have you ever played Diablo? Of course. Yeah. I I have a theory that the the, people who designed IKEA are the same people who designed the Diablo levels. Like, at any at any point you're standing, it looks like a legitimate room, but you walk 10 feet and you're like, wait. This doesn't make any sense. It's just a brawler. Alright.

Back back on track. IKEA, if if anybody here is a software engineer at IKEA, please sponsor the show. Back to even just Swedish meatballs. We don't need money. Just

Alright. So, let let me try the segue here. This is the part you never hear on the on the live show where, like, okay, what's the segue now?

I mentioned WebAssembly and

Yeah. So you you mentioned in in that article they talked about, making calls into some other React libraries and stuff like that. Historically, that has been one of the strong reasons to prefer Go for JS over WebAssembly. It's because it's much, much easier to do that with Go for JS. Because Gopher.

So if I write Go code and I add this Go directive, I can call it from JavaScript? That's the

From WebAssembly. Oh. Yeah. So it's not it's not quite the same as what Go so you can't just, like, natively call you can't your your rack app can't natively call Go functions. I think you can accomplish that as you mentioned in your article. But it takes it. It's it's a lot more cumbersome than that. It's not as direct. But from another, if you have some WebAssembly that say written in Rust, it could now call Go.

And I assume again, the people this benefits, like the developers that care about this kind of stuff, either work on, like, super high performance front end applications or work on, like, very, small no. Like, if you work on small architectures, do you use the WebAssembly as well, or do you compile to like, very small devices, I mean. Oh, some some will. Yeah. I guess, like, if you're working on Raspberry Pis or or things like that.

True. Yeah. You can. I'm I'm

just wondering, like, I really wanna meet the people who care about this stuff, that don't develop things for web applications. Maybe they have just a a tiny widget in a in a normal web app or something.

I know that companies like Fastly are using WebAssembly sort of on, like, on the edge, if you will, you know, that to to easily and quickly ship router programs or I don't know exactly what they're doing, but, you know, to to or for CDN delivery, stuff like that. So you know, in situations like that, maybe you want to integrate, you know, something some components are written in x y z language and other components in a b c language, and this sort of makes that integration easier.

Okay. I'm looking at their, customer testimonials. The SREs over at Giphy or Jiffy, if you really wanna be that guy, They use, Fastly and they're happy with it. Not sponsored. Right? But if Fastly use, like, WebAssembly and Go

to do that, I'm happy because I'm

a happy Giphy user. It's like my second most used feature in Slack.

I imagine a huge number of websites you use are are using Fastly.

Yeah. It's sort of this weird layer of infrastructure of the Internet that we are just so used to. Everything is on CDN, and everything is fast, and everything is we're just used to it even though it's in reality, it's an amazing engineering effort. Right? So this blog post is an official blog post on the Go dev blog. Right?

Yes. It is.

I really like the the Go blog as a source of, like, okay. This is what they actually care about. They don't post post that often, which I think is a good thing. They could talk about, like, every little thing. Cool.

I usually say SQL.

Okay. So you are weird as well. It's SQL. So this blog post is not about Go, and I wanna be upfront about that. It's about SQL only. But, the reason, it popped, like, into my feed in the when I search for Go stuff is because the person who wrote it, Raymond, works on, like, two Go projects, a company called Convoy IO, just like a webhook thing, webhook gateway, and another project called Light Queue, which is a test queue over SQLite in Go. Okay.

Yeah.

So you can create, like, a queue over your SQLite, server, which I imagine is very lightweight and you can embed the SQLite into Go and, like, you can build pretty cool stuff with it. It's a very small, like, very clearly a small test project, not a not a real thing yet. But this blog post goes into the fact that nulls are distinct values in SQL. Did you know that?

Yeah. I mean How? Null equals tried it.

One equals one is true. One equals zero is false. And null equals null is null.

Yeah. You have to do distinct from at least in post grads, you have to do this. Like, a is distinct from b if you wanna compare nulls that way.

Yes. But the thing is, if you insert two, like, unique rows, but you put null in one of the values, it will let you do that.

Right. Right.

I was, like, blown away. It it was very puzzling to me and actually was relevant at work at the moment. So whenever I have a blog that's as relevant as this one and, you know, it popped up on Hacker News and whatever, It's a it's a good blog post if you work in, databases right now like me, and then you remember that you have to add these, like, partial indexes to deal with it or a generated column or something like that. Like, something that is not nullable in reality. You basically add wherever you would put null, you put, like, something that looks like not a real value.

Right. Right.

Case in point, today I ordered an appointment for, like, to get my passport renewed for the flight. And then it had, like, add it to your, calendar. And then I clicked on it, and then it said meeting for object object.

Speaking of nulls, I have a notification here in Riverside. It says, issue, has a Riverside tab, has Riverside open in other tabs? Presumably, one of our listeners has Riverside open in two tabs, and it and it displays that with a a null value for their name.

Really? Is

this happening right now? It's happening right now. So, I I do wanna mention some things pulled out, or mentioned here in comments because, because I want to. We have a comment here from Andy. It says not all nulls are created equal. We we also have, on the Josh ads, but all nands are.

The I'll I'll just say all NANs all NANs are empty in their own way. But every every initiated value initialized value is different. Right? You have to leave the media tab.

Yeah. I'm just not making jokes. It's your fault, not mine. Okay.

We're gonna take a short break. This is was the first part of the show. This was news. We're gonna do a short ad break, and then we're gonna do a real, like, two minute break, and then we're gonna do the Go one twenty four release party. Alrighty. But before all that, obviously, we have a lightning round for you.

Oh, yeah.

With lots of stuff to

talk about because we're gonna empty out the backlog. Let me bring that media tab back.

Lightning round.

That's a long, setup. Yeah.

It has a lot of echo. Yeah. So you have the first item here, and I'm excited because I'm seeing, like, one of my favorite URLs, steamcommunity.com. Are we doing Factorio lighting round again?

Something like that. Maybe. So there's this bug reported against Steam. I guess, it's a bug. I mean, it's it's also in the Go feature tracker. But certain Go programs freeze when they are launched via the Steam client. So something I don't know what it is exactly, but something about the Go runtime doesn't play well with with Steam. Steam is doing some interesting weird stuff, I'm assuming, because, like, why wouldn't it? It's Steam.

If Gabe and say says it should Gabe and

The issue is long and full of stack traces and process lists and all sorts of weird archaic stuff, you know, the sort of stuff that, your significant other says, do you understand that when they see it on the screen and you pretend that you do? That's that's this issue. Anyway, I I thought it was kind of interesting to to see this come up, on Steam. Now I don't know that this means that games are written in Go that are produced on or that are distributed with Steam, although it might mean that. But I think the particular case, it's just a little utility program that is part of a much larger game.

My lighting round well, my first item for the lighting round is another rewrite in Go. I brought a company called Dagger that wrote their front end in Go. Now I'm bringing a company called Lovable, which by the way, if you haven't heard about them, I haven't used them yet. But I think they beat Wiz for the fastest to, 100,000,000, ARR. Don't quote me on that because I might have seen a different company, but they're they're definitely exploding, like a lot of people use them.

Mhmm.

They rewrote their entire Python backend into Go. 42,000 lines of code. And they go

through the one thousand in Python or in Go?

In Python. And I'm

curious how many that translates to in Go if it's more or less.

I assume it's more.

I assume it's more verbose.

So they it's very simple, the blog post. They just say why we shifted to Go, their back end is highly concurrent and parallel. That's like their workload. And they built their own dependency injection framework because apparently they didn't like anything they found in Go maybe or they didn't know it, but, like, it helped them structure their code, which I assume makes sense if they use the DI framework in Python. It's makes it a lot easier to keep the same structure.

No. I've I've I've actually wondered why a dependency injection framework is even useful. Like, I've I've I've yet to to imagine a scenario where that's that's beneficial. But, people seem to think it is because they use them.

I I think for them, it makes sense because they have a lot of, like, things popping up and out of the server, very dynamically because the agent is doing a lot of things, so it's very non deterministic, the the back end. But it's just an assumption. I don't actually know anybody yet, lovable. The I think the main number here is that deployments got lowered from fifteen minutes just to three. All request times are faster, 12% on average.

Yeah. That's pretty cool.

And they say that they're, like, practically, their engineers spend less time on performance bottlenecks than just working on stuff, like features. So for now, at least, it seems like that rewrite was totally worth it. Cool.

Speaking of rewrites, I wanna talk about something that isn't isn't a rewrite, but it helps you rewrite. You ever, write bash scripts and then it's annoying to deploy them because it's it's just annoying? Yes. Or they're slow?

Yes. Yes. A thousand times, yes.

Enter Bunster. Bunster will transpile your shell scripts into Go so that you can compile them into a single executable binary.

Oh, really?

Yeah. It's a pretty cool idea. It's doesn't support all features, yet. Apparently, there's a list of supported features, but it's under active development. And I think that's kinda cool. Cool. Cool. Cool.

Before we move into the last, item on the lightning round, I wanna pull some, things from comments here. First of all, Andy and Andy, I don't know if it's the same Andy. Thank you for putting the lightning icon for for the lightning round. Andy says well, I don't know which one. I have Go oh, I know which one. Alright. Define Andy, Andy Williams, says he has a Go apps on his Steam Deck, and it works great. So Steam Deck is their, like, hand to hand, console.

Oh, yeah.

I did the mistake. Well, if Nintendo wants to sponsor this, episode, Konnichiwa, Arigato. Thank you. But as long as they're not, I bought my wife, the Switch, which is a great console and it's a lot of fun. But then they announced the Steam Deck, like, a week after I bought it. And I was like,

surely there's a refund, period. You could've you could've taken it back.

Yeah. But she likes the switch, and also I bought some games. So but it's a good actually, we discovered it's a good platform for our child. So, it's it's good for like, I'm I'm really building on it for the flight. Right?

So we we have we we settled the question who Andy is. Andy tells us that Andy is Andy is me. So so we've got that settled. It's they're like nulls.

They're they're all the Andys are unique.

They're all unique, and they're all the same at the same time.

Yeah. And Frederic is saying that, he assumes the Go code is three times as as, longer because of if error is different from nil. But I don't know if this is just a signposting for the question mark proposal.

I don't know. I've I've been doing some JavaScript lately, and if I try to do JavaScript the way I do Go, you know, that is check every function call for errors, it's, like, 10 times bigger than Go because you have all these try catches all over the freaking place. It's a Yeah. Yeah.

It's not a lot of fun. And talking about, working in JavaScript, I've been doing back end Go. I've been doing back end JavaScript, TypeScript. That's what I'm doing, at work right now. And I stumbled upon this project. It's actually trending on GitHub. There's a project called NVM Windows. This is a live in ground, so I'm gonna keep it for ten seconds. Jonathan, do you know what NVM is?

Let's see. We're on different versions of, like, Node or or something, doesn't

it? Yes. It's Node version one.

Yeah. Okay.

If you have, like, two project let's say your front end is Node 20, but your back end is already upgraded to Node 22, you have to change your all your shims. Right? Same as Python virtual ends. So you can use pyenv to manage your Python versions or or, UV if you already upgraded. So same for, node.

Those weird backslashes.

Anyway, so there's a project called, NVM for Windows. If you use NVM in your own Windows, go check it out. The people who are working on it are working on a full time, like, company, environment manager kind of thing. They even have a LinkedIn. So if that this is a real problem for you, you know, consider talking to them.

is So that's just a yeah. Chi. Everybody remembers Chi. Right? Some of you might still be using it. Chi was my go to HTTP router until six months ago when six months ago, 01/2023 was released with the new improved serve mux in the standard library. So I've actually migrated two or three projects for clients off of Chi since then. But Chi recently released a new version 5.2.1. The only change in this is they dropped support for Go 1.14.

Well, Go one one fourteen until 01/19.

Up through 01/19. Yeah. So they they finally implemented a a, like, policy of which versions are we gonna support, and they decided to support the last four versions. So not really big news unless you're running an old version of Go and need new features from g, then you're gonna

be stuck. So there is one last rewrite that I just wanna tease and we'll we'll talk about it on the next episode. Okay. The ASDF, rewrite. Oh, yeah. I'm just teasing it. We'll talk about it next week because I'm I'm very excited about that one. We mentioned a lot of stuff related like the NVM thing, which is a you you probably use SDF to run NVM and writing bash scripts using Bunster and all that, but that's for next week because we don't have time.

And then related to that is the QWERTY rewrite called Dvorak. Where where is that where is that sound effect now?

No. No. No. No. No. Don't do that.

Sir, stay away from the vehicle, sir. Alright.

That's all that's all we have for you for the live

I think it's time for an ad break. And then,

Let's do a quick

ad break.

Let's

do it. Okay. I need that I need that media back again. Where is it?

So I'll just do Welcome to our ad break. How smooth was that, guys? I feel like if since this is a live episode, I should I should be more like, you're listening to COPO geo radio on all your five gigahertz or 2.4 hertz, Wi Fi connections. Traffic looking good today on Docker Hub. Not too many crashes on Docker Hub. If you're pulling, keep pulling. But let's do our actual ad break.

Okay.

Thanks a lot a lot a million to our supporters on Patreon, who, by the way, dictated the date of this show. That's the only poll, they had open. But, yeah, we have a lot of people in our audience. 40 people. Jamie, Sagar, David, Jose, another David, Dave Cheney.

feel free to write and chat because your support is what makes the show tick.

Rob Printless, Charlie TC, Adelina Simeon, who was on the show, and

you should

buy her books. Thomas Gall, Lutz Hannuken, s j k s k s k k s k s. I assume that's not their real name, but if that's the case,

Carlsen We still love you. You've heard this.

Bruno, Wilken Rivera. Yeah. Kristen von Kietzel, Jamie Tenna, friend of the show, who was on the show and is actually on the chat right now. Thanks, Jamie. Joost Helberg, Mateusz Kvalka, Andy Williams, friend of the show, stepped in for me a few times.

on the chat.

Will Roden and Josh Bleaker Snyder, end of the show. Oh. Thanks a lot to all these beautiful people. We never did the full run through. Right? No.

Yeah. And and and thanks for, reading those names so I didn't have to because, I'm terrible at his pronunciation too.

Jens is not happy with my pronunciation. I'm sorry. This show has ran for a hundred episodes. Yeah. We started it two years ago just based on Jonathan sending some, like, phishing messages in a Slack we were both in over two years ago at this point.

Yeah. A little more. Because because we haven't done every single week.

Yeah. We've done almost every single week. I think we missed, like

We took a break off each summer, I think.

Yeah. So went through some, like, and and we kept doing it even through, through some hard, limitations, like when I was away for three months draft or you moved countries to The States and we had to change the recording time. Yeah. But I don't know about you. This is very, very fun.

I agree. Yeah. Good to

And one of the reasons it's fun is because I get to learn a lot about Go from you, which is nice.

And I learn from you too. We learn from each other.

Yeah. You mostly get to teach me. Let's be honest here. Right?

Oh, I mean, you've taught me quite a bit about especially the security related stuff. There's a lot of thing insights there that you have that I I don't know about.

And imagine that's the things I can tell you about. But one of the main reasons that it's fun other than the fact that I'm learning is the support of our Patreons and our listeners. If you want to join this beautiful community, you can reach us at cupago.dev, that is cupago.dev, where you can find links to all of our stuff. Our Gopher Slack channel, which is where most of the, like, community chat is going, where we, for example, gave the links to this live episode and ran some polls and people post some cool stuff. It's Kebab Case, cup - 0 dash go.

And and you only see the ones I share with you. So.

Yeah. For sure. You have a full editorial control on that. If you want to support the show, like the beautiful patrons we mentioned before, you can do that. You can also buy some swag. You can the people on the live stream can see my beautiful Capa Go hoodie and our nice Capa Go, mugs. Although, non canonically, I think we're both drinking tea right now. Right?

Yeah. We are.

Yeah. Yeah. But just to be fair, it's, like, 9PM here, and I wanna sleep at 10:00.

It's two almost 2PM here. So, yeah, it's not coffee time anymore.

If you, don't want to buy swag or support the show financially, that's totally okay. A great way to support the show is to leave a review on Spotify, YouTube, Apple Podcasts, or just wherever you listen to your podcast, well, to this podcast and share the show with a friend, a colleague, a a co student, just wherever you meet other gophers. Maybe if you're planning to go to gopher, GopherCon, soon, just share the show and spread the word. I think we would have made it to, like, 20 episodes if nobody joined and nobody listened. Oh, yeah.

Did I miss anything on the on the ad break checklist? I don't think so. I think

I think we've

We're good. Done enough ad break. I think we should move on to the release party.

Let's, do that.

I like that little organ, like, Bob Dylan esque organ in the in the beginning there.

It's, Contax Carby a, 200 for all my other midi heads out there. Native Instruments. I Jens sipping in Negroni from my cup of cocoa. Love it. Love it. I guess we should add a, PEGI rating for the cups. We we need

shot glasses in our swag store too, I think.

I don't know if I

It could be espresso shot glasses or or the other kind. Either one either one would be a a a a improvement.

Yeah. Espresso wing. Actually, a good idea, Jens. Maybe I'll maybe I'll put that into stock. Let's get to the release party. Yesterday, February 12, the Go team has officially released, Go version one dot 24 dot zero. Jonathan, walk us through the, like, top items. Why do I even care other than the fact that if I'm using one twenty two, I have to upgrade because it's end of life?

So that's a good question. Because I think the things I care about are, most in this release are some of the least important things for most people. The the thing I'm most excited about actually that I'm gonna be using the soonest is the new context in the testing package.

Yes. Sync test. You've wanted to talk about that on the show forever.

Not even that. The t dot context method that returns a context, it's canceled when the when the test ends.

Oh, yeah. Yeah. Yeah.

Yeah. Because that's gonna clean up a whole bunch of context to to dos in my tests. So it's a really minor minor thing that doesn't matter, really, but it's gonna be one of the first things I use. The other one is the s log discard handler.

So discarding logs, allows you to just create a silent logger. Right? Yes. Why would you need a silent logger that does nothing?

You could always already create one, but it was more verbose and less efficient. Not that that matters a lot in tests, but it's usually for tests. You have a you have a an object that takes a logger because during normal operation, it creates logs. But in tests, you don't want the log output or you don't wanna capture it somewhere, so you can just discard it. So it's it's intended primarily for for testing purposes.

Now here's, a question for you. Should you test logging? Because I assume if you use the discard handler, you can't test it.

You should test logging, but not in all of your tests.

No. I I'm not saying test the logger. Like, should you test that the expected log output is being written?

Yes. But not in all of your tests.

In which ones? Just the, like, super important logs to care about

or something? I will generally write one test for each behavior that I want to test. So when I so I'll write one test to test that under these circumstances, the correct log output occurs. And I'll write another, test to test that under these circumstances, the correct error value is returned, etcetera, etcetera. So I

So when you use the discard logger, the the log itself happens is just directed to slash dev slash null.

Right? Basically. Yeah.

So if you do some inline computation when you run the log thing, it it will happen. That's the thing I'm worried about because

It depends on how people do like,

log, you know, server dot init and then the response, they just log it. And then if you have a thing that out, like, optimizes logs out of the code, the code breaks. You know what I mean?

Mhmm. Mhmm.

So

it depends on how your logs are done. So there there are some capabilities in the s log package that you can detect whether or not this log level is enabled or whatever. So the the discard handler basically says all levels are disabled. So if you're using that capability to probe the logger, then that code will not will not execute.

Oh, so, yeah, that that makes sense. But, generally, this is more like syntactic sugar because you could already do that. Yeah. I, by the way, disagree with you. Like, I never, test logs. I think logs have to be incidental. They're not behavior. Every program you have, I should be able to take all the log prints out, and it should behave the same. So The logs are to SDD error, and the output is to SDD out. You know what I mean?

So counterargument, delete all your logs. I use them. Then they have behavior that that matters, and then they

should be tested. We can this won't hold up in court. Very, very cool.

The consumer of your logs is very different than the consumer of your application, and and that's why the testing is done differently. But, you know, if you as the the administrator of the application need to read those logs, then you wanna make sure those logs are working correctly.

So if the my view on it is usually logs are for me personally as a person who's developing the software. But if I'm shipping something, let's say, overseas, you know, to like a a blocked network, let's say you have to do FedRAMP and you're not allowed to look at the logs and only other people are allowed to look at the logs, only in these, like, very strange circumstances where I'm writing software and the logs are being written but I'm not allowed or I can't read them but someone else has to and has to understand maybe then I'll consider testing it but definitely not for every function.

Oh, I don't I don't do it for every function for sure.

Anyway, the, omit the, like, discard logs thing is I've I've implemented this literally in every project I've worked on. Right? You start a test, then you have, like, a flag for the test of, like, wait, I'm trying to debug, but I don't like, I can't be, arced to open the actual debugger. So just print some logs and I'll add some, like, one, two, three, four, and I'll discover which line has the problem. But usually, you don't want logs in your test because you want the test output to be very clean.

Yes. Jamie We should talk about those.

Is saying that logs are operational data. I don't know if that's, argument for me or for you. I'll take that one for me because the rest agree with you. So I want to have, like, at least one point. You wanna read some of the

I agree with that too. They are operational data, but operations are important to the program. I mean, I I think going on to what Dwayne Dwayne says next, you know, if you get a bug where something isn't getting logged, it should be. Don't you wanna test for that, to make sure you don't regress. And I think that, yes, it's operational data. So the considerations are different, but they're still important considerations that deserve to be tested for the matter.

That's fair. That's fair. What Frederic says is is very close to what I did, which is testing the logs for sensitive information and, like, very specific expected keys. So you don't test every log or every whatever, you take the entire log output, then you feed it. I used to feed it to Microsoft Presidio and just look for any sensitive information at all, like secrets, keys, data, personal data, things like that because all the companies I've worked at have been cyber companies that deal with very sensitive data.

Right? Right. Right.

So so I love that. I love the fact that it's not strictly better.

There's a trade off. Oh, no.

Yeah. There is a trade off, but nearly, nearly, nearly on every single benchmark, it's better. You could go read the specific benchmarks, but honestly, I think it'll be good, just choosing the right one choosing the default one. And you can by the way, you can disable the new implementation. Like, if you actually have the need for the old implementation, you can disable it by disabling the, like, go experiment flag, which I really liked as a as a feature for a release.

And that closely relates to the other, the the general performance improvements. The the blog post here says that, in general, CPU overhead has been reduced by two to 3% across many benchmarks, and this is a big part of it. Can you That's cool.

Show me another language that gets upgraded for you, and you just get, like, very reliably on every single release between single to to to double digit performance improvements just by upgrading the toolchain and doing nothing else. We had, profile guided optimization, right, that improved everything. Then we had including compile times. I think two releases ago, we also had a really big performance improvement on, I don't remember what exactly, but but, I I remember it was there. This release is the maps.

Well, I wanna hear from the audience what their favorite features are. So while while I'm talking here, drop in the comp in the chat what your favorite features are, and we'll we'll pick some of those to talk about too. So the I think one that needs to be mentioned is the new gold tool command. That's one that I was initially very excited about because it's such a pain in the butt the way it works right now, where you, you know, to to to lay out the problem for anybody who's not familiar. If you have a a Go tool that you use, let's say, to generate some code, like, maybe, SQL c or something like that.

o API Cogen. Just throwing it out there. No no relation or no money being handed to me under the table by the chat members right now.

But anything like that, that you use, typically in a go generate, it's it's a hassle. It's a hassle. It's a dependency, but it's not a compile dependency. Right? It's a it's not part of the compiled output.

Hey, Jamie. I'm listening.

Yeah. Like, as you mentioned, I was also very excited. I'm like, my blog post was very excited about it. I am still a bit disappointed. It's not quite, as nice to work with. In particular, I get it. But the reason you have to do Go tool and then the module path to actually invoke a tool means that you can't just say, like, go to all Lint. It's go to github.com/ blah blah blah blah blah blah /command/ blah blah blah. And it's, yeah, not quite as handy as it could have been, originally.

Yep. I think the the Go team is very like, the Go project is very much crawl, walk, run. Right? You already have, like, final thing in mind, but there are a hundred thousand people you will well, maybe 10,000 people who will use this feature in the next six months. And then for 01/25, we could, like, introduce all these improvements based on the survey feedback, etcetera.

So you have to use the full module input path, which yeah. And so that's the thing. Like, yes, in the future, maybe they will add aliases and that will drastically reduce that. And then that little bit of, awkward developer experience will go away. But at least right now, it's not. So yeah.

I I feel like it's a step in the right direction, but it's a really awkward step. And and I haven't yet decided if I'm gonna use it or not. I probably will, but kind of reluctantly.

I think a really good reason to use it that Frederick well, I think. I saw a comment, from Frederick right now on the chat that a really good reason to use it is because it's gonna be in the, Go mod file. Dependabot could be, like or any other supply chain security stuff could they don't they don't wouldn't have to parse, like, go build tags for things, which I think no vendor offers today. I would be very surprised if, like, Snyk or any of the companies I've worked at, like, security companies, parse build the tags in source code to find tools that you rely on. That's gonna be pretty difficult because you don't have the full module path there.

And so kind of, in fact, like, wearing a renovate t shirt, not necessarily for this. But I was, working with the RenovAte maintainers to look at what it would mean to add support to Go tool to RenovAte. And due to the implementation of it, and the fact that it is just in your Go mod. But there is a new tool directive, which subtly changes things. So, like when you are going to update that dependency, so yeah.

So so it's not it it it sounds like it's a lot more built in than trying to parse build tags and just basically guesstimating what tool you're trying to install. Right?

But I think, so previously, if you followed the tools. Go pattern, you basically don't get any benefits with this. It's kind of effectively what happens. However, if, yes, you were, doing, like, in your makefile, go install or, like, curl to bash to install things like Golang CI Lint, you could get support through things like Renovate, and you could have other tools that would manage things. But no, it wouldn't detect it directly from, like, a tools.go.

Cool. Cool. Cool. So some improvement yet, but it's a first, stepping stone, I guess. While we have, Jamie on the phone, what do you think about Amidzero? I just saw you posted a blog post about that as well. Yeah. Although, I don't know how impressive it is to find a blog post of you about something because we're, like, celebrating our hundredth episode. You're, like, at a 10 1,001 blog posts at this point. Like, what haven't you blogged about?

Well, and, someone rightfully so took the Mac out of me for posting another very excited post about 01/24. And, I think I've kind of found that posting something like this is a great way of getting it upvoted in loads of places because everyone's like, Ah, yeah, this sounds really good. But yeah, zero is something I am very much looking forward to because, there are cases where you have structs with JSON, where you want to have an optional field. But depending on what that type actually is, the best way of doing that with the existing, and the empty would be to add a pointer to that thing. But that's a little bit painful to them work with, especially if you've got nested things.

So it's not just the zero value. It's also if you're if you have a custom struct and you have a is zero method, it will omit that based on that as well, which I can very easily see how it gets abused to, get, security, information out of, like, mark it as is zero if it has a key in it so it doesn't get logged and things like that.

Oh, yeah. It's interesting.

But the this is a really cool improvement. The best way to understand it if, Jamie's very clear explanation wasn't clear is, again, I'm referring you to Anton's live release notes. So he has the these, like, clickable release notes. You could just go click run. You run the first example and it prints, name Alice, birth date zero zero zero one dash zero one dash zero one, t zero zero, column zero zero, column zero zero zed.

I will say there is a drawback of this that, someone nicely actually replied to me on Reddit about, which is, you need to be careful when your zero value actually has value. So for instance, like age may not necessarily be something if age is zero, you don't really care too much. But there probably will be some fields that you actually have to be careful that

Wait. What do you mean age zero makes a lot of sense? If you if see if it's in years, the first twelve months. Right?

Yeah. It's the sort of thing that there may be some fields that you have to be careful about. And be like, oh, no. Actually, I maybe shouldn't use the zero value because that is a valid thing that we need to represent.

Interesting. Cool. I love how you had to, not omit the someone replied nicely on Reddit because that's not the usual case. If you omitted it, it's omit zero. We assume someone is being an asshole on Reddit.

I just discovered I can show comments on screen. Oh.

Oh, cool. Cool. Cool. Sweet. Sweet. Thanks, Jamie.

Thanks for calling in.

Yeah. If you figure out how to do that as right on Slack or somewhere, like, where people can do that. I don't think we have a lot of show left. I have, like, fifteen minutes. And we If somebody else wants to call in

and talk about their favorite feature, we'd love to.

You you have, like, a few minutes. One other feature, which is totally, syntactic trigger

that

I really, really liked, random text. You need to get some random text.

I'm gonna use that one pretty quickly too.

Yeah. And and you always have to wait, what about the seed? Oh, I can't use rand. I should use crypto and then it's a whole pain. No. You type rand dot text and you get a cryptograph of kitty random seed with a base 32 alphabet, which contains at least a 28 bits of randomness, which is enough to prevent brute force today. Super it it it's just the most practical Go boring feature that I could imagine. Right? But, you know, trying

to get random text without that is is an embarrassingly annoying pain in my opinion. It's several steps, and you have to look them up every time. It's not obvious because partly because the crypto rand API is just so bare. So I I really I really appreciate this.

Yes. And on that note, there's a lot of new crypto stuff, which we won't go into in this party because the people who already care about it, they already celebrated. Right? Mhmm. We did have the Phipps episode, so we would refer

you to listen to our

inter our our whole FIPS episode, federal information security.

Frogs in pirate suits, wasn't

it? Yeah. Something like that. It was something federal. So the US government, like, tries to do post quantum crypto.

Well, I I wanna pull out a comment here from Frederick. Let me see if I can show it. Oh, sorry.

Go ahead.

It's another tool related one. Go test now has a dash JSON flag, which will output JSON formatted test information. So not intended for humans necessarily to parse, but to integrate with tools like Neovim or or other editors or CI pipelines and stuff like that. So your, test output can be more machine parsable. That's pretty cool.

It also prevents you from having to write the output of the test to some horrible format like JUnit XMLs just because that's a standard. Right? Yeah. Yeah. I could really imagine in my last role, we implemented a flaky test service that, like, took the output of tests and tried to run them all kind of different ways and with different parameters and then see which ones fail and why and try to detect and things like that.

A clarification from from Frederick, something that that I missed. The JSON output itself has already been there. They've added new information to that output is the is the new change to one twenty four. So this goes to show that I don't output JSON from my, Go commands right off. So I didn't even know it was already there.

So yeah. The the the build failures one we talked about it on the show, by the way. You should go listen to that.

You know, I've we talk about so many things on the show, and some of them are are accepted proposals. Some are upcoming, maybe accept, some are declined. I honestly forget which features exist now now and which ones might exist and which ones will never exist. And I've actually found myself trying to use features in my coding that that have not yet been approved or or approved that aren't implemented yet. Maybe this show makes me worse at Coding Go. I'm not sure.

I would be surprised. So a lot of, new features. I think all in all a great release. I don't know how you compare this one to, like, previous years.

I I don't feel like this is like a an Earth shattering release. Like, there there have been some that introduced really, big changes. This doesn't feel like one of those. I mean, certainly nothing compared to the addition of generics, but, it's a solid release. You know, there's, there's several things that I I am I'm looking forward to.

It's not divisive, I think. Everybody loves this release because it just improves performance and adds some features, some of which are kind of, young yet, like tool dependencies. Some of them are just very useful, like, all the all the things we discussed. And, yeah, I think that wraps it up for the show. Jonathan, anything else to add? Nothing.

I think it's a good show. Thanks, everybody, for listening for the last two years. I know not everybody's listening that long, but, hopefully, we'll see you here again in in two more years for episode 200. We'll we'll see.

Well, if we're doing dailies, it should be, like, just a few months.

Yeah. Right. Well, maybe we'll

discuss that offline. Right? Or not. Thanks a lot, everyone. Nice celebration. Program exited. Goodbye. Program exited. Goodbye.