What's coming in Go 1.25? Plus Redowan Delowar on what makes Go different from other languages

The show is supported by you, our listener. Stick around till a little bit later to learn more about that. This is Cup of Go for 06/20/2025. Keep up to date with the important happenings in the Go community in about

fifteen minutes per week. I'm Jonathan Hall. And I'm Shay Nehmad.

Hi, Shayne. It's been a while.

Hey. Yeah. I'm very happy to have you back on this show. It's so difficult to do it on my own. Yes. My appreciation for you doing it yourself in the past has increased.

I've only done it once, and that will be the last time.

You know what? I think I could I I I have, like, once a year. You have a once a year ticket to be like, oh, I can make it do it on your own. Yeah. We have a pretty cool episode. We combed through the proposals, and there wasn't anything super critical. So, we have some more conversation y conversations, today and an interview with, Redawan. You might remember we mentioned his, DI blog post a while ago. Oh, yeah.

This blog post comes from Redawan Delaware. It is called You Probably Don't Need a DI Framework. And I have to say I was very happy to read this not because of the content per se or the opinion it expresses, but because it explained to me what a DI framework does in Go. I've been wondering this for a long time as I've never used one. And I I do agree with the conclusion that that aside.

So we'll be talking to him at the interview part interview portion of the show. But I wanna start with the 125 r c one has been released. Woo hoo. RC stands for release candidate. We mentioned this, like, every six months or so because every six months or so, there's a new major version. What what does release candidate mean?

Well, it means that as far as we know, as far as the Go team knows, this is ready to be released, but there's certainly a chance that they're missing something and where they want it to be tested. So if they find a showstopper, then RC2 will be released after they fix that showstopper. If no showstoppers are fined and found, then this will eventually become Go 1.25.

And the cool thing here is how they they'll just, like, use it, put it in the production load test and the unit test. Like, nobody's suggesting put it in production yet. Yeah. If you already have Go installed, there's a very easy way to install that this specific version with Go directive. So it's Go install, and then you point it at, like, the latest version of one twenty five r c one, and then you go do, like, a Go one twenty five r c one download, and you got it.

The interactive one. Yeah.

Yeah. And so we, had Anton on the show, actually.

My name is Anton. I do some open source stuff, and, I write, interactive, maybe I can call them guides or books and, interactive articles on my blog. That's mostly what I do in my free time. So that's it.

So I've been using this I don't know. Have you been using these release notes instead of the official ones?

I wouldn't say instead of, but in addition to sometimes. Yes.

I know. I would say instead of. It's much easier for me to read this than the official Go blog. And one twenty five hasn't been released yet. So you'll you'll have to stick just with one source of, news about the changes. Actually, two because we also tell you about it. Right? How does, you know, running RC any RC worked out for you in the past?

I haven't done it a whole lot, but I've never I've never found a bug by doing it. So

Yeah. That's the same for me. Like, I really always hope to find the problem and be, like, the one hero that's like Mhmm. Oh, here's the crazy compiler bug. But it just works for me. I guess I don't do anything, too out of the ordinary with Go yet. So r c, one twenty five, r C one. I guess this is a pretty easy way to try to contribute to the Go community. Just run it and see if it works.

I'm curious if there's anything in 125 in particular you're looking forward to, Shay.

I'm actually looking looking forward to is kinda weird to say about the garbage collector. Okay. But I'm I'm excited about the experiment. Like, making the language better just behind the scenes for me and just making everything faster is the sort of silent, maintenance work that I'm very excited about. I like the new vet of analyzers that will replace all the, host port, for, like, constructing addresses because that's a code review comment I always give people.

I feel like the last maybe three or four versions have had have had bigger changes. You know, introduction of SLOG and and new testing things. And I I don't remember what they all were, but I do feel like this is a fairly low key upgrade. Having said that though, the one thing I am excited about for this version is the introduction of testing sync test, which was already in 01/2024 as an experiment. That experimental flag is being removed.

Yeah. And there's a ton of changes in, crypto Of course. Including the FIPS mode, which we mentioned, which I'm not excited about because I'm not implementing any government level, applications. I'm glad it's there,

but it won't affect me personally.

Yes. But I am excited that it is there because it makes it, it makes proposing Go as a back end language in enterprise context, especially b to b enterprise context, much, much stronger. Like, you know, there's usually the argument of, oh, let's use some annoying, you know, dynamic language like Python or TypeScript because we could move fast. And here's like, okay, but there's gonna be like a nine month long project in two years from now making our TypeScript app FIPS compliant so we can sell to to the government. Like, OpenAI is selling to the government right now.

