🎹 As simple as Do, Re, Mi, Go 1.23 (rc1), baby, you and me!

This show is sponsored by you. Stick around until after the news to hear more. This is Cup of Go for June 28, 20 24. Keep up to date with the happenings in the Go community in about 15 minutes per week. I'm Jonathan Hall.

And I'm Shay Nehmad, and everything is back to its right place. We're doing an episode. It's Friday morning. We're both tired.

We're both tired. Yeah. I I haven't even had coffee yet. Have you?

Of course. Awesome. I drank I drank coffee out of my brand spanking new, DevOps Days Amsterdam mug Oh.

That they gave up. Rooster's got some competition.

Actually, I think they're using the same supplier because it has the same thing where, you know, the outside of the cup is white with a printout, and then the inside has a color. Okay. Cool. So I guess the imitation is the sincerest form of flattery. Right?

Yeah.

We see you, DevOpsDays Amsterdam. We see you, and we appreciate you.

Well, let's jump into the news. You were surprised by this 1. Tell us what it is.

Yeah. It's just the time, man. The time is blowing by so fast. Go 123 release candidate, 1 is released. I'm not gonna call this release, 1.23 even though that's, like, the the version. Yeah. It's go 123.

So are you gonna are you gonna use it? Is it just go 123 is out? Or are you gonna wait for the point release 124?

Easy as ABC.

Yeah. Anyway,

so, yeah, there's a release branch, of Go 123. And this is a really good opportunity if you want to set up your CI pipelines to build, you know, the new version, start migrating all your linters. This is a really good version to do it in. In my opinion, not for your production application since it's still just the first release candidate, I wouldn't trust it. But it's very good for the community.

The big 1 here, which we won't go into detail, is Range Over Funk. We talk about that a lot.

And we're gonna talk about it later on in the show as well. Yeah. So this is a big 1. Telemetry is now a Go telemetry thing. Like, there's a command.

Sadly. Yeah.

Yeah. We discussed how to someone on Reddit was like, how do I prove that I'm good at Go even my even though my work experience is from another language? I think that's a great way to do it. Right? Mhmm.

Right.

So 1, 2, 3.

But if you do wanna upgrade sooner than that, we have other good news for you. You got 1.22.5 and 121.12. That's a nice near palindrome. 121 12. We'll be coming out on Tuesday, with a secret vulnerability fix. So I can't tell you what it is yet, but next week we'll talk about it.

As usual, just, always use the latest patch. It it won't cause any backwards compatibility issues almost for certain.

Almost for certain.

Alright. Let's talk about some proposals. We missed out on proposals last week because we recorded the episode, a bit too early. Mhmm. But there's 1 I really like, and I think everybody can get behind. So, you know, go FMT. Right?

Oh, yeah.

I love it. Even though you you'd slightly less prefer it to GoFump. Right?

Yeah. I I like GoFump over GoFump, but yeah.

So there's a behavior change which I really, really liked, suggested by the way by, Daniel Malti, Q lang maintainer.

And the Go fmt maintainer.

And the Go fmt maintainer.

Which means this will probably be added not only to Go fmt, but also to Go fmt.

I just wanna clarify for our listeners. There's go fmt, and then there's go FUMPT. Yep. Both of which format your Go code. The latter being, maintained by a really cool guy, and it's a bit stricter, so it's nicer. Less things to argue about. For me, it's like part of the basic package. Right? You open a new package, you set up golangciilint, you set up go fmt, you set up go test, and you're, like, you get

That's it.

So, you know, if you wanna run things like, go mod tidy or, you know, go test in ci, go lang cilint in precommit or in CI? What would you want to happen if there's an issue?

I want, I want to be notified and probably my PR fail.

Alright. That's

true. Failure if it's not quite up to to the bar.

Yeah. So the way we decided overall to implement it is if the process exits with a number that's not 0. Right? If the exit code is 1, then your pre commit hook will fail or your, like, CI pipeline will fail.

Exactly.

This is true for Go test. Right? If you're on Go test and if test fails, you get a output, like an exit code. Many other tools are like it. Go FMT isn't like that. And this proposal just got accepted to just align that behavior with a lot of other tools in the Go tool chain and also in Linux in general. So if you run go FMT minus d, it will exit, with 1 if diffs exist.

Yep. I love it.

This is a breaking change, like, in a sense, whatever. But I think Russ summed it up pretty nicely that it exists and Go does have a compatibility promise. But for tools, the the compatibility promise is not as strictly regulated. Mhmm. Which is nice because, you know, they sort of overlook that 1 and they feel free enough to fix it. If you have a script that breaks, it's very easy to fix it. Right? You just add pipe pipe, true or remove the minus d flag, and you're good.

