🗓️ 2025 conference preview, GoReleaser enhancements, and whether to use assertion libraries

This is Cup of Go for January 10, 2025. Keep up to date with the important happenings in the Go community about 15 minutes per week. I'm Jonathan Hall.

And I'm Shay Nehmad.

Hi, Shay. I heard I should be conversational, and we should talk more on this show.

That's good. That's a non awkward way to do that. How's the weather?

It's kinda cold here.

We have to talk about Go because, dear listener, I have a confession to make. I spent this week doing back end with TypeScript. Traitor. Yeah. Jonathan, save me. Let's talk about Go a little bit.

Well, if if we're if we're making doing confessions, I guess, I'll tell you that I've been doing a lot of front end with JavaScript lately too.

That sounds alright. That sounds like an okay choice.

Yeah. Yeah. Well, it's not fun.

No. It's not. Wait. TypeScript or JavaScript? Just JavaScript. No types. Oh. Damn.

In this show, we're gonna be talking about a security update that's coming out soon, bunch of conferences that you could be speaking at, some releases, and a few other things. I don't know. 124. I think those are the highlights.

Yeah. We have, also cool blog posts that we wanted to share a new project that's coming out. It's a bit of, a a little bit of everything. And then we're gonna bike shed, after the ad break about how to write tests. Because who doesn't like to argue about that?

I'll just skip test. That's the easy way. Mhmm.

No tests, no failed tests, no failures in CI.

That's right.

That's great.

CI can't fail if you don't have any tests.

Yeah. The the CrowdStrike way. Just ship it. I think that's the second episode in a row where I'm shitting on CrowdStrike, but it's just, I apologize CrowdStrike people. You're all you you're doing okay. Security fixes. So there is a plan to issue a security fix, on Monday, January 13, which covers a specific CVE. You know, there's a preannouncement, so you don't have to upgrade yet. Just remember to upgrade on January 13th.

So how many of our listeners do you think this, security patch is likely to to affect?

So that's actually an interesting question because the security patch impacts a specific path of code that may or may not be executed by your own code. And this sort of reachability analysis, if you go really deep into the weeds, it's kind of hard. Right? Because even if I import this package I don't necessarily call the function that has the vulnerability and even if I call it maybe I don't call it in the right context or with the right parameters in a way that might trigger the vulnerability. So how many people does this actually affect?

Wow.

According to, pkg.go.dev.

That's a lot more than I would have expected, actually.

Yeah. It's it's only presenting the the top, 20 k, so I'm I'm not even seeing, like, whether Google themselves imported somewhere, but it definitely seems like it's part of Kubernetes because it's part of someone's fork of Kubernetes, and I can't really see them changing all the log to g log in their fork. That's probably not what they did. But, yeah, it's happening through, a lot of other tools. So protobuf, gateways, SQL exporters.

Yeah. We'll talk about it next week. We'll tell you what actually happened.

I'm adding, a thing to our backlog, so we don't forget. What about some conferences?

Yeah. Let's let's talk about conferences. We haven't been following this as closely as we used to, largely because the Wiki page for the conferences is no longer a Wiki page, and it's really hard to get it updated. So, we'd have to kinda scrape our conference info from other places, but we got a few for you. The next one, coming up is gonna be in Brazil for Annapolis.

call for papers, which is funny because these are not papers anymore.

Yeah. They're not.

I don't think they've ever been, but

They did call for presentation. So, actually, it says call for speakers, but

c f CFS's.

That makes more sense. Anyway, c f CFS, or Go for Con Berlin, is open until February 23rd. So you still have a little over a month, 1 and a half, to propose a a talk in, Berlin.

Yeah. If you're based in Europe though, don't wait until the last minute because if your talk gets like, usually what happens is all the talk reviews, happen towards the end of the call for papers. But sometimes they can if you know someone at the review board or you can just send them an email and be, like, hey, I sent my thing early. Can you review it and let me know if it's good or not? And maybe I'll send another one if it's not good.

And the last one, far out in the future, this is all the all the way in August 13 to 15, GovCon UK will be back in London. The CFP slash CFS is not yet open. It opens on March 1st. So we'll talk about that again in a few months to remind you.

Yeah. It is call for papers though. When you open the the CFP page, it says the title in bold, call for papers. Yes. And they just have a cool thing of, like, sort of directing you towards which talks they're, aiming towards. Yeah. They have keynotes, which are 30 minutes, talk sessions which are 60 minutes, and tutorials which are a 120 minutes.