All right. As you said, we're gonna be a little more discussion y today than we often are. I found a post I found it on Reddit, but it's a regular blog post, so we can find it other places too, called Go should be more opinionated. And I thought this was a little bit of an interesting take. One of the perks of being a Go developer expert is the incredible opportunities it provides.

I don't think it's nice. I think it's actually toil, like unnecessarily toil. Mhmm. And, you know, it's the sort of thing that I don't wanna waste my time thinking about. If objectively there isn't one project layout that's perfect because not all projects are the same.

Yeah. I agree with a lot of what you said. I'm a little torn though. Like, is it the place for the language to have that opinion or is that a place for a framework? And then of course that leads to the second question of, don't we hate frameworks in Go?

You know, there's a a blog post about how to do structured logging. Right?

Mhmm.

Structured logging with SLOG. It's in the standard library. If you go to the Go dev blog, you can find it. Right? Yeah. There is how to do, reproducible Go tool chains. Right? Although you could have done that with a separate tool, a shell script and your own thing. Right?

Maybe.

There is how to, do a lot of things, and the project templates experimenting with, project templates, which is with the go new command. Right? And they've written, like, two templates to get you started. But it definitely feels like, you know, if you want to do logging, this is how the Go team tells you to do logging. But if you want a project template, oh, here's the project and here's a command and here's a few, like, easy, templates to get you started that aren't really that deep.

Of course. Yeah.

So I don't know how how great it would be. Maybe an area where AI could actually be useful. Oh, yeah. You know? It seems like the sort of thing. Right? Look at 10 examples at how people have used the template and then improve the template. But I don't know. Maybe I'm just being hopeful.

Well, speaking of being hopeful, I think you have a topic to talk about that's a little bit in the same vein as hopeiness.

You wanna try a different, you wanna try a different I know you're tired, but I know you have something better in you. I don't. So project templates. Cool. One final blog post I wanna share is from, kmcd.dev. I I I just looked at that domain for a second. I was like, oh, it's like xkcd. HTTP Query and Go. It's a pretty short blog post if you're in into, like, networking and Go. You should just try and read it.

It's to fetch a a document or an object.

Okay. And post.

Everything else. So

I think that the concept is you use GET for, like, simple, queries to fetch a document on the web. Mhmm. Use POST to theoretically imply something that would change. That's why it's called GET, you get something, and POST, you post something for the server to use. But GET isn't great for complex data retrieval.

Or even just a simple list of a thousand different IDs you want to fetch.

Yeah, because there is a limit on the length of the URL. Right? Right. It does have a practical length limit. I think it's somewhere around 2,000 or 8,000 characters, something like that.

I think it depends a lot on the browser and the the servers and caches and and proxies involved too. But, 2,000 Yeah.

That's why that's why I'm saying, like, most modern servers, 8,000, but all you need is, like, one old version of NGINX running somewhere along the chain, and you're like, oh, it's 2,000 actually. I use, by the way, for GET query parameters, to try to make it nice, something called QS to like a it's an n simple NPM library that just, like, allows you to create the nested object. So the URL looks kinda funky, to be honest. It has a lot of, like, square brackets and it looks kinda funky. But in terms of code, it's nice because you, like, serialize and deserialize the object, but then it turns out to be really long.

Mhmm.

KMCD here proposes a new method, query, which is like, tries to bridge the gap between the use of get and post. Mhmm. The input is in the body, not in the URI, but unlike post, these are safe and idempotent. So you can do like a GET with caching and automatic retries, which I wouldn't want to do with a post request. Like, if I had to implement a GET using a post just because of length limits, then suddenly in my and you wanna do like an automatic retry or cache the result, right?

I have to wonder why not just modify get to accept a body? Why do we need a new verb?

I think with the current verb, it's so overloaded, but most servers won't let you pass a body with GET. They'll let

you pass a No. But they don't they don't they don't let you pass a query either. So, like, is it really any different to change to expand the GET semantics versus adding a new verb? Maybe it's just clearer, but, like, logically, it seems like a GET with a body would solve the same problem.

I think GET doesn't carry a like, GET will not carry a payload. Even if it's the spec would change at this point, it's like I think it's called the Hiram's Law. Do you know what I'm talking about?

Yeah. That

oh, the old consumers depend on this, implicit interface. Even if they change the interface, this is a law already. This is like set in stone. The servers will not accept the payload. And if someone tries to pass payloads and get, know, they might get stopped by like enterprise, firewalls that use this as a rule to detect the malware trying to leak stuff.