Yep. I'm I'm a fan of this 1.

And it got accepted. I believe it's also very easy to implement. I don't know if there's a branch already, but seems like an easy 1 to implement.

And this proposal was 1 that was, actually brought up on the Cup of Goat channel on Slack. Dwayne Schultz did a shout out when it was only likely accept, which was just a few days ago, but now it's completely accepted. This is 1 of his pet issues, if you will, that he's been looking forward to. I know how that feels to have 1 of your pet issues finally accepted.

Yeah. Thanks, Dwayne, for, pointing it up. Alright. We have 2 other accepted, proposals to discuss. List of deprecations and newer available dependency versions. Haven't we talked about this 1? It feels like we already saw this 1.

We did. So this is actually a follow-up to a decline proposal that we talked about not too long ago, a few few weeks ago. The idea of that proposal that was declined was to emit an error or a warning message whenever you, run go get or something and you're downloading something that's not the most recent version. That was rejected as being too intrusive, maybe not Mac compatible. So this is a new proposal to add a new subcommand.

A new subcommand to the Go tool chain?

Yes.

Oh, we're piling them up. We have now Go telemetry. It's getting it's getting a little crowded in here.

So the final version of the accept proposal is to add go list, options to list deprecated or outdated versions of your dependencies. So it it won't automatically, like, throw spam in your face about XYZ version is outdated. But if you want that information, you can easily get it now through the GoToMan tool instead of having to, you know, go out to the slow, boring interwebs to look that stuff up.

I wonder, like, that sounds like a thing I would immediately integrate into tools like Dependabot or Snake or, you know, Orca shift left. Like, I would try I wouldn't I I can't see myself actively going to my project and running it, but maybe, like, some automated CI step, like filter just on major upgrades and just, like, write a comment on a poor request or of automatically file an issue. I don't know. Like, thinking back on upgrading Go packages, I don't think I've had a lot of issues upgrading packages. But I haven't really done it in projects where I didn't know all the dependencies pretty intimately.

So, I mean, I I actually work on a project. I've recently worked on 2 projects to do that. But what I'm doing now is is just use the dependent bot, which only, notifies us of security vulnerabilities. But I actually kinda liked, we had a workflow at a previous client that did this for all new version updates. It was kinda handy.

I do think it's great how we kept the exact same functionality, but just making it basically a change just to the UX. Right? Instead of it doing it automatically, we put it in a tool, then it's like a la carte. If you want it, you can take it. If not, you can skip it.

I have a miss My wife just brought me some

From a tiny, tiny cup.

Tiny cup.

This episode is tiny cup of go, brought to you by a couple of tiny gophers.

So anyway, what I thought about

anyway, sorry. What I thought about was, I just read a blog post from, a blog we're gonna discuss in just a second, kmcd.dev, where he has a dependency on some Hugo template. Right? That does charting. And he tried to upgrade that dependency, but ended up discovering that a sub dependency that was actually important, char.

And can I insert a little rant here?

Of course.

1 thing I want a tool to do, and I don't know how you would do this, is I want a tool to tell me when a library has been deprecated and superseded by a fork. Because I actually had that fight me this last week. We had a a bug in a library that hadn't been made updated in 3 years. It was archived on GitHub, but there was a new fork available that somebody had made. It was just a drop in replacement and had the bug fixed.

That sucks, man. I I'm trying to now that you say it, it happened to me, like, a few times, and I can't believe there's no built in thing that does it. But I guess, like, how would you declare a library as, like, abandoned? There are quite a lot of libraries that I I like in Go that are totally dormant. Like, there are no issues, there are no pull requests, there's no whatever. Not because they're dead. Just not because they're abandoned, just because they're done. Right? Right. That's cool.

Yeah. Exactly.

So would you want the tool to mark repository as stale if it's still, like, all good? Just old? No. So how would you mark it? Like I don't know.

So I I suppose, you know, GitHub and maybe GitLab and some of those, services let you archive a repo. And that might be interesting to know that the repos would archive. And and that could possibly integrate into this existing tool that that we're just talking about, just to tell us, you know, this 1, there's no new version, but it's been archived. So maybe it's something to look for an alternative.

Alright. I think next to our, other meta tasks, which include, you know, trying to find that 1 guy that doesn't have his cup yet and implementing an episode serger and doing a new intro for season 2, and the auto tag, all the old stuff is 2 weeks. I'm adding create a proposal, for archived repos. Let's see if we can do it.