I think I'll do the keynote. That sounds easier.

It's yeah. Only 4 keynote sessions will be selected and 24, talk sessions will be selected. And, the and finally, tutorials which are more classroom style. So, you know, whatever, is more your type, you could take. I've definitely seen people in conferences where it's only, like, 60 minute presentations.

I think that is one of the bigger ones. I haven't been to it, but just based on people I've spoken to who have been there.

Yeah. I guess, there are there are a lot of gophers in the UK. That would make sense. Cool. Talking about Google and security, I have a Hacker News, thread which I found. I don't do you use a Hacker News, like, as a social media?

Occasionally. I'm not a regular visitor, but I occasionally browse or

So I I never, like, go visit the website, but I have a Telegram feed that, like, feeds me just the titles, and then I judge the book by its cover and choose which threads to go into. And this one was interesting, go safe web. I was, like, oh, what's this? It's a pretty cool project from, Google. Again, we're really hyping up, Google stuff, this episode.

Although the first line of the readme, it

says. Right? Disclaimer. It's a language by Google. That's fair.

The first line of the readme, however, says disclaimer. This is not an officially supported Google product. So, it's done by Google, but I guess you can't sue them if it breaks or or get support or whatever.

So so let me ask you something. Google plus, was that an officially supported Google product?

How about I believe it was. Podcast?

How about all the rest of the killed by Google, you know, site? Do you know that thing? Google graveyard? Yeah. I fucking love that. Jamboard, Chromecast, Rob Cam, Keene, optimized podcast domains. Do you remember they shut down domains in 2023? That was insane.

I'm actually surprised that Chromecast is on that list. I thought that was still going on, but I guess No.

No. No. Just out of date. Died 5 month ago after 11 years. And YouTube stories and if you go Stadia Stadia was a heartbreaker for me. Man, I really thought cloud gaming was gonna be a thing. And if you go really way back, you find a lot of things.

You remember when Google used to do search? Anyway, let's stay focused.

Yeah. Let's stay focused. It's a non official Google product, so it's probably gonna live longer than the official ones. I guess that what what that means. But what is this project and why would you care? So, Jonathan, let's say, you're at work, and you're working on something that has sensitive data, and it's an HTTP server. Yeah. What do you need to do?

Well, I wanna make sure there's some authentication, in middleware probably. I wanna make sure I'm using HTTPS.

So so you're, like, scratching your brain right now trying to, like, dig up open the folder called security, clear out all the cobwebs. Right? Right. Because usually you have some of the smarter people like Filippo and whatever taking care of that stuff for you. Mhmm.

Yeah.

Right? So, like, sort of avoiding these things, uniform, error handling to make sure you don't accidentally leak data over error, messages, and enforcing a ton of h u p security headers that you just have to, include and do correctly with, like, an interceptor that forces you the content type options and the access protection and things like that. Just things you you if you remember to do or your framework does for you, that's great, but if you don't, you're less secure as a as a server. So a big list of really cool things. I like the approach.

When you say it's early, what do you mean?

They just claim it's, this project is in early stage, and they are not accepting any contributions. So I think it's just like an internal

Google interface. The Go mod references Go 1.16. There's at least commits 5 years old. So

Yeah. I I don't the fact that it's old doesn't mean it's, like, it's not in early stage. I don't think it's, like, a top priority thing for Google. They just released it as a as an idea. Yeah.

Yeah. Set up a load balancer or something to to handle all of your stuff. Right?

Yeah. And the SSL certificates, you get them from your cloud provider or whatever. So you I almost never had to do SSL in Go. Right? Because I had Nginx or ALB or whatever wrapping the thing for me.

I mean, the last update was 3 weeks ago, and it was just updating dependencies, I guess, for some security vulnerabilities.

Actually, opening opening the issues, the top issue is state on the read me that this project is substantially unmaintained and it seems like, it's an ex Googler or no, currently security engineer at Google, from Ilano, at least according to their, GitHub, profile that says this project is large. I think it would need more work than what's currently been done to define it as a live project. I think it's safe to say it's dead. The reason being, the only application that adopted this framework internally was written by me and has since gone in maintenance mode.

I love the open draft pull request called, I think we're getting somewhere with generics.

