Cup o' Go


★ Support this podcast on Patreon ★

Creators & Guests

Host
Jonathan Hall
Freelance Gopher, Continuous Delivery consultant, and host of the Boldly Go YouTube channel.
Host
Shay Nehmad
Engineering Enablement Architect @ Orca
Editor
Filippo Valvassori Bolgè
Sound Designer / Audio Editor based in Milan

What is Cup o' Go?

Stay up to date with the Go community in about 15 minutes per week

Speaker 1:

This show is sponsored by you. Stick around till after the news to hear more about that and how you could become a member. This is Cup of Go for February 9, 2024. Keep up to date with the happenings in the Go community in about 15 minutes per week. I'm Jonathan Hall.

Speaker 2:

And I'm Shayne Ahmad. Welcome to our Go 122 episode. Yay. Tada.

Speaker 1:

I'm a little bit sad. I was really hoping for a Valentine's Day release this year, but it just wasn't in the cards.

Speaker 2:

Well, I guess that, we can worry about upgrading and everything crashing and reporting all the bugs this week and then have, Valentine's Day free for, like, a date or something.

Speaker 1:

I suppose that's a good idea for those of us who are lucky enough to have a date.

Speaker 2:

So, today we're gonna have a bit of a different show. We're gonna really focus on 122, share with you the six things that we think are the most important in this release, which are loop var. Range over int. The new math random package. HTTP routing.

Speaker 2:

Slices.

Speaker 1:

Trace UI.

Speaker 2:

And I think we're gonna do it actually the other way around. Like, you're gonna take loop far, and I'm gonna take loop far. Alright? But how cheesy was that? Like, each one saying one title.

Speaker 1:

At least we aren't finishing each other's sentences yet.

Speaker 2:

Yeah. Sandwiches. What? Anyway, so we really wanna give you, like, the 122 rundown. There are a few small, news items before that.

Speaker 2:

We can't forget about 121. It's still in the cards both figuratively and literally because it's in our cards of the show. So 121.7 and 120.14 got released. What did these releases include?

Speaker 1:

I didn't actually check because 122 came out before I had a chance to care, which got me thinking. So, you know, the way the Go team supports releases is they support the last two major releases. Right? So once 122 comes out, 120 is deprecated, no longer supported, which got me thinking 120.14 was released a few hours before 122. I wondered if that might make it the Go release with the shortest support window.

Speaker 1:

Like, it was technically supported for a few hours. If you found a bug quick enough, it would technically be supported to to report it. So I went looking, and no. It wasn't the shortest one.

Speaker 2:

What was the shortest one?

Speaker 1:

Actually, Go 1.19 had a minor release after the support window had closed.

Speaker 2:

So it's minus, support?

Speaker 1:

It's like minus a week. Yeah.

Speaker 2:

That's how seriously go team takes their support.

Speaker 1:

That's right. So, when I jump over to the issue tracker to see what actually is included in these two releases, there's nothing that's really worth calling out. It's a bunch of little esoteric compiler optimizations and bug fixes and things like that. Nothing in particular that's likely to affect you. So I mean, if you're not updating to 122 for some reason, update to these.

Speaker 1:

But otherwise, why not use 122?

Speaker 2:

So at least from the discourse in our channel, seems like there is a reason not upgrade to 122 yet. Because. There are crashes. It's not super stable yet. It's just a brand new release.

Speaker 2:

So, you know, I wouldn't put the most important production stacks on it yet. I give it a a couple of weeks. Yep. Another small release we wanna shout out is a Golangsi Island. So, Golang CI Lint had 2 releases, 1.56.0 and then, like, another patch after that.

Speaker 2:

56 is a really, really big release. A, it bumps almost all of the underlying linters, which make sense as they include support for 122 and iron out all of their bugs. So it's a huge list of bumps, but there are also some other features other than go 1 22 support options for, s log lint, options for white space, and one that I really like, implementing stats per linter. So now you have a minus minus show stats flag that can help you, like, see which linter is, giving you the most errors or maybe, you know, enable all and see which one is, the worst to fix. Mhmm.

Speaker 2:

