🧑🚀 For our 1st anniversary, we debate about (white)space in Muxers for a looooong time
This show is supported by you. Stick around for the Edberg to hear more. This is CapaGo for February 2, 2024. Happy anniversary. Keep up to date with the important happenings in the Go community in 15 minutes per week.
Speaker 1:I'm Shayne Ahmad. And I'm Jonathan Hall. It's been a year.
Speaker 2:It has. So, actually, I'm looking our first episode came out January 23.
Speaker 1:Yeah. But I didn't wanna celebrate the anniversary of the Ardent. I wanted to wait for you.
Speaker 2:Sure. Yeah. Yeah. So, it's been like a year and a week and a half. So yay.
Speaker 2:Thanks for supporting the show. Thanks for listening. When we started, I don't think either of us had any idea that we would be going this long. Glad that we are. It's a lot of fun.
Speaker 1:Yeah. I have a problem. You just said it's been and immediately, I've been like, it's been 1 week since you looked. Okay. So it's been 1 week since we talked about Go News.
Speaker 1:Let's talk about some Go News.
Speaker 2:Let's do it. So first off, a proposal that you talked about in my absence a couple weeks ago when Yarden was here. Thanks, Yarden, for stepping in for me. You talked about the proposal to add the dash JSON flag to the go build command. And you talked about all the reasons that could be useful.
Speaker 2:That's been accepted.
Speaker 1:So That's great.
Speaker 2:For all the JSON fans out there, get excited. Your JSON flag is coming to the go build command.
Speaker 1:I don't know if there are JSON fans as much as we have all become JSON sufferers in the same way. We're just like, this the
Speaker 2:best we can do. Anybody who's used YAML might be a JSON fan.
Speaker 1:Yeah. That's for sure. I don't know how long ago you wrote XSLT queries to deal with XML files, but that's someone who did that using c sharp, which we complained about before starting recording. Yeah. It's not good.
Speaker 1:And the JSON flag for Go build is good. More support for tooling is great. So now you can integrate it in your CI pipelines and sort of get these logs directly into your structured logging thing and everything should work fine. It had time for comments. Now it's accepted.
Speaker 1:And again, I think it's a good chance to jump in on implementation because that's a pretty fun feature. There's already a change in place. They need some more tests. They could use some more documentation. There's some low hanging fruits there if you wanna jump on the open source bandwagon.
Speaker 2:Awesome.
Speaker 1:Okay. So let's talk about, the client proposal.
Speaker 2:Yeah. We don't do a lot of that. So it's good to get a few of those in there.
Speaker 1:Actually, we have 2, in line. And the third one, which I really hope will become declined. So we we can talk about that. But what do you think should happen if I do append to nil?
Speaker 2:I think the universe should implode.
Speaker 1:So if you try to you can jump on the Go Playground and do that right now. Right? But if you try to append anything to nil, it must be a slice. Append gets a slice and an argument, and nil is not a slice. The proposal was allow appending of nil slice if you have more than a single argument.
Speaker 1:It's fun to look at the votes, the emojis, emoji reactions, which we'll get back to, funnily enough.
Speaker 2:It's fun
Speaker 1:to look at the emoji reactions on GitHub. It's a perfectly balanced, plus 8, minus 8, on the proposal. It the key points, there's there's more depth to the thread. If you can use a pen to anil to copy a slice, which is sort of weird syntax, and there's some generics there sprinkled in for good measure to make it even more confusing. But since we already have clone and Go is all about one way to do things, after a pretty long discussion and, you know, going through the code and whatever, they found that every single usage of it could be replaced with slices dot clone.
Speaker 1:So they wanna remove the complications from append and keep it, simple. So it's, again, a very pragmatic approach. Let's look at all the actual usages in in real code. And it's been a likely decline, and now it's declined. So if you need to copy a slice, don't go for anything confusing.
Speaker 1:Slices.clone is the way to go.
Speaker 2:I have been using the slices package a lot lately on the two code bases I'm working on and I I find that I I I'm no longer a generics hater. I still think it's easily overused but I at least like it in that package a lot. Oh. So I I think I know where your question's going. I find myself using slices dot contains a lot to replace a bunch of really verbose for loops.
Speaker 2:And I love the type checking that it gives you that, you don't have like there's there's some there are some libraries out there that do some of the same things with with reflection, but then you have to do type assertions back to your original type and so on. And if you get it wrong, you have a potential run time panic. So I love the type safety that you get with generics that lets you do things that otherwise required reflection. So that's where I like I like the use of generics.
Speaker 1:The thing I'm worried about is if you rewrite it without generics, would you need reflection? You know what I mean? If yes, then probably you want the generics option. But if
Speaker 2:not Yeah. It depends.
Speaker 1:You probably just overused it.
Speaker 2:In some cases, I rewrite the the code to use neither reflection nor generics, if that's possible.
Speaker 1:Well, easy for us. Slices package is not optional. It's part of the standard library. You use the go run time then you use it. Unless you plan to fork or go into a non non generic option, then you should learn how to use it.
Speaker 1:Because part of the standard library and probably any code base that you're gonna walk into is gonna have that pop up. We have another declined proposal we wanna talk about. This time about linters, which you love so much.
Speaker 2:Yeah. So this one's about GoVet. And the proposal was to make GoVet, which is the official, the only technically official, linter for go, make it warn if you try to call the recover outside of a deferred function. So a refresher or maybe if you're new to Go, this is a first time primer on the topic. But if you panic in Go, that causes your program to to just stop running.
Speaker 2:Right? Unless you also recover that panic. And to recover the panic, you have to do it in a deferred function. I won't go into details here, because you can learn about that in many other places. The point of the proposal is what if you call recover in a non deferred function?
Speaker 2:That's that's wrong. It's it's objectively wrong. It's not like it's useful in some rare cases. It's never useful. It never does anything if you do that.
Speaker 2:So the idea was let's make GoVet complain if you do that. This proposal has been declined. Can you imagine why?
Speaker 1:Maybe it's hard to implement or there are cases that in which is useful and your assertion that it's never useful is,
Speaker 2:is fallacious. Yeah. So now you're very close. It's it's hard to implement. It's actually hard to detect when it's wrong except at runtime.
Speaker 2:And by then it's too late for the limiter to do anything. And the reason is because you can have a function that doesn't have a defer but it calls recover, but that function itself could be deferred. Oh. And that's a pattern I use fairly commonly. You know, if I if I have a defer defer logic, recovery logic I need to do Yeah.
Speaker 1:You extract it to, to a function. Right?
Speaker 2:Exactly. And then I just called defer fufunc or whatever, 16 different places, and they all call the same thing. Wait. But
Speaker 1:if they're far from each other, they're still like, the defer statement still is written somewhere. Right?
Speaker 2:It's written somewhere. But so, yeah. This could back to then, you know, is is hard to detect. So So you'd have to do some pretty deep analysis to determine if every function that calls recover is only ever called from a deferred function or from a function that itself is deferred or so, you know, it could be several layers deep.
Speaker 1:What what I'm imagining though is that with pen and paper and enough time, I could do it. I'm wondering if there are cases that I'm not thinking about, like dynamic functions or conditional defers or something like that in which you Yeah. It's it's ambiguous. Like, you really couldn't tell until run time. For example, I imagine, like, a debug, You know, if a debug environment variable is true, then you don't defer closing the connection because you wanna keep it open, you know, for, like, debugging even if the process closes or blah blah blah, something like that.
Speaker 1:You don't wanna kill the DB. Yeah. So you wouldn't be able to tell. Right? It's if defer, else don't defer.
Speaker 2:Or
Speaker 1:and it's gonna be hard to track.
Speaker 2:But I think the only two cases I can think of where it would be impossible to check are if you're building a library that exposes a function that's meant to be deferred. I don't know why you would do that, maybe if you're building some middleware for recovery or something, but it would be pretty rare. And the other would be, like you said, some sort of dynamic reflection based stuff, which is also rare. Which leads to the other point that they made in the comment thread, which is that there it's not actually any evidence that this is a a large problem.
Speaker 1:Yeah. Like, recover is not a thing I I write ever basically in Go code. So I would probably forget to do it. Like, there's no changes to me forgetting to call, recover in a deferred thing instead of, the other way around.
Speaker 2:Mhmm. And that and that led to some to my learning for the for the week. The the one new thing I learned about Go this week is that GoVet has a strict definition of the frequency requirement to be for a a rule to be GoVet. And there's a link to it from the the issue, tracker but basically it says vet is run every day by many programmers often as part of every compilation or submission. The cost of execution time is considerable, especially in aggregate, so checks must be likely enough to find real problems.
Speaker 2:They are worth the overhead of added check. And there's more to it, but that's, you know, that's the principle, and they they didn't have the evidence to support that. That's not saying it's not true. Maybe someone can find the evidence later. If you really think this is a problem, go find that evidence and reopen the issue or open a new issue and we could get it.
Speaker 1:I love that. There's recently LinkedIn posted a new developer productivity and happiness guidelines. They have a team similar to mine at Orca that does, like developer tooling, developer productivity, engineering enablement, blah, blah, blah, platform engineer, all these names of you know taking care of the tooling infra. And one of the metrics that they recommend teams like that to measure is dbt developer build time. How long do developers at your company wait for their build tools to happen and then to run, you know, and if you can cut 1 minute off a CI pipeline or one second of a CI pipeline by not including a check-in go vet, and, you know, you run that, let's say 10 times a day because you push to the CI 10 times a day or maybe GoVet is even pre commit for you.
Speaker 1:And you have a a 1000 developers that adds up really, really quickly. So I enjoy the fact that they want things to be fast in GoVAT. I'm not sure it justifies not including it in any linter. Like, I assume, you know, if you did put it in an option linter in Golangci lint or something like that, something you run every nightly, let's say, and not as part of Precommit or, you know, in CI, in offline, in a non blocking lagging indicator kind of way, that could be useful. Yeah.
Speaker 1:But if it's so hard to implement, then maybe it's not useful anyway. So we have a new proposal that I think you want it accepted and I want it declined. So sharpen your sword. Obligatory every episode, thing where we say we won't talk about 122 and we talk about something from 122. So you don't wanna talk about 122 things yet until it comes out hopefully next week.
Speaker 1:But this proposal is about, mux patterns, which is one of the biggest features in, 122. A quick refresher, the new, like, routes and handlers in the standard library, you don't have to get any, like, framework to do that. Include the HTTP verb. So you have get my route and get and post my route and delete my route, etcetera, etcetera. The proposal from, Evan Tan from Santa Monica wants spaces in between the verb and the URL.
Speaker 2:I think this is Arbitrary number of spaces.
Speaker 1:Yeah. The reasoning if you could really visualize it even though this is a podcast. Imagine the words get post and delete in all capital letters or like in new lines. Right? And then all the routes begin in the same they begin like at the 8th character because you want them all to line up nicely.
Speaker 1:So you have to have a lot of white space between the get and the URL and very little white space between delete and the URL. I hope you can visualize that in the in the podcast. If not, they they just want to have a lot of spaces between the verb and the URL. And I hate it. I can't explain why.
Speaker 1:I just wanted to have one space because I want one strict way to do things. But, you know, in the discussion here, there are some other opinions such as yourself, I think.
Speaker 2:Well, I don't have a strong opinion. I'm I'm not voting up or down this proposal. I I don't really care. The alignment argument is weak in my opinion. It's a kind of nice thing but it's not a great thing.
Speaker 2:But I I do like the discussion on it. I like that this is such a divisive proposal. That's the main reason I think it's interesting to talk about. So the the main argument that I see presented for multiple spaces is that's what the HTTP protocol itself allows. HTTP allows you to do get space space space space space slash space space space HTTP slash 1.1, for example.
Speaker 1:So there's a difference between the RFC, which says, you know, a request line has a method token, a single space, and the request target, and and then another space, and then the protocol between that and many implementations that actually do allow it.
Speaker 2:Well, yeah. Although the the spec apparently also allows new lines in that first line. So the way I understand that is you could have get new line slash new line HTTP or something like that, I guess.
Speaker 1:I think it's limited to one new line because 2 new lines is the content, right, in the HTTP. But I don't know. I don't like it just because of these questions and the value. Like, this introduces ambiguity questions, edge cases, and, you know, minimum is like, it introduces a place where you could argue about style. Like, I imagine this discussion popping up in code review where someone puts a lot of white space and like some other smart person is like no actually in hdp it's, one space.
Speaker 1:Look at the spec and they have all this discussion. We could just avoid it. And if you want your routes to line up, anyway, you should put the route thing in a separate variable because you want to reuse it. You want to reuse it in your client libraries. You want to reuse it in testing.
Speaker 1:There's no way you're actually gonna use it in a single string ever. Right? When the moment your program is more than a super simple HTTP server, you're gonna wanna extract the routes to separate variables so you could use them, for example, when testing your, HTTP server.
Speaker 2:So More constants. That would be even better.
Speaker 1:Yeah. Even in the example Evan gives, it's like get my route, post my route, delete my route. Let's put the spaces aside for a second. If these are actually supposed to be the same route, I would do, like, code review and I'd be like, please extract this to one constant because if you change one route, you'll forget to change the others. Yeah.
Speaker 1:And I I guess the most important part here is I want auto generated the code to be very consistent and allowing different spaces for like, this leaves ambiguity for the person who's gonna implement the open API generator for this, you know, go 122 max, server, which I don't want. I want that code to be super super super samey across, different pull requests because I want differences. I don't want lines that aren't related to the thing I'm auto generating to change because of something else. That makes code review and everything a lot harder. You know what I mean?
Speaker 1:I add a delete and suddenly I need to update my get line. So I'm very much against it. I am going to even post a comment against it, and I hope, it will get declined. But, Evan, we love you. It's nothing personal, Evan Tan, from, Thankful and Gladly and Santa Monica.
Speaker 1:We really appreciate your discussion and contribution to the Go world. Just not this one.
Speaker 2:You've almost convinced me but I'm gonna leave a comment in favor of it just to spite you. I'm kidding.
Speaker 1:Okay. I'm gonna be like, this is the official position of the Capa Girl show and all its listeners. We will fork the language if this gets exceptional. Alright. So, tabs versus, space, A new a new war in, programming, apparently.
Speaker 1:So that's it for proposals this week. There are 2 releases we wanna discuss as well.
Speaker 2:Yeah. Let's breeze let's breeze through these. We're running a little bit late. So the first one, one I'm excited about because as you mentioned earlier, I love linters. This isn't really a linter, but a formatter.
Speaker 2:Go fmt, g o f u m p t not g o f m t. Don't be confused. Gofumpt versus gofumpt. 0.6 was just released. Includes a couple bug fixes and, nothing really major, but I'm I'm always happy to see new releases.
Speaker 2:That means it's being actively maintained. And it means that my pull request against the project is that much closer to being accepted. I did it, some updates on it over the week. So hopefully, that'll be in the next version whenever that comes up.
Speaker 1:Good luck. I really hope your code will get into, GoFund because we use GoFund in my company. It could be like, oh, we run Jonathan's code. And people could be like, who's Jonathan? I'm like, oh, you haven't listened to Capagobe?
Speaker 1:Yeah. One more release you wanna go through. If you use Elasticsearch and Go, their new release from 2 weeks ago includes open telemetry integration, which if you use Go and Elasticsearch, you probably know what it means and you don't mean need me to say anything else. Also it now requires, Go version 1.20, which is not that big of an ask anyway. You should be prepping for 1 22 at the point, at this point in time.
Speaker 1:And if you don't use, Go and Elasticsearch production and you don't need open telemetry integration, then, yeah, you're just zoned out. And, hey, welcome back. We're gonna talk about some other stuff as well. I'm just happy to see the client for you know go getting first class citizenship for Elasticsearch integration because it's not that obvious. Elastic is not Go under the hood.
Speaker 1:They don't really have to do it but they're really maintaining it well. I've used it in production twice already And it's Go is usually not the language you would think of if you need to implement like a something that does data and big data. We talked about it with Miki a little bit. But just as a wrap around elastic search, it works really well. Right?
Speaker 1:You have h t p back end and elastic search as your data store. And if that fits well for you, you could just use Go and not even worry about it. Cool. And one, final community thing we want to mention, are you familiar with byte byte go?
Speaker 2:No. I'm not. Well, it's a lie. I wasn't until you mentioned it to me before we started recording. Yeah.
Speaker 1:So, they're not actually about Go. It's some sort of architect prep newsletter thing. When I was interviewing for architect roles, I signed up for the newsletter and I found some useful stuff in there. They produce really high quality content, and they just mentioned to go in one of their YouTube videos. So I thought it's a good place to shout them out.
Speaker 1:Also, another, content creator with Go in their name. So, of course, we have to support that. It's a video about how Hatajaar with I I think it's some Disney plus live sports thing sort of akin to Twitch. Alright. How they process all the emojis when you have, like, a sports game going on and many people are responding in real time and, like, sharing their emotions.
Speaker 1:So they have this whole pipeline where they, like, process the responses and put them on the screen and count them, in real time, and they sort of present the architecture. And they every part of the architecture uses the correct quote unquote correct, technology for that part of the stack. So you have Kafka for message processing, you have Python for data processing, and you wanna guess what Go goes for? Tell me. HTTP servers.
Speaker 1:Because that's the the what the language is for and you know they really really like the users really like putting emojis. I can imagine you're watching, like, a finals of the cricket match or something.
Speaker 2:And so you're putting a yawning emoji?
Speaker 1:Yeah. Yeah. Yeah.
Speaker 2:Sorry to the cricket fans out there. I just had to make a joke.
Speaker 1:I've like, I don't know. I follow NBA and I can really imagine how well, I used to follow NBA. I don't anymore. In Israel, it's really hard because it's 4 in the morning. It's actually the yawning emoji because because of the time difference.
Speaker 1:But they really reduced, the latency from 6 seconds on average to 2 seconds on average. The availability from, you know, they sometimes had outages to a 100% out uptime since they set up this system, which is impressive. And they cut costs by 85%. And, you know, the cost was like $1500 per match during World Cup. So that adds up.
Speaker 1:Yeah. So, yeah, go, profitable for emojis apparently. Awesome. I'll put the article as well. If you don't like video content, I totally get it.
Speaker 1:There's a medium article as well. So we'll put both links and you can choose whatever if you wanna follow-up on that, whichever format you prefer. Cool. That does it for this week. Thanks a lot for listening.
Speaker 2:This program is sponsored by listeners like you. Thanks to all of our Patreon supporters who are helping to make this feel possible and to not burn a huge toll in our personal pockets. This is an expensive hobby to maintain, so thanks to everybody who helps. We have a new Patreon member this week who will shout out in just a moment. If you're interested in becoming a Patreon member or talking to us or looking at our ridiculous faces or anything like that, head over to cupago.dev.
Speaker 2:You can find all the links to everything we're all funded by the show. Clicking all the show notes for all the articles and videos we mentioned in the in each episode.
Speaker 1:And all past episodes, a whole 1 year of them.
Speaker 2:Exactly. Yes. You can also chat to us in more real time if you want to over on the Cup of Go Slack channel, which is hosted by the Gopher Slack. There should be a link to that on our website as well if you wanna join that. We have a pretty active community and it's growing.
Speaker 2:We have people joining every week and, sharing articles and advice and talking about go related things and being silly sometimes. So come join us there. On the topic of our Slack channel, this week, we're going to be asking you, our listeners, what you think about the show format. In particular, we find that every week, we struggle to keep it under 15 minutes. In fact, almost never do we actually hit the 15 minute mark.
Speaker 2:So we're wondering, should we try? Should we try harder? Is 15 minutes important to you? Would longer be better? Would 20 minutes or 30 minutes or or 3 hours be better for you?
Speaker 1:3 hours could
Speaker 2:be good.
Speaker 1:Actually, if the show would be 3 hours, we would probably hand in some pull requests live during the show. Yes. Like, read the with the program. No. I think like that.
Speaker 1:No. I think like that. Both of us opening proposals. There you go.
Speaker 2:It's the live go proposal show. Anyway, we're we're really interested to hear from you, what format you think is best. And you know it doesn't have to just be a matter of minutes, we've also considered other options like maybe we stick to hard news for the first 10 minutes and then softer community related news for another 10 minutes or whatever. We wanna hear from you what is best for you, for your commute, for your listening habits, and we'll try to respond accordingly and and come up with a format that works for us and for the listeners.
Speaker 1:So we're gonna put a poll up on Slack and you could just, respond. If you're not in the Slack community, it's a good chance to join. Definitely is. Before we thank our Patreon, I wanna shout out a new book. It's not strictly go, so he kept it for the ad break.
Speaker 1:It's called Getting Things Done by Omere Rosenbaum, my friend.
Speaker 2:Visual and practical guide to get. Nice.
Speaker 1:So you're a book aficionado. You read a lot of technical books.
Speaker 2:Yeah. What do you
Speaker 1:think about when I you know, I'm I'm just, like, holding it up to the camera.
Speaker 2:Yeah.
Speaker 1:Judge it by its cover. What do you think? I know you're not supposed to do that. But
Speaker 2:Yeah. It has a nice cover. I like that shade of blue.
Speaker 1:It's free Code Camp, press, which is good.
Speaker 2:I don't know that, publisher very well. So I don't have an opinion based on that.
Speaker 1:They're reputable, I would say. Okay. They have some cool stuff. And just flipping through the book, most pages look like that. You have a bunch of terminal windows showing your commands and you have a bunch of drawings showing you, I'm a little surprised to see color there.
Speaker 2:Like it's mostly black and white and then there's a little bit of that's pink or something there. Right?
Speaker 1:Yeah. So it's a colored, like syntax highlight to the terminal. It's actually screenshots of a terminal.
Speaker 2:Okay.
Speaker 1:And you have some several colors there. Yeah. It's it's it's very colorful. It is visual, like like it says on the cover. I think there are 3 types of developers.
Speaker 1:Right? The ones that don't just don't care about source control is just something that gets in the way. It's not a tool. They just wanna push their code. They don't care.
Speaker 1:So that's one type. This book is probably not for you. On the other, the end of the spectrum, people like me who nerd out about every single tool and learn too much about it. So this might be the book for you, if, you know, you wanna get super deep into, Git. If you're in the middle and you just wanna pick a topic to get slightly better at as a software engineer, I think Git is a very very very safe bet.
Speaker 1:You're gonna use it in every company you're gonna work for And it's always nice to be that person on the team who knows how to solve that gnarly rebase, you know, three way merge from 2 different repositories and a sub model issue. So it's nice to be that person because everybody thinks you're smart but you're actually just moving some files around. So I can't recommend getting things done enough. We'll put a link in the show notes. This is not sponsored by the way.
Speaker 1:Omer doesn't even know I'm doing this. I'm just recommending the book. So you're ready for
Speaker 2:a hot take?
Speaker 1:Yes.
Speaker 2:Alright. If you need to know all the fancy stuff with Git, which by the way, I'm I'm this I'm I'm like you. I'm the I'm the nerd out on tools. I love Git. I think it's a really powerful tool and I I know way too much about it.
Speaker 2:On the other hand, in my other life that doesn't talk about Go, that talks about CICD and stuff like that and trunk based development, in that life, if you need to know a lot about Git, your branching strategy is probably too complicated. That's my hot take.
Speaker 1:Microphone sizzling.
Speaker 2:And on that note, I think we're done. We
Speaker 1:just need to thank our new Patreon. Oh, yeah. Yeah. Yeah.
Speaker 2:I don't even know the name. This is a surprise for me too.
Speaker 1:Thanks a lot to our newest Patreon, Joost Helberg. I really hope I I picked the correct pronunciation. And thanks a lot to all our patrons. We're not gonna mention every single one every episode because that's a bit too much. But we do have 11 members, 10 of them paid, which is we're, like, inching in on half of our limit.
Speaker 1:We have a limit on Patreon by the way. We're not looking to make money out of this. We just wanna cover the show expenses. Yep. So we're halfway there, which is amazing.
Speaker 1:And that's pretty cool. Yeah. Yeah. It's a lot of fun to see people care enough about the show to, pay for it. It validates the fact that this is useful.
Speaker 1:Like, I was really worried that people were just nice, being nice to me about the show and Yeah. Went actually listening. And whenever someone actually came up to me and was like, oh, I heard on your show that x y zed and it was useful. I was like really surprised. Now I feel sort of validated.
Speaker 1:So
Speaker 2:Yeah. When someone tells you your 3 year old's drawing is beautiful, you're like, yeah. Thanks. When they pay for that 3 year old's drawing, then you know that it's actually cool.
Speaker 1:Yeah. I for example, when my mom told me, oh, your podcast, it's it's so nice. I was like, yeah, sure. Thanks for your money. That's, first and foremost.
Speaker 1:But also thanks for the feelings of validation. We don't have an interview for y'all, this week, but we
Speaker 2:I hope next week we will. Now that I'm not traveling, we're getting back in the normal schedule. Speaking of traveling, I'm gonna get in the car here in a few minutes and drive to, to Brussels to to be at Fosdimm. So I hope to see some of the listeners there.
Speaker 1:Oh. Yeah. There's a lot of FOMO because people, talk about it in the channel a lot. Yep. Yep.
Speaker 1:So enjoy Fostem. Y'all enjoy, the rest of your weekend or week or whenever you're listening to, day and or evening. And we'll catch you all next week.
Speaker 2:Until next week. Bye.
Speaker 1:Bye.
Creators and Guests