So it's an interesting concept, but it's a good thing that, this person, Roberto Clappes, has stated that this isn't actually abandoned. So it's a it's an interesting concept. If you have a security aware thing at your company, maybe take a look, but I wouldn't build on top of it. I would just take the concepts. Because each individual concept is not that hard to implement other than the promise of, like, future proof this safe this framework will forever and ever protect us from every single security vulnerability.

One that's clearly not abandoned. So this is Go Releaser. We talked about it on the show before. They're always adding new features. Go Releaser 2.5 was released, just before Christmas. And the interesting thing about this is it's no longer named properly, I guess. They added experimental support for Rust and Zig. So now it's like the Rust Sig Releaser.

Multi language support for Go Releaser. That's super cool.

That's pretty cool. Yeah. The other, thing I wanna mention, upcoming, I saw that just last night, Go Releaser 2.6 nightly was released, and it has a bunch of cool features that even if you are, like, hardcore, I only ever do Go for whatever reason, you might appreciate this. It has capabilities or or will once it's released essentially in the next day or 2, to automatically, I guess, announce your releases on Blue Sky, on Discord, LinkedIn, Mastodon, Mattermost, and a whole bunch of other social media websites and and and Slack and things like that. So I think that's pretty cool.

Honestly, almost every Go Releaser thing, I've done had integration with Slack just as part of GitHub actions. Right? Once it's released and pushed, something lets, Slack know. Right? So CS's or other people who depend on the thing that was released, they can go out to their customers and say, hey, blah blah blah.

Yeah. Right.

I mean, it would be good. Go release is great, man. Super tight, always works, works fast, simple configuration. I'm I'm all for Go Releaser. At my previous, company, we used Go Releaser Pro. That was really good.

Yeah. Cool.

That's enough, long form news. We know the current generation is all hyped up because of YouTube shorts and TikTok, and you don't have attention spans anymore. So let's move to that lighting ground to feed you some of that good good dopamine you like. Lightning ground. My thing for the lighting ground is a really really really really really good blog post about how you

How good is it?

Really really really really really really good. You know what? That's a pretty good, question. How about you read it and I read it and then we compare our results about how much we liked it. Wait a second. You're asking how will we compare these results? Maybe we can benchmark them and then compare them with bench stat. Well, if you read these blog post, you know how to do that. It's Bartek. I think we talked about Bartek's, blog post in the past.

Oh, wow. It's been a while.

Did it have, like did you just write it to make sure that you're not going over some threshold, or did you actually try to optimize the thing?

Usually usually, I do benchmarks when I'm comparing 2 different implementations or something to decide which one failed.

So that would be perfect for that. You just need to add to your row, to your, like, your benchmark test, a row that says, oh, case 1, case 2, Bartik has an example here. It's all verbose. Like, it looks so ugly. I won't lie. It's like for case in case and then 4, like, you know, method 1, method 2, run the benchmark. And then you just run bench stat on it with minus row instead of minus new and old and you get the table comparison after one test which is really really useful. Yep. Yep. Yep.

I don't remember. Okay. I do remember. So I I have 2 quick picks for the lightning round. They're basically just resources that you could use to get more Go news or happenings in the Go community, if you will. First one's called Golang Nugget.

So what's the difference between Golang Weekly and Golang Applied Weekly? Is Golang Weekly, like, unapplied?

Yeah. Yeah. This is purely, sort of hypothetical abstract. If you want to apply your Go knowledge, then, going apply weekly is also great.

I love that, there's enough Go news for, like, a podcast and, like, 5, newsletters, everybody with their style and take. It's actually a good thing, but we hope, you know, this show gives you, like, a specific take. And, obviously, worth mentioning, go like Applied Weekly as well, which, is maintained by our friend, Kristoff, which was on the show a long time ago. I wonder if if we pull out that episode, how old, Filippo's gonna make it sound in the edit.

So, Si, I just got a copy of the applied Go weekly newsletter, and it has a really good article. Have you seen this this newsletter? Of course. I follow it. I really like the recently, I it's going to AI and stuff. Wondering who's writing it. Oh, wait. Yeah. I don't know. We we should find out because I mean, he just shared one of my videos and so, you know, he's not a super guy. That's a good day. So Yes. Oh, hi, Kristoff. Welcome to the show. Thanks for having me.

And that does it for the lightning round. Let's do a quick ad break before we jump into a bike shedding discussion about Goethas.