I guess it's a useful feature. I would just hack it with some bash commands, but it's nice to have it as a built in option. I use, rough for Python at work today and having the stats feature is really helpful in communicating. Look how many problems we have in our code base. Oh my god.

Speaker 2:

Without actually sending the entire list which could be really really really really long. So yeah, Golang silent has another upgrade. Like always, when upgrading Golang silent, you pick your versions of the underlying linters which sometimes can be problematic. So do that upgrade carefully. Not as carefully as the Go runtime, but still carefully.

Speaker 1:

So actually, one of the fixes in the patch was what bug I reported.

Speaker 2:

Oh, really? Yeah. Which one?

Speaker 1:

I saw the release. I was like, awesome. I'm gonna go do it. So I upgraded to 122 and I upgraded to the Golan CLINT. Because I wanted the new version of Golang CLint, so I could use the range int function without my linter complaining and stuff like that.

Speaker 1:

There was actually a bug in an upstream linter that affected my configuration, but they they were nice enough to fix it pretty quickly. So I'll probably be doing finishing the upgrade today.

Speaker 2:

Nice. Revive? Mhmm. Yeah. I saw that.

Speaker 2:

I saw that, report. The revive config was broken. So it's not a bug in the linter. It's just a bug in the config. Right?

Speaker 1:

It was a bug in the way the the revive linter handled config.

Speaker 2:

One last, news item before we dive into 1 22. My company, Orca Security, is hosting the next Gopher meetup, in Tel Aviv. So if you're in Israel and you wanna join the Gopher Israel, meetings, we're finally restarting them after a pretty long, time off. It's gonna be in our offices to Shia, 3 in Tel Aviv, hosted by Orca Security. Thanks, Orca.

Speaker 2:

I don't know. It's it feels kinda weird because it's my company, but whatever. Mhmm. March 12th at 6 PM.

Speaker 1:

Very cool.

Speaker 2:

Yeah. Yeah. And there's still one TBD talk, so, you know, maybe you wanna hand in your talk. We would love to have you.

Speaker 1:

So let's talk about these 1 22 release notes that we've been hinting at for weeks. First up, we have the loop var. It's no longer an experiment. We've talked about this ad nauseam on the show over the last year. It was included in 121 as an experiment.

Speaker 1:

I've been running that experiment in production, never had a problem. It's now official. It's the official behavior. To recap, if you haven't listened to one of our past episodes or just forgot, when you do a for loop in Go, previously it would reuse the same variable for each iteration of that for loop. So if you had for I equals 1, I plus plus whatever whatever, it would just increment that same variable with the new value each time through the loop.

Speaker 1:

Which is fine in many cases, but it doesn't work if you try to reference a pointer to that or pass it to a goroutine or something like that that uses that same variable as the next iteration begins. So now the new version in the 1 22, the new version of loops creates a new variable instance for every iteration. So that's never a problem.

Speaker 2:

I think it's just removing super big foot gun from the language, polishing it, making it better. It's good that we're staying angry and we're not just accepting, oh, this is a quirk. This is how it's gonna stay forever. This was also done very, very, very, very carefully. Right?

Speaker 2:

How long did this change take?

Speaker 1:

Yeah. They've been talking about this in implementing prerequisite features for at least for well over a year. By prerequisite features, let me also mention the thing I was gonna say, that this doesn't affect code that is tagged to work with go 121 or older. So if your go dot mod says go 118 or or a dependency of that you're using has a Go mod, it requires 118, that was that module alone will still use the old behavior or 121 or any any version prior to 122. Or if you have a a specific file that is tagged with a Go build tag to require 121 or older, that will still use the old behavior.

Speaker 1:

So the ability to have a language feature like this, how for loops work, is pretty fundamental. Very potentially file by file. That's a feature that didn't exist in Go a year ago. So that's one of the prerequisite features they had to to build into the language is the ability to enable something like this, something so fundamental.

Speaker 2:

It's amazing to see how much work needs to go into maintainability. Like, just the ability to maintain this language now that it's so, you know, all over the place is really an engineering challenge of its own. Not just even not just a technical one. They the way they rolled it out, the communication, everything. I think it it's a great case study.