That's probably a big part of

I I wouldn't like, if I were to implement I I we used to work at a network micro segmentation company, like a firewall company. If you ask me off the top of my head, the top, like, 10 rules, probably slotting it at number seven is don't have any payloads in HTTP things that shouldn't have payloads. Just based on, like, experience of how malware works. Cool. Let's jump to a quick ad break.

Oh, yeah. Wow. That was the episode from February with, Carlos Becker. Yeah. The author of GoReleaser. Yeah. So that's our best downloaded episode ever. That's awesome.

I guess that's his fault maybe. I don't know.

Thank you, Carlos. Come back on, please. Give us some more listeners.

And by the way, closely behind it, there's a very recent episode. Like, the February episode had some time to cook. It's been, like, five months. But the next one after it is the Ian episode. Yeah.

Well, I think that's it for the ad break. I don't think we've forgotten anything, but we do have a great interview coming up.

Yeah. And, we're skipping the lightning round today to get to listening to our interview with, Redawan.

There it is.

So stick around for that. Hey, Jonathan. Hi, Shay. Would you say I'm dependable?

Well, you were a couple minutes late to this call,

but you did show up. That's true. That's true. But, generally, would you define me as dependable? Generally. Yes. But what if you needed to, like, bring a different cohost? You have to, like, inject some other dependency. Yeah.

I suppose I'd need to come up some sort of framework to handle that for me.

Yeah. That would be kind of difficult. I wish we had someone on the call who was an expert on such matters who could help us. Oh, hey, Red One.

Hello. Welcome to the call. Welcome to the show.

They're they're all of my intros are bad, but that was one of the worst.

Oh, they just get worse every time. So next week, this will this will no longer be the worst.

That's great. That's like the Simpsons thing. It's the worst day of your life. No. It's the worst day of your life so far. Redo, how about you introduce yourself to the people?

Hey. I'm Redo Wang. I'm currently, working at Vault, which is kind of like a European sister concern of DoorDash in The US. So yeah, I've been doing open source for a long time and working here for around like two years. And I primarily work with Go.

I assume that actually most podcasts only have one episode and then they quit, you know what mean? Yes. So on on the statistics, two years is pretty is probably pretty good.

Yep. Yep.

I have to admit that I was, like, one of the top, users of, Walt. So I'm happy to see, like, someone behind the scenes because it's pretty popular in Israel. And it also has, a deal. It had a deal with my workplace. So I would, like, get free lunch from Walt every day. Not free, but you know what I mean? Like included.

Oh. Oh. Yeah. Yeah. Yeah. Israel is one of the bigger market of, like, Walt's. So yep.

Yeah. Love to order food. You see them. But usually, the effect you see it's funny to talk about the back end because, I dunno if people who have, like, DoorDash or Walt or all these sorts of companies in their cities know. The main effect is very visible that you have, like, guys on bikes crossing red lights and, like, cutting you off trying to get a little fast. So now we'll see which laws are being broken on the back end to get my food to me in, thirty minutes or less.

Yep.

So the way we got to, talk in is your blog post about, dependency injection frameworks, which were you mentioned, like, at the top of the episode. For listeners who, like, missed that episode or just, I think, in general, a refresher would be helpful. What is that blog post about?

Okay. Yeah. So I kind of, like, recently wrote a blog post, regarding how in Go you actually probably don't need a dependency injection framework and it actually got a lot of traction mostly because Go is a little different from many other languages and what happens is like people coming to go from other languages, they often bring their practices and their habits and behaviors, which is good, which is all good. But at the same time, some of them actually don't fit very well. And DI is one of my pet peeves.

So what is it about Go that makes it different that a DI framework might be appropriate in, I don't know, some other language, but it's not in Go? What's the difference?

Yeah, so one of the first, like the simple the simplest thing I would like answer is Go has a lot of first class properties. Like you can actually pass around functions, which you cannot do in many other languages, which makes your life pretty easy. Like if you need to initialize something, just pass a function and call that function inside another function and it's fine. And in languages where you need to create an object and call like a methodology, you might need some sort of like wearing things where you have these like heavy objects that you need to initialize somewhere and then you need to call some method on that in order for the whole thing to work. But in Go, in most cases, you could just like pass it, like pass the whole thing, create your struct like in Go we have this convention where we usually create like a construction function, which is like a new and then you return the object that you want to create.