I can't wait.

Welcome to our ad break. This podcast is sponsored by Blockbuster.

I don't know how to say that.

I thought it was sponsored by, things that were, you know, really cool in the nineties.

Okay.

Oh, no. Those are our listeners. Never mind. Never mind. This show is sponsored by our listeners. Actually, I'm wondering what's the average age of, the list like, the listener to the podcast. I might be totally off, and most people who listen are, like, 18 or something.

Good question. I don't know. I would imagine I would imagine older than 18, but probably younger than me. I'm 45.

Don't let me phrase this in a wrong way, but it's easier to like, I think the average is to be younger than you.

Yeah. I think so. I think I would expect the average to be I would I would expect late twenties as an average probably. But I don't know.

Actually, I like I love the fact that podcasts don't have great analytics because I would start obsessing over them. But just getting a slice of, all the people who listen to the show would be cool.

Speaking of analytics, I I can hop over to YouTube and see who watches us on YouTube at least.

Oh, that would be cool. Why don't you do that while I tell, the nice listeners about how we are actually sponsored? Because we're not sponsored by Blockbuster. We're not sponsored by anyone. This show is self supported with the beautiful Patreon members.

Yeah. But, yeah. That goes to me.

But he lets me know when things, go through. Yeah. You can also find links in the site to past episodes with all the transcripts, all our social media links, less than go release our offers, but they are there. I don't think we have Blue Sky, Mastodon, and all that.

We have we have Mastodon. Do we? We have.

I'm not on Mastodon, so I wouldn't have.

We have LinkedIn. We had Twitter, but I closed my Twitter account, and that likely closed our CupidGo account too. I'm not sure.

I think it's still it's still kicking.

It must still

We need to ask Elon, I guess. Yeah. And, you know, we need to make sure that our episode have right wing enough titles so the algorithm picks them up. That would be a fun experiment. Maybe we can release an episode just named Jordan Jordan Peterson, Alex Jones. What are their contributions to the Go language? Also, what happens when you put the January 6th, date into the Go lang date format? That's probably gonna get picked up. Or alien it or a left wing listeners. Anyway

Some of our listeners have just sworn us off now. I don't know which direction they're leaning politically, but they're no longer listening. For sure. Alright.

Also, if you wanna support us and you don't wanna support us financially, that's totally fine. You can leave a review, or share this show. Setting like, spreading the word about the show is the only way it gets around. We don't pay for advertising. So leaving a review on the whatever app you're using to listen to this whether it's Spotify or Apple Podcasts or whatever or just sharing the show in your jobs like Slack channel being, like, hey.

Yeah. So not great. What I learned about our listeners on YouTube is that 54.9% of them are subscribed to our channel.

That sounds good.

When I go to the age and gender, tab, it says not enough demographic data to show this, report. So no idea.

Alright. Isn't 50% really good?

I guess so. We we we seem to have a 164 subscribers.

Oh, that's cool. That's cool. Well, if you use YouTube

Oh, no. I'm wrong. We have 366 subscribers.

That's still cool. Well, I guess if you use YouTube Music for your podcast. Right? Then you would find podcasts there.

Anyway, thanks for listening on YouTube, if if that's you.

Yeah. Thanks for listening, in general, everybody. That's all the normal things we have to say. Go click on all the links we told you to and leave a rating and do all the things. Thank you. So, Jonathan, do you write Go tests? Yes. I do. Usually, when you write your tests, at some point, you wanna assert that the thing you got from the function is the thing you want. Right?

Mhmm.

How do you write that?

Depends on what I'm testing. I know where you're going with this because I I looked at the the post. Mhmm. I guess I can just TLDR. I already do the thing he suggests.

So Michael Lynch has a blog post that sort of kicked off a really, really Reddit ish thread of people, like, bike shedding about how to write tests. The TLDR of what he's saying is, don't use any third party library for assertions like testify or is or any of these, libraries. Rather, write if like go has this thing where you have an if then an expression then a semicolon and then the condition. Right? The binary condition.

So the one nitpick I have is I always like my want before my god, and there's two reasons for that. One is I think it's more readable. Using this pattern, if your if your expression for your god is of inconsistent length, then you have to sort of scan different parts of the line to find what your want actually is. So I like to have the want first for that reason. I think it's visually easier to put that first.