Speaker 2:

If you're, you know, a new startup and you're opening your new open source thing, build it in a way that in 5 years, if it succeeds, it looks like what Go is doing right now. Learn from their lessons. Cool. So next feature, range over int. Another really fundamental if you're talking about 4 so you can 4 is a very loaded.

Speaker 2:

I wouldn't say overloaded although some people think that, but it's a loaded term in Go and you can do a for statement with a range clause. Right? And range over an array. Makes sense? A slice, a string, or a map, or values on a channel, and new in 122 integer values from 0 to an upper limit.

Speaker 2:

So this is a really nice, syntactic, sugar where you can just say, 4 I walrus, range of 10. And this goes from like 0 to 9. Right? You have to do it a lot, you know, you want to grab the top five things off a list and show them. You want to iterate for a known amount of times because you wanna retry.

Speaker 2:

This is something that happens a lot and it's nice to have this, simple syntax to do it in and I don't think it's, like, ambiguous. It's super easy to understand for IRange 10. The only thing I'll always worry about is whether it's inclusive or not inclusive. It's not inclusive. So this is a very simple feature.

Speaker 2:

It hides the fact that there's also a preview of a language change they're considering which is range over function iterators. You need an experiment to turn that on. We're not gonna go over it. This episode, we actually talked about it a bunch of times already. It's 10 times more complicated and it's building on the same blocks of let's add another thing you can, range over.

Speaker 2:

But you can range over integers now, another improvement to the for syntax. On the topic of numbers Yes.

Speaker 1:

You can combine this feature with the last one if you really want to. We have a new mathrand package, mathrandv2 with a sub thread interface, an API that's less confusing and more important, improve performance. So if you use MathRand for some reason, you can do it faster now. You can create pseudo random numbers faster, but we couldn't back port the new performance improvements to the old library because it changes the it changes the fundamental algorithm used to generate random numbers, which would change the sequence of random numbers created. Why does that matter, you might think?

Speaker 1:

It's random. Right? Well, it's pseudo random. You know, you you could seed your r n g, your random number generator, so that all of your tests produce the same deterministic pseudo random output so that you get the the right thing. Right?

Speaker 1:

That's a really useful thing to do. But if they change the underlying algorithm and it produces different random pseudo random output, it's still deterministic but it's not the same deterministic. So, you know, they would probably have broken almost every test in the world that depends on MathRand if they had done this and probably some production code too. So that's why it couldn't even though the API might not necessarily change, the the output changes and that is considered part of the API. That's a big reason.

Speaker 1:

This is a new a new library. And then since they had to do a new library for that reason, it's a great opportunity to just sort of clean up the API, give it, you know, better function names.

Speaker 2:

Yeah. Refactor the whole thing. And, it's also a stepping stone for doing v2 for other packages, sync, encoding JSON that might get a v2 in the future. So there's a lot of, you know, new features in the well, I guess not new, but new looking features. The way that read looks, the dotn function is now generic.

Speaker 2:

It can be an int or a u int, which is very nice because you don't have to think about it. You just decide if you want your random number to be like any number. What's fun about this, at least for me, is I'm reading the release notes and I'm also using, a link for interactive release notes with someone, put up, you know, with, executable options in the web UI. Mhmm. And when you run it, it's always the same number.

Speaker 2:

I'm like, oh, no. Rand v 2 doesn't work. It always returns the same number. Of course, that's wrong. Right?

Speaker 2:

Because it's seeded. So it should return the same thing. So it it actually does work. Don't worry about it. I guess someone tested it once or twice.

Speaker 2:

Yeah.

Speaker 1:

Awesome.

Speaker 2:

If I have a code that's using MathRand right now, should I worry about upgrading to v 2?

Speaker 1:

I think it depends mainly on whether you want better performance.

Speaker 2:

So if it's not critical for me, I'm fine to stay with the normal MathRand?

Speaker 1:

You're fine to stay. What I would be more concerned about is should you be using MathRand at all, or should you be using cryptorand? You know, if if you're doing something that that's exposed, you know, you're trying to generate random UIDs or something like that, and you to be secure for some reason, you probably want cryptorand for that.