Alright.

If you want it to not get accepted, I can open it. But I'll I'll I'll open it. I I haven't done any any issue work in a while. That would be actually kinda cool. Cool. So we talked about, list applications and newer available dependency versions, a very simple sub command, and then we ran that about dependency management for a while because dependency management is hard. It is hard.

1 last proposal update. We talked about this already, so I won't go to the details. But, it's been accepted, the proposal to allow a mission of range variables when ranging over a function that returns 2 values. Mhmm.

May

recall we talked about this with, you know, what what if the second value is an error? Is it okay to skip over that automatically? Blah blah blah blah. The the consensus, at least as the Go team defines it, was to make it match all other range, capabilities. So you can do 4 x comma y colon equals range blah or xcolon equals range blah, which is the same as x comma blank, or you can omit all the variables entirely and just range over the number of iteration.

So I just I just don't want someone to accidentally use the not accidentally. Like, the first version of their code, they don't care about the error, so they don't iterate over it. And then when they, like, go over the code and refactor it before pushing to to a a pull request, it's not immediately obvious that you skipped the error. Right? Because it's not an underscore that's, like, ugly in your eye.

That's a fair amount.

Do you like it?

There are definitely things I like about it and there are some, some annoying edge cases as well.

So if you don't know, this is a rare chance where we're not just talking about a basic Go feature. GRPC is sort of a high performance RPC, remote process call framework, which uses protobuf under the hood. You define messages, and then you can implement a server and a client that, do remote process call from 1 another. And, it's for me, it's been super useful just in my career in general. I've even given talks about how to use, like, gRPC and protobuf as a source of truth for your entire rest things and your entire API and sync everything into 1 protobuf file, etcetera, etcetera.

I wouldn't say it's why it's bad, but it talks about some bad parts of it. Yeah.

Yeah. Which is interesting because gRPC has, you know, approaches a decade of usage. It's not a new technology anymore. I think about it as, like, cutting edge thing from Google. But at this point, it really shouldn't be. Right? Many people don't get into it. Many people have a hard time with it. And I think Kevin here touches really interesting points why. He talks about the learning curve, talks about compatibility with the web.

I like the closing here where it says it can be and is better, and then it offers some kind of ways to overcome some of the shortcomings.

Yeah. Again, it's you could use it as a grocery list of, hey, I wanna implement gRPC, and I'm already sort of, like, preparing for a debate. I already know what's gonna be hard in in my company, so I'm gonna prepare for it. Like, the learning curve is hard, so I'm gonna do a small workshop instead of just sending people the the documentation because the documentation is kinda rough. Rough.

Awesome.

Which I'm definitely down for because I don't wanna spend any more time in my life debugging, random JSON schemaless data. So it's 2024, folks. Let's stop it. Alright.

I think that's a show. Let's, that's a wrap. Hop over to our wrap up. We don't have an interview today, but we'll have a little bit of banter after the show.

For sure. This show is sponsored by you, our beautiful, beautiful listeners, but specifically our beautiful Patreon members.

We've had

2 new, Patreon members since our last episode. Thanks a lot, Thomas Goodyear and Ranageth for joining as members. This is a hobby we do, to stay up to date on what's happening in Go and being able to use it at our jobs. But it's a pretty expensive hobby, mostly paying for editing fees, hosting fees, etcetera. So you know the drill.

I have to share a short story then. I was at the airport, as you know, last week instead of with you at the live recording. And there was a 5 year old girl or so probably, who saw my laptop as I was going to security. I had to take my laptop out of out of the bag and everything. And she saw the the Cup of Go Brewster sticker on my laptop, and she was looking at it.

Yeah. She she walked around with, like, the rust book. Remember that scene in x men where Will Smith is like, they have to shoot the aliens in the alley and Will Smith is shooting that little girl?

Oh, yeah. Yeah.

Walking around the neighborhood with a physics handle.

The men in black, not the X Men. You said x men.

What did I say? X men? No. Will Smith wasn't in x men. Luckily, I think. Not a good fit. So anyway, if you want to, give little gifts to little children at airports as a stranger, you can buy stickers, cups, hoodies, and shirts, on our swag store. You can find all these links at cupago.dev. That is cupago.dev. You can also join our vibrant community on Slack.

I think so. See you next week.

Awkwardly, are we done?

Yeah. No. I think

you're done.

I wish we had an outro to make it clear.

Yeah. So we need your we need your help to un awkward, this part of the show. See you. Bye. Cheers.