I actually before you move on, I actually do that as well, but for a totally different reason. Okay. It's because in when I learned c plus plus like in 2012, I read the twin effective c plus plus and it says always in ifs put the constant on the left because you can accidentally do if a equals b, 0, not a equals equals 0. Yeah. So that's sort of got ingrained into my, like, muscle memory, and I do it in every language, even in Go where, like, it it can't happen. Right?

I also do that just because it feels right, and I never knew why it felt right. But that's it probably goes back to learning it for those reasons without realizing that those are the reasons.

Yeah. That's like, just the cultural DNA of, people who started in, old language. Anyway, so that's the first reason. Yeah.

The second reason I prefer want first is when I'm using a tool like cmp.diff. I think the diff is easier to read if the expected value is first and the actual value is second because then I know that pluses are extra or different and minuses are things that are missing. Flipping that around to some people, I guess, maybe like it the other way, but I feel like it's just less intuitive to read a diff where minus means that should not be there. Yeah. So that's the other reason.

So the reason I don't like this, and this might be slightly controversial, is I know Go is a simple language and you shouldn't use something that isn't standard library for things, but, honestly, testify is great.

I think testify is so bad.

Or or any testify ish, library that just gives you assert equal, nil, is error, expect error, like, all these, you know, require and all these sort of testing niceties that are just a very, very simple API that looks really, really good. Is equal, is true, is nowhere, is fail. Yeah.

I I disagree with most of that.

Like, you don't think it looks good? Or I don't

think it looks good. I think it's hard to read. And and there's 2 parts of that. First, the testify API is inconsistent, and that's what I hate most about testify. Like, in some cases, the want comes first.

There's a comment here on Reddit that I I really liked where someone said I like, basically, my opinion. Right? I don't like this style as after hundreds of assertions, this starts to get very verbose and repetitive. Is and go CMP mostly does fine for me. An assertion shouldn't take more than one line in my opinion. That's crowdy river on, on, Reddit. That's an okay ish opinion. Right? That's basically what I'm saying. The response here is just so Reddit.

My response to to that would actually be more nuanced. That is if the tests are too repetitive or difficult to read, then they need to be refactored just as normal code that's too repetitive or too difficult to read needs to be refactored. So tests or code treat them as such, and then I don't think you need the assertion libraries anymore either.

Yeah. The only thing I think you would use is cmp equal for structured data. Right? Because you don't want Yeah.

I use cmp diff for for structured data usually. Yeah. And I also don't understand this assertion shouldn't take more than one line. I I guess that just they don't like the three lines of if x equals y, then t dot fatal, that they feel like there's too many lines.

Yeah. That it's I think it's a reasonable thing to say, I'm gonna write a a 100 tests, and each test is gonna have 10 assertions, in the next, like, year, making it shorter and easier to read, in my opinion, or in this personal opinion is interesting. I like that. I like the justifications that people come up with in this, thread. Like, Google uses this, like, sort of, you know, going to Google code as authority, maybe.

So you you made a point about, readability, which reminds me of a conversation I had on LinkedIn, of all places, recently, about code readability. And you you said that you like the the shorter assertions for for greater readability. Of course, readability is a very subjective concept. If you're fluent with testify, then many of those assertions will be readable to you. If you're fluent with is or with, JUnit or whatever, you know, then you'll you're gonna find those certain idioms to be readable.

Yeah. The the author actually responded here and said he understands both perspective perspectives, and it's a close call. So I think that's, like, the best way to summarize this discussion. Doesn't super matter. Like, at the end of the day, there are things in, like, about test cleanliness that are way, way, way more important.

Alright. Cool. Cool. Cool.

So And write tests.

I think that's the conclusion. Right? Write your tests.

Definitely write them. Don't don't have AI write them. That would be crazy.

Speaking of AI, I found great success having Copilot rewrite my tests, from, one framework to another. We had a bunch of tests written in Convey, which I think is terrible. It's much it's much more than a search library. It tries to, like, take over everything about your test. It does BDD or something. Right? It's it's I think it's not even that. Like, maybe they tries to, but I don't know. It's weird. But I I used it.

Cool. Well, I guess I know what you're answering about using AI in the next survey. Lowering the usage of third party libraries and subscribing to the standard library. There we go. I'm sure they'll like that answer there in the Go team.

I think that's a show.

Thank you for listening, everybody. Program exited. Bye bye.