Speaker 2:

Yeah. So two things to remember there. Make sure you use the correct, random, function. And also turn on linters for that. Right?

Speaker 2:

Almost every security linter in Go when they see MathRand, they freak out. Yep. Exactly. Double check your no QA. Like someone added a no lint.

Speaker 2:

Right? Yeah. Double check that they they actually meant it. Alright. Next feature, one of my favorites of this release, even though, you know, talking about the way it's implemented with white space not with white space we can, get into it because, unfortunately, my opinion is not carrying through.

Speaker 2:

Anyway, it should be routing. So it go as always prided itself on being very strong with the standard library. Right? The normal dark souls ish response of just git gud in the forums is like, oh, you don't need a library to implement anything. Just use the standard library and you can do everything.

Speaker 2:

Why would you need frameworks? Why do the Go is great? And this opinion just got more valid, with the new routing patterns that the standard library offers because they are way way more expressive. You accept, methods now. So you can get, get, post, delete, patch, or the rest of the HTTP verbs in the path or like in the pattern that you give to the handler functions and you can also get wildcards which is I think really the big feature.

Speaker 2:

So you can have a path that looks let's say you have a user, endpoint. Right? So you have slash user slash ID. You wanna get an, an identifier. Now instead of, like, splitting the path based on, forward slash and, like, parsing all that out yourself with all the problems, you can use request dot path value.

Speaker 2:

You know how each handler gets a request object, Http request. Now it has a function called path value. It gets the wild card name and just gives you the value back. So super super simple to use in my opinion and solves a lot of problems And you can even do like in this wild card and you get all the real remaining segments. You have exact mass gestures so no more, wait, should I put a backslash?

Speaker 2:

Shouldn't I put a backslash? You have prefix match and exact match if you want them with, a dollar in the wild card. So they solved a lot of problems in HTTP routing. It for example, you know, you want 2 routes and you wanna solve the conflicts between them, you had to have a single route and do it in code before. Now you can do it in instead of doing if get, no, if post.

Speaker 2:

Now you just put it in the handler. It's a lot better. It really removes a lot of the need for web frameworks. If you do super specialized stuff like WebSockets and and or you have a ton of code with your already existing framework including helpers and whatever and you don't wanna rewrite it, I don't think you'd need to rewrite but anything greenfield I would recommend try to do everything with the standard library and don't use a framework. Yep.

Speaker 2:

And one thing that, I really hope will happen soon is that LLMs will catch up on that as well. Because right now if you start writing a web server in Go, Copilot will immediately pull up, like, gin or or some framework. And I think that's not great because people might default to that. This does break compatibility. For example, patterns that used to have the wild card, like, parens, curly braces, won't work.

Speaker 2:

So But

Speaker 1:

that should be very rare. I mean, obviously, that was the reasoning anyway that they allowed to break that is it should be very rare to have a URL with that in it legitimately.

Speaker 2:

Yeah. Yeah. But if you upgrade and you have an HP server, and you use the standard library, make sure that you double check that it still works. You should probably run all of your tests when upgrading anyway. So I think this is a really big step forward for the language.

Speaker 2:

Again, removing the need for a lot of libraries and and using a lot of lessons learned, and making a lot of, a lot more batteries included. You install Go, you can just spin up a really advanced web server now, which I think hits for the, majority customer segment of this language. You know what I mean? It doesn't really impact the, desktop developer people, but for most people working in this language, it's pretty relevant.

Speaker 1:

So I do wanna call out one proposal, the one that we talked about 2 weeks ago that you didn't like. It it has been accepted.

Speaker 2:

Accepted or It

Speaker 1:

was accepted. Yes.

Speaker 2:

No. I

Speaker 1:

Just 8 hours ago. So

Speaker 2:

Oh my god. Last I checked it was, considered to be accepted.

Speaker 1:

Yeah. It's been officially accepted. So, sorry, Shai. May maybe you'll go back to using a a framework after this.

Speaker 2:

Michal Behoslavac or Slavec just posted 24 minutes ago. This is news breaking news. Beep beep beep beep beep beep. Based on the emoji votes, of my comment, is there really a consensus? Because I put in some, like, really good reasoning why this is a bad idea.