The places where I've seen people bring in the iframeworks are like developers that don't know really enough about programming. They don't have, like, tens of years of experience behind them to have seen the whole thing. They know just enough to be dangerous, like four years experience area. Yeah. So they'll be like, oh, someone taught me I got a code review once that you should functions shouldn't have too many parameters and it was linked to clean code.

Yeah. Yeah.

But in or the other way around where they're like, okay, I won't use a framework because I think it really over complicates things because I got a code, code review comment once that, like, you know, don't bring in dependencies unless they're absolutely necessary. Right? But then they don't separate their like all the constructors and all the bootstrap of the application and all the startup into one like file and one function that's called Bootstrap that has all these things. And then, you know, suddenly for some reason, your configuration is being initialized with three parameters inside your logger and all these sorts of weird things instead of initializing them all in order and passing them in a fun like in a big graph creation sort of function that doesn't have any business logic. It's just wiring up all the things.

Yeah. I I wouldn't say, like, Python is probably, like, the right language to, like, pick on this because, like, in Python also, you prob you most likely, like, don't need a d I framework. In most cases, you could, like, get away with it because there is also, these first class functions and whatnot. All of this thing you actually don't need. But what happens is like there are languages like, for example, in Java, there is a very common, it's just a custom and not only custom and there are very valid reasons behind why they oftentimes use like dependency injection frameworks.

One thing that's interesting is that I can't fathom why you would need like a thousand or 4,000 microservices for like a cab renting application.

Okay. Okay. They they have their reasons. They have their reasons.

I'm sure I'm sure they do. But at this point, it might also be like, this is how we do thing. Like, if it works for them, great. I don't know what's Uber, financials look like. But and I'm happy for for it because it's cool tech. Like, it's definitely cool. I'm just like, okay. Yeah. And you know what? I'm I use it. It works. So I would know if if it didn't work as well, then I would be pissed, but I use the app and the app works, so no no complaints.

Yeah. It's basically a solution to a social problem, not like a technical problem, like microservices. Like when you have, like, 5,000 engineers working on something, you want them to be empowered. So in Uber, at least what I have heard from some of my co workers who have worked there previously is like, you can just go, you can just basically go ahead and like start a new service and start working and they have their deployment pipeline and it's very empowered. But at the same time, you know, like when everyone can create all of these services and like deploy that, sure, you will have like all of huge amount of like services.

Well, thanks for the primer on DI and how it interacts with Go. Let's step back a little bit. Tell us a little bit more about what else you do. I'm sure that DI isn't the only thing you concern yourself with. What interesting problems have you been solving lately? What do you work on these days?

Okay, yeah. So I primarily work as a backend engineer and I work with distributor systems. And that's a very like an umbrella term. If I drill down, currently I'm working at in the database team where we are building like a service in front of that is going to be backed by Cassandra. And that's going to solve some of the scalability, database scalability problems that we have had inside because WALT and DoorDash both are like growing at an incredibly faster rate.

I've seen in your blog, I'll put a link in the show notes to the entire blog, not just the DI thing. Like, it seems over time, recently you've done a lot of Go, and then you scroll a little back, you did a little bit of Python. Is that why you're so happy right now? Like, is that why you're smiling?

Yeah. Yeah. Yeah. Yeah. Yeah.

It's cool that, like, people are excited about it.

Yeah. Yeah.

It you know, it would be it's pretty rare. Like, engineers tend to be, excited about new Well,

not everyone. Yes. Obviously. Like, not everyone. Like, some people like, hey. You can't take away my decorators. Like, Go doesn't have a decorator. Hey, just call a function from another function. It's like, no, but that's not as nice as, something like a decorator, I would say. Yeah.

Sounds like time for another blog post to educate those fools, I guess.

Yeah. And, well, it also like depends on your experiences. Like I have written quite a bit of Python over the last, I would say, seven, eight years and even before that I have written like TypeScript and the whole point of me coming over to Go because I like back end, I like distributed systems and whatnot, and writing those languages has their downsides if you want to work at that. Like where I want to work, right, if I want to keep writing like Python, it has its downsides. And yeah, Go is not perfect, but well, it's a tiny language, it's statically linked, it has a lot of good stuff.

And I'll just, say, you know, I'll I'll do this shout out instead of you, but I went to the careers.world page Mhmm. And seems like there are Go roles open. So if you're saying there's a lot of excitement around Go and people are looking, if you're in Helsinki or Stockholm or Estonia or Finland, all these, countries that always show up on the happiness index, you know what I mean, then it seems like there are some Go, roles. Do they make you, like, do one day on the bike or something just to learn how the couriers work or did did they not force you to do it? I heard a rumor that everybody who works there has to do, like, one day of shipping food for real customers.