Speaker 2:

The main thing being when you change one endpoint, the diff for that pull request is gonna include 2 endpoints and it's gonna make it very confusing and you're gonna have to, like, review without reviewing white space or if you want them to be lined up, like, review white space. So I I hope they'll reverse it. This is not a good position. I don't know why I'm so like, this is not important, but just because I took the time to think about it. Uh-huh.

Speaker 2:

It it's become, my watershed moment with Go. I'm surprised.

Speaker 1:

I mean, the original post has 5 upvotes and 18 downvotes. That that's not consensus to me. So whatever consensus is being discussed didn't happen in in this issue tracker. So, yeah, I'm I'm curious how that'll be responded to.

Speaker 2:

Well, the most important thing is that this is not so important. Like, if it worked one way or another, I wouldn't Yeah.

Speaker 1:

If this was generics, I think I think we would care a lot more. Right?

Speaker 2:

Yeah. Yeah. For sure. So it got accepted, but I'm gonna abuse my power here and tell all the listeners, get in the comments. Go outvote my thing.

Speaker 1:

I think we'll be talking about this issue in the future again. So stick around for for some fresh on that.

Speaker 2:

So we have 2 extra features we wanna talk about in Go 122. Before we dive into those, there's a lot more. There's a huge change list of more minor things, so I definitely recommend you go check out the interactive release notes and all of the release notes. This is a really big change in the language.

Speaker 1:

Yeah. And I'm sure we'll talk about other things, as as the weeks go by in future episodes, especially as blog posts come up to talk about it. But the last 2 we wanna talk about today, one of them is slices. The slices package in particular has a few new interesting functions. Concat is, what allows you to basically do a more efficient version of append for multiple slices.

Speaker 1:

You know, if you have 6 different slices that all contain things you want to put them together, you could call append 5 times or whatever Or you could use slices dotcomcat and get a more memory efficient version of that.

Speaker 2:

Why is it more memory efficient than calling a pen 5 times?

Speaker 1:

That's a great question. I wish we had a blog post that would tell us about that. Oh, wait. We do.

Speaker 2:

Nice.

Speaker 1:

So Carlonna Johnson wrote a blog post, and she also was the one who implemented this new feature about, implementing it and and how she made the choices she did and what she tried in the process, you know, to to settle on this design decision. But basically it it uses fewer allocations. If I recall, if you use append, you're gonna, in general, get up to 1 allocation per append call. With slices concat, you get one allocation. That's the t that's the that's the short oversimplified version of what happens.

Speaker 1:

Nice.

Speaker 2:

It's also a a nice use of generics. Like, when I look at these functions and, you know, what they give us and their signatures, I'm like, oh, this was what we needed generics for. Like, all the bike shedding about, oh, would I need to use it in my code base? Like, yeah, for concat cause you wanna concat slices and you don't want 500,000 different implementations. So it's nice to see it in its element.

Speaker 2:

You know what I mean? There are other changes to the slices package as well, not just concat. Right?

Speaker 1:

Yeah. There's a few others. So functions that shrink the size of the slice, like delete, compact, they now zero the elements after the last element. So in the past, if you had a slice that said, we're 1023, and you called compact on it, you'd end up with 1233. But that's that second 3 would be after the length, of the slice.

Speaker 1:

So you wouldn't normally see it unless you started doing funky slice things. Now that is zeroed, so your slice would be 1230, and that 0 would be at after the end of the slice. If you don't know what I'm talking about, it doesn't matter to you, so just forget that.

Speaker 2:

Yeah. But, I think that the, issue is really, really well written. If if this does sound interesting, Dela Plus, Valentin De Laplace, from Paris, wrote the proposal and it's super well written. It has, like, you know, all the examples, the headers. It reads like an article, really.

Speaker 2:

So it's really well written. Go read that. It's a it's a good lesson in technical writing, I think. Straight to the point and really explains it. There's also the, replace option which I, liked a lot.

Speaker 2:

Instead of just deleting, like, 0ing, you can replace all the items you want in your slice with a specific thing. And insert now always panic when you try to insert with something that's out of range, which is really, really good. It's better to to fail when you try to insert to a place that doesn't exist instead of failing silent.

Speaker 1:

So the the previous failure mode was actually a strange one. It would it would not panic if there were no elements to be inserted. So if you tried to insert nothing, which I suppose could happen in some cases, but that was into an out of range place in the slice, it would it wouldn't panic. Now it will panic even though you're trying to do nothing. So it's a little more consistent.

Speaker 2:

For sure. The last feature we wanna mention is just something that I've been working a lot with, lately, which is, like, tracing and profiling and all these tools. I've spun up, I don't know, about 7 of them in the last 2 weeks because we're, evaluating different profiling and tracing tools for at work. It's nice to see in 122, they revamped the web UI of the Trace tool. This is probably the worst thing to try to explain in podcast form because it's a refresh of the web interface of how it looks.

Speaker 2:

So no way to explain it, really. The only thing that can I I can explain is that, you now support looking at traces in a thread oriented view? So if you have a really multi threaded application and you don't wanna look at the entire trace, you wanna look at a specific thread, maybe it's the interesting one where you're hunting for the bug or for the performance bottleneck, you can do that. You can say, I wanna look at the thread most people's request would be in the middle, in the average. Most people's request would be in the middle in the average, right?

Speaker 2:

But for celebrities that have a ton of data and a ton of connections and a ton of whatever, ton of followers, their specific request would be slow. So you wanna trace that specific Go routine. So now you can do that. Also, it now show shows a full duration of all syscalls, which is interesting if you have a slower, syscall. We mentioned, how, meth rand is getting faster.

Speaker 2:

I once used the dev urandom system call so much that it was the performance bottleneck, and I couldn't see it until I added logs before and after because there wasn't any way to trace it. So now you can trace full duration of systems calls as well. Think if you have a production, like, setup with Go and you care about performance, you care about tracing, you wanna understand what's going on, this is a really, really good, announcement for you. Try it out and play around with it. You'll probably find a bug just by upgrading and playing around and actually looking at the numbers.

Speaker 2:

Right? Because how often do you look at the traces? So a really cool, you know, change to the web UI and it's very, encouraging to see them investing in debugging tools. And again, stuff that's about maintenance is not necessarily a ton of flashy new features. That does it for our, wrap up of 1 22.

Speaker 2:

Right? Yeah. Like we mentioned, there's a I'm not gonna say it. I was just about to say it. There is a large number of, of other changes, in the go command and in vet and almost every standard library got a new thing as well.

Speaker 2:

Obviously, go slash version because that makes sense. So you can go take a look at the other things. I think these are the highlights that will be relevant to most people. Like, when you talk over coffee with people at work and they're like, oh, we heard there's a new version. What's up with it?

Speaker 2:

It can be like, oh, so they fixed the loop bar. You can range over ints now, like in, Python, so that's nice. They really improved the math random thing. HTTP is amazing. And there's a new features in slices as well that are really great.

Speaker 2:

If you're into debugging, there's Trace UI, and you got it all,

Speaker 1:

off the cuff. So for most of you, enjoy these brand new shiny features. For some of you who are more conservative, enjoy the new features of 121 now, now that you're, one more major version up and you're willing to adopt 121. Yeah.

Speaker 2:

Maybe there's a cohort of listeners who should listen to the show just in, you know, 6 months. Like, people who buy games 1 year after release. They just discovered we were selling swag at their store. Yeah. Yeah.

Speaker 2:

Awesome. Alright. Thanks for listening. 122. Finally, we released from that, burden, and we can, go back to talking about normal Go news, which you can expect next week.

Speaker 2:

Stick around for the ad break to hear about some of our new members and some other cool stuff.

Speaker 1:

And the Fosdome update. Oh. Knock knock. Who's there? Interrupting cow.

Speaker 1:

Interrupting cow. Boo.

Speaker 2:

Yeah. John, you're a little bit older than me. Right?

Speaker 1:

I think so. Yeah. Few days

Speaker 2:

ago. I see you as a as a bother figure, really.

Speaker 1:

Oh, wow.