Well, that's an option. Like, it's it's not, like, mandatory. You don't have to do it if you don't want to, but, yeah, it's a fun option, like, many actually, like, choose to do. So

yeah. Jonathan, do you think you'll be good as a food courier? Like a bike ridden food I used

to deliver newspapers on a bicycle, so I suppose that a lot of those skills would transfer over.

Oh my god. You legitimately used to do, like, newspaper delivery.

Yeah. Yeah, I did.

If we have listeners, like, born after 2,000 newspapers, were these things made of paper?

No, I'm

just kidding.

Oh, wow.

I'm just kidding, but not really. Well, awesome, man. Just before we wrap up here, if people wanna find you, where did they do it?

Yeah, I had a Twitter account, but I kind of like deactivated the whole thing, but I am also, I'm blue sky, which is which is the only one that I'm just like trying it out and my handle is red nahi, my all of my handle is everywhere is the same, like my github handle and my blog, everything has like the same handle. So yeah. And also, like, I'm on LinkedIn, I guess, like every you have to be on LinkedIn.

Mhmm. You have to play the Yeah.

Yeah. To play the game. Exactly. Exactly.

Yeah. Although we are, like, playing checkers while Jonathan is playing LinkedIn chess. He's, like, trolling everybody on LinkedIn.

Oh, wow. 40 chess.

Of course, all the links, for Redwon's blog, and the about page and everything are in the show notes, you can find them. Jonathan, how about you? Red pops up with the stumper question. I don't know why we call it the stumper question. It's not a stumper

question anymore. Not a stumper question. I guess we're stumped as to why it's called that. So when you were learning Go, we didn't really talk about your history with that, but I don't know how recently you started learning Go, but who influenced you the most?

Okay. Yeah. I would say in my case, I follow the development of Tailscale very closely, so all of the people there like Brad Fitzpatrick and also Debbie Troshaw and I would say like they have a lot of influence on my thought, how I work and what I do. So yeah, I would give like a huge shout out to like the Tailscale folks, like they do incredible work with Go and you can learn some world class engineering from their open source like the whole Tailscale thing you want like GitHub and everything, just following the issues and stuff. So yeah, I have learned over the years a lot just reading the code and like browsing stuff and also like the blockquotes that David Kroshaw, like recently he posted one blog post about like how he uses agents like LLM agents in order to develop with Go and why Go is like a great language in order if you want to like develop with this large language model tools.

Awesome. That's awesome. Great

shout out to Tailscale as well. Yep. A lot of Go companies being, highlighted. What's the name of the blog post? I wanna put it in the, in the show notes.

How I use agents, it's by David Kroshaw.

Oh, I I'll I'll find it. That that's enough. Yeah. I'll send my agent to find it.

Yeah. Yeah. Yeah. You you can find it

because with agents.

Yes. Yes. Yes.

Oh, I see I see where you take your, blog's, style from. The light mode, black text, no, styling thing. I feel like whenever I see a blog like this, I feel stupid for, like, investing in the CSS of my side and, like, making it nice and whatever. Okay. Everything looks so much more professional when it's just like HTML, no no

In my case, it's like my front end skill is shit. It's not very good. So I I never invested much time there. So I just, like, picked up, a default Hugo team and just, like, rolled with it. It does the work. It does the job. So yeah.

Maybe it's it's the signal you want to convey. Like, don't hire me for my front end skills. Yeah.

Yeah. Yeah. Most likely. Yeah. Yeah. For for sure. For sure.

Well, I'll put the show the link in the show notes as well. I actually haven't read it, so I'll definitely read it. That's a good, that's a good shout out. Thanks everyone for joining, Cupago this time. I have one, like, final question, and that one this one is a stopper question, actually. You've been a long time listener of the show. Who's better host?

Oh shit, like that's a hard word, but I would say like I can immediately identify Jonathan's poise from a mile.

Okay.

Take it, what are you?

So if I see someone running, it might be you.

Yes, yeah, yeah.

I'm gonna cry in the corner then. Thanks for coming. Thanks for coming on the show.

Thank you. And you for all

the show for so long.

Yeah. Thanks a lot.

Do it for, this week, folks. Check us out next week as well. I know the schedule's been kind of spotty recently. And actually next week it will probably be as well. I'll talk to Jonathan about it after the show, and we'll see how we'll figure it out. But we really appreciate you all listening. That's it. Program exited.

Program exited. Goodbye.