Speaker 2:

Alright. It's from Brooklyn, Mennonite. This show is supported by you. We opened a Patreon. People have been signing up.

Speaker 2:

It's been great. This is an expensive hobby. We pay in our editor, and we pay the people who manage the store, and we have some apps that we pay for, to set up the website and the recordings for our equipment, etcetera, etcetera. We love doing this, and it's really heartening to see the community, you know, helping us maintain this fun hobby. So thanks a lot for your support.

Speaker 2:

We have 3 new members today to shout out, Thomas Gall, Christian von Kitzel and Jamie Tenna, who's been a long term poster on the on the Slack as well. What's up, Jamie? Thanks for supporting the show. If you wanna join this beautiful community of people, you can reach us at cupago.dev. That is cupogo.dev.

Speaker 2:

And, basically, everything's there. I always after I say the URL, I mention all the other things like our Slack channel and our email address and our store and all the episodes. But basically everything's there. John did a really good job of setting up the site. So capago.dev and you can find everything there.

Speaker 2:

We're mostly available on our Slack community, but you can also email us, news at capago.dev. And this is a good chance to ask you to share the show. This is a good episode to bring new people into the show I think many people are interested in the new release. This is not very esoteric news. I guess this is very mainstream news.

Speaker 2:

So if you've been wondering when's a good time to send an episode in the company Slack channel or maybe you have a local Telegram or Whatsapp group or some programming discord, community or whatever. We would really appreciate you spreading the word out. We have big plans for 2024 for the show. Mostly trying to keep it alive as the biggest plan of all, but really cool interviews and and stuff like that. And it's been really fun to see the the community and the numbers growing.

Speaker 2:

It's fun. So sharing the show is the best way you, you can support us. And if you want to do the extra mile, you can also join our Patreon.

Speaker 1:

Speaking of the community and and spreading the word, I had a great time at Fosdum last weekend. I met a number of cup of gophers, talked to a couple folks who are gonna come on to do interviews, in the coming weeks, so stick around for those. And I got to meet Andy Williams, who was our, fill in co host and interviewee, on a past episode. We met for some beers before Fosdimm, and there was a little bit of a question, like, would we recognize each other? But I'll tell you what, he looked exactly like his picture, except he had legs.

Speaker 1:

So that was, that was a nice, a nice thing to meet him and and other cup of gophers there. And I handed out a bunch of cup of gophers stickers. I I did a presentation there, and I handed out the stickers. They went like hot cakes. Everybody loves Brewster.

Speaker 1:

I don't know if they'll be listening, but they at least like Brewster. So I guess that's something.

Speaker 2:

I have a few stickers, of things that I products that I didn't use or, just because it's friends.

Speaker 1:

Exactly. It's fine. If you are listening now because you learned about this show at Fosdim, hop onto the Slack and let us know. You know? Say hello from Fosdim or something.

Speaker 1:

We'd love to hear from you. That's cool. And know that that's how you found us.

Speaker 2:

Yeah. And if you're planning to come to the Gopher meetup and you're listening to the show right now, then same. I don't think I have stickers left, but I might I'll I'll try maybe I can I'll rip one out of my water bottle and I give it that one. Sure. Talking about the community, we had a poll on Slack about the episode length.

Speaker 2:

This has been a contentious topic, because we open the episodes with 15 minutes per week. This is like our slogan, and it almost never is 15 minutes, just because contrary to our expectations when starting to show, there's a lot of Go news.

Speaker 1:

We expect them to really be,

Speaker 2:

struggling to find things, but we're actually leaving things on the editing room floor every week. So we're gonna keep it flexed because that's what, y'all said. Some people really appreciated the short format, but most prevalent opinion was just take however long you need and try to keep it short. So that's what we're gonna do.

Speaker 1:

I think we'll change our tagline from 15 minutes to about 15 minutes just

Speaker 2:

to be a

Speaker 1:

little less dishonest. Yeah. But, anyway, thanks for participating in the poll and letting us know how you feel about it.

Speaker 2:

Yeah. Talk to you next week, everyone. Thanks for listening. Happy 122.

Speaker 1:

Yay. Cheers.