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

Jonathan Hall:

This show is supported by you. Stick around till after the news to learn more about that. This is Cup of Go for Friday, December 13. Keep up to date with the important happenings in the Go community in about 15 minutes per week. I'm Jonathan Hall.

Shay Nehmad:

And I'm Shay Nehmad. Hey, Jonathan.

Jonathan Hall:

Yes, Shay.

Shay Nehmad:

How do you scare a developer?

Jonathan Hall:

I'm gonna say something about Windows, but I don't know. Leave the windows open.

Shay Nehmad:

My other car is a CDR.

Jonathan Hall:

No problem.

Shay Nehmad:

Hello, everybody. It is Friday 13th. We hope you're, all spooked up. Actually, that that's a good question. What's your, most, like, the scariest movie you like?

Shay Nehmad:

Or I guess the horror movie you like the most?

Jonathan Hall:

I don't I don't like horror movies, honestly. There's a few that kinda count as horror that I guess I like. I I guess I'll say the 28 Days Later series because I the 20 year 8 years is about to come out. I just watched the preview for that. I'm kinda interested in that one.

Jonathan Hall:

I I I guess that counts as horror.

Shay Nehmad:

I'm down to clown with, some horror movies. The Shining. That's a good one.

Jonathan Hall:

That's a good one. Yeah. Yeah. That's a good one.

Shay Nehmad:

But nothing as scary as looking at my Jira backlog. So let's look at something else and talk about, Go. But we do have something scary to talk about. Security vulnerabilities in the crypto language. And then again, security vulnerabilities in the crypto package.

Shay Nehmad:

Before we jump into that, I just wanna give the rundown of what we're gonna talk about this week. So the security vulnerability as mentioned, we're gonna start talking about the 124 draft release notes as 124 is set to come out around February ish. Oh, Valentine's Day. We always have that, bet.

Jonathan Hall:

It's always it could be Valentine's Day, but it won't be.

Shay Nehmad:

Yeah. So we're gonna start going through the draft release notes so you know, what's definitely there. Then we have 2, blog posts to talk about, 1 from Dolthub and 1 from Victoria metrics, and one Twitter thing to go through about a new observability library. And a whole bunch of things in the lightning round. We have a lot of things to talk about.

Shay Nehmad:

Our backlog is only growing, just like my real one. So let's talk about, some Go, shall we?

Jonathan Hall:

Yes. Let's see a security. So I saw that, XCrypto was updated, but, did you dive into it to understand why?

Shay Nehmad:

Yes. Let me ask you. Assuming I'm not shy, would you let me come on the show?

Jonathan Hall:

Maybe.

Shay Nehmad:

Assuming I am shy, would you let me come on the show? Yes. Alright. Can I come on the show? Yes.

Shay Nehmad:

So if you were to base your, answer on the first question, you would say no. Right?

Jonathan Hall:

I might say no. Yeah. It depends on who you like, yeah. So Shai is permitted to go on the show. Other people some other people are and some aren't.

Shay Nehmad:

Basically, everybody's permitted. We're pretty we're

Jonathan Hall:

pretty sure. Much.

Shay Nehmad:

Yeah. It's the other way around. People just don't wanna come. Anyway, the thing is there's an SSH, callback called public key, callback, which you can configure in your server. And the server can, get some questions about some keys like key a and key b.

Shay Nehmad:

Now, I don't necessarily control these keys, but when I do a actual request, you might accidentally, just because of the way it was set up, I can call public key callback twice. 1st with a key I don't own and then with a key I do. And a vulnerable application make an assumption that I control key a or control key b, and then make authorization decisions based on key b where I don't control that key. I don't control the private key. This API is widely misused.

Shay Nehmad:

Like, people just don't get it, and I don't blame them. It's very confusing. So this API is really misused all over the place. So as a partial mitigation, you this change enforces that the last key, passed to this function will be the key that's used to authenticate the connection. So you can't do the thing where you ask with one key and then use another one.

Shay Nehmad:

Okay. You just have to, use the last one. And if you want to do multiple collections, you have to, call it multiple times with the same key if, like, if it's necessary. Like, the the client still may not control the original key. You're just not gonna make that, like, mistake, anymore as the server.

Shay Nehmad:

Okay. So it's a pretty, cool vulnerability, I think. It's very logical. It's very not technical in a sense Uh-huh. Which I like.

Shay Nehmad:

Feels very human. And just shout out to Damien, Turnout, Patrick Dawkins, Vince Parker, and Julius de Vivier from platform.sh and UpSun engineering teams, for reporting this CVE. I think, like, getting a CVE on your on your belt is a pretty major achievement for most security researchers. Sure. And it's very cool.

Shay Nehmad:

And it's so cool, I actually went to their site, and their site looks pretty cool as well. Like, platform built to Sage looks like a pretty awesome service, like, platform as a service kinda thing. They're not sponsored. I'm just like, they found the vulnerability in go. They get a shout out.

Shay Nehmad:

Cool. Cool work, guys. So obviously, if you do have SSH in your server, upgrade basically, make sure you don't misuse this, function. The problem is you might import something that does this for you and you're not really aware. That's I think the main thing you have to worry about.

Shay Nehmad:

So I would, like, go, run go voln check and just make sure that you're you're not having any issues.

Jonathan Hall:

Well, I'll be honest. When I saw that there was an update to that package before I go and think about it, I updated it because I feel like anything in xcrypto, if there's an update, I probably want it. For

Shay Nehmad:

sure. We had a a talk about, like, a Slack conversation about the Von check-in our Mhmm. Slack channel recently. That was pretty interesting. Like, how people approach running Von check.

Shay Nehmad:

Right?

Jonathan Hall:

Yeah. It's a it's a good question. Like, do you run it for every pull request? That was kind of the topic. You run it for every pull request and it's a it blocks merges if there's a break, or do you run it once a night, or, yeah, different ways to do that for different projects.

Shay Nehmad:

So so some people say it's it blocks the word on every feature branch and so basically the first person who sees that needs to make a fixed branch first and the the fact that this workflow, which I think is literally the most severe workflow you could have, Right? The the person was like, yeah, this works really well compared to Node. Js where Yeah. Yeah. So even the strictest possible workflow is, pretty good.

Shay Nehmad:

I don't think it's necessary just in terms of, like, if there is a critical critical vulnerability, you're gonna hear about it in the news. Right? You're gonna notice you're gonna hear it on this show and the world isn't that fast to react. Like, all I'm saying is if your vulnerability program is actually as good enough as your comply, like, compliance requirements, like your regulator is asking you to do, you're probably overachieving compared to the rest of the software in the world. But I I wouldn't do it.

Shay Nehmad:

Stop the world. Like, it's just cognitive load or, like, you're taking people out of flow state. I don't like it. Oleg from the channel, Oleg Kovalov suggested to just do it a cron job on on a weekly. Just, like, fix it and ping everybody to rebates, which I think is a lot more reasonable.

Shay Nehmad:

But it's GoVonczyk, very cool, and crypto, very scary.

Jonathan Hall:

Shadi, did you leave a window open or something? Is there a draft in here? Oh, I

Shay Nehmad:

don't know. Why are you are you hearing something? Are you seeing something?

Jonathan Hall:

Oh, oh, oh, here it is. It's the Go 1.24 draft. And that's our segue, folks. Sorry for the bad jokes. That part probably.

Shay Nehmad:

Hashtag sorry, not sorry.

Jonathan Hall:

Yeah. Exactly. So we're not gonna talk about the entire draft today of the 124 release notes because that would take too long. We're already gonna be over our 15 minutes. But we're gonna talk about a couple of the highlights.

Jonathan Hall:

So so first up, I'm I'm excited about this feature. We get the new, to I don't know how to call it. I would say tool, but, you know, it's a tool that's called tool. Mhmm. So you you know how shy sometimes you, maybe you're using a code generator.

Jonathan Hall:

Maybe you're building mocks or you're using SQL c or something like that that generates code. And it's it's how do you track that in git so that you always build against the correct version?

Shay Nehmad:

So you have to create a file. I think it's called tools dot go, and then you import it, but you don't actually use it. And then everybody who's new to the project is confused. And then someone deletes the file because, like, oh, there's nothing here. Like, someone meant to do it, but they forgot.

Shay Nehmad:

And then nothing works for a while until they figure it out, then you revert it. Fun times.

Jonathan Hall:

Yeah. So you yeah. Basically, just like like you said, you create this typically called tool dot go or something like that or tools dot go that, imports the things you want, but it's never compiled. So that way, it kind of fools go mod into importing the correct version and tagging them and go to mod and go to some. Well, now we're gonna have 1st class support for doing that correctly with, tools.

Jonathan Hall:

So you can use Go tool, and, I guess you use it kinda like you do with, Go mod, but you rather than it being a mod that's compiled, you're just saying, this is a tool I use in this project. Please track it for me and use this specific version of it.

Shay Nehmad:

And the the thing is this is something that other languages have had for a while. Right? When you work in in Python or Node. Js or Rust, you have like dev dependencies. It always felt really missing at least for me, Ingo.

Shay Nehmad:

Like I I've if you remember, we interviewed the author of a go test sum. I think it was one of our first interviews, like, ever.

Jonathan Hall:

Mhmm.

Shay Nehmad:

And I really like this tool, but I can't, like, justify putting it in Go tools. That feels really bad, like, setting up a tools fight just for a test output. But now that it's gonna be in the Go mod in, like, a sane place where you it's where you put the dependencies, I think I'll switch to using it, like, full time. Same thing with Golang CI Lint. Right?

Shay Nehmad:

All these tools that you expect to be installed. I just expect them to be installed by default.

Jonathan Hall:

Right. Yeah. I think this will help with a whole bunch of stuff. I'm really looking forward to to using it and Ergonomics. Yeah.

Jonathan Hall:

It'll be great.

Shay Nehmad:

The second feature we wanted to highlight, from go 124, is about, like, generics, but it's actually about refactoring. So here's the here's the use case. Right? Let's say you have an old package. Right?

Shay Nehmad:

And you wanna move to the new package which is, better. Right? Like Barney said from, How How Met Your Mother. New is always better. But I'm gonna give you 4 words to live by.

Shay Nehmad:

New is always better. That's the rule. Right? So way back in go 19, there have been type aliases where you could say type, let's say, x equals to some other type type y. This is usually a useful feature when you wanna take something that's untyped, that something that has like a basic type that looks pretty complicated like a map from a thing to another thing.

Shay Nehmad:

Just wanna give it a clear name. So I I've always found it useful for that.

Jonathan Hall:

Yeah.

Shay Nehmad:

But it's just a name for an existing type. Right? You didn't create a new type. Just gave a name to, to a new name to an existing type. Mhmm.

Shay Nehmad:

Now if you have an old package and a new package that makes it really useful if you wanna migrate from an old package to a new package, you can have the same name for both. Right? By type aliasing them and you gradually update the use of the old package user to the new package type just throughout your project and the compiler is happy because it's the same name. You just change the import. The problem is 118 introduced generics and you couldn't do that.

Shay Nehmad:

Like if you had a generic type in an old package, you couldn't alias it with the new type and now you can. It looks really really reasonable type your new type name and then square brackets t any equals to the old type and parens t which basically stands for hey, I'm lacing a new type it can be anything but it's actually the old type with its type constraints that are already defined so it's not actually anything. So you have full type compatibility when moving like generic types and you can actually have this already with the go experiments so if anybody like really really really wants to use it you know, like Robert Griesemer, the the person who told us about this in the blog post, they can already turn this on with, experiment flag and now it's just gonna become the default because I guess it's stable enough and they didn't find any bugs.

Jonathan Hall:

Mhmm.

Shay Nehmad:

The the main reason I'm excited about this is it's an improvement to generics that doesn't introduce more features. It just makes it more ergonomic. So it doesn't make the language more complicated which I think is a good thing. And everybody agrees on the Internet and nobody has a different opinion about Go, right?

Jonathan Hall:

Yeah. Everybody thinks generics are perfect. Oh, wait. I found this one guy who disagrees.

Shay Nehmad:

This one guy.

Jonathan Hall:

What's one guy?

Shay Nehmad:

One guy in every single Java developer in the world, they disagree.

Jonathan Hall:

Yeah. And so Nick Tubby wrote a a post a while back back in November about generics and some of his challenges with them and got some feedback on Reddit and other places about that. And so this is kind of a follow-up to that. Tldr, the old his old post overlooked some of the features in Go. He gave a couple examples of some comments he got on about his old post.

Jonathan Hall:

The one he said that stung the most was, this code looks like Java. I'm sure we've all experienced that before if you've we need to go for any other time. We run into this code that looks like Java written and go or PHP written and go or Ruby written and go, etcetera. Anyway, so he writes this. It's a fairly long post actually.

Shay Nehmad:

Very detailed, very detailed.

Jonathan Hall:

Yeah. Yeah. Kudos to him for being detailed and not just hot taking and and trying to throw crap. He's trying to be detailed here.

Shay Nehmad:

I think the the main thing is about having more features with generics that other languages tend to have that that allow you to do more complicated things with generic.

Jonathan Hall:

Yes. And he also makes the point that he appreciates the Go team's reluctance to add new features, which I completely agree with. On the other hand, you know, there there has to be a trade off. Right? And I think that's kind of the whole point of this article is is we had to find balance between adding features too quickly and making the language bloated and confusing and adding them too slowly and sort of we're working with our hands tied behind our back, while we try to work around the language's limitations.

Jonathan Hall:

And clearly, Nick feels that those too much on the hand side behind your backside of the spectrum. I'm not sure I agree, although I definitely can identify with some of his frustrations. There are I have definitely found places where generics, in particular, have felt too limiting. But I'm not sure that the solution is to just add more features because I don't want Go to become Java or PHP.

Shay Nehmad:

There are a few things like self referential type aliases and parameterized type aliases, which funnily enough, you know, the last feature we discussed from the 124 blog is in that same neighborhood, but it's definitely not the same scale. These are like huge Ferraris in the driveway whereas the type aliases, 124 supports generics of theft. It's like a cart that you can pull by hand. It's definitely not the same scale of complexity when you think about it. Yeah.

Shay Nehmad:

The thing that first of all, I love this, blog post. Shout out, Nick. Like, thinking about a language that deeply and, like, saying actually listing features you would want and giving examples, Super cool. The problem I have with it is that the whole focus of the article is about the code. Writing clean code and the act of coding, and not the act of reading the code.

Shay Nehmad:

It's like, how can I code golf this and make this as concise and as quote unquote clean, which I found as as years go by as an excuse to, like, the way I like it versus, anything else?

Jonathan Hall:

Mhmm.

Shay Nehmad:

And nothing about how this will impact the artifact in production. Like, will this make compiling slower? That's a bad trade off. Will that make, race conditions or, like, complicated edge cases in production harder to debug because you don't have you just can't point to, like, debugger on the line and just know what it says because a lot of things are generated by the compiler sort of behind your back. The higher level and the more complicated you make a language, it's almost impossible to make that without the trade off happening somewhere.

Shay Nehmad:

Whether it's compilation time or the actual artifact you're shipping being worse because you I don't know suddenly you have to do reflection in the runtime. Right? So this on the one hand does a really really deep dive into the code like the construct but it almost says nothing about the artifact like the binary that's gonna come out the other end and I think that's it's very easy to do that because you spend your days nights looking at the code but the code is not the end all be all. It's just a means to generating the binary that's actually running in production. And I I really prefer blog posts that say, hey, maybe you can do this feature to make compiling faster or to make the binary smaller, to make things that matter to the users and not things that make, developers productive.

Shay Nehmad:

Because I found that it's very rarely the, like, latest and greatest feature in the language that matters. It's the test suite. It's the flow state. It's whether you have meetings. It's whether your manager's an asshole.

Shay Nehmad:

Like, there's a lot of things that matter a lot more for your developer productivity. So but I again, I really like it. I also really like the memes. Good choice of memes which is always appreciated in a in a blog post. It's posted on DultHub which also, again, not sponsored, but I think they have a pretty cool idea.

Shay Nehmad:

I don't know if you've heard of them, but they're trying to do like a database with branches. Like, you can diff and branch your DB, which is pretty cool. Like a SQL interface, but a git approach with, like, production databases, in the cloud in the back end. Like, that's pretty cool. That's a cool idea.

Shay Nehmad:

I'm not sure how we use it, like, what's the use case, but it's very cool.

Jonathan Hall:

Well, you should get someone from Dault on the show and talk about it.

Shay Nehmad:

Damn. Nick, if you're listening to this or if someone sent you this episode, come on the show, man. We would love

Jonathan Hall:

to have you. Yeah. Oh, what does that sound mean? It means it's time for the lightning round.

Shay Nehmad:

You're you're going a bit heavy handed with the this is not a kids show. Lightning round.

Jonathan Hall:

First up in the lightning round, we have weak pointers in Go and why they matter now by Phong Li. It's a blog post that goes into the upcoming feature in Go 1.24 about weak pointers. What are weak pointers? It's the ability A weak pointer is basically a way to reference a chunk of memory without locking it down. So the garbage collector can clean it up if no one else is actively using it, but it a strong pointer, the normal type of pointer says, I'm using this memory, you can't clean it up.

Jonathan Hall:

A weak pointer says, if it's still there later, I'd like to have it, but if if you need it for something else, go ahead and clean it up. So it's a memory optimization technique. And this blog post goes into why it's important now and how to use it. So check out the blog post, and we'll dive into this more a little bit later on in a later episode, as go on 24 approaches.

Shay Nehmad:

On my lightning round table, there's a really cool new, approach for for instrumenting, observability over from the folks at Datadog, which I really think, other than the fact that they're very expensive, are really best in breed both in, developer documentation tooling, observability. They're they know their stuff. Product design, and this blog post just flaunts it, man. They released, Orchestrion, which is a cool name. It's been on our backlog for a while now.

Shay Nehmad:

I'm really happy we're getting to it. It's compile time auto instrumentation for Go. Most of their customers have instrumentation for APM. Right? They want to do tracing.

Shay Nehmad:

They want to, like, get signal out of your application. But you don't want to waste developer time doing that because it's basically the same everywhere. Right? Languages like Python, Node, whatever, the runtime just allows you to do that. You can just inject things into the runtime all willy nilly because it's, you know, you have a very high level.

Jonathan Hall:

Dynamic. Yeah.

Shay Nehmad:

Yeah. Exactly. Go compiles to a native binary. So it's very difficult to inject stuff at run time. Historically, if you wrote Go, you just spend a lot of your development time, like, putting metrics everywhere and traces and and middlewares, etcetera, etcetera.

Shay Nehmad:

Right? Where this is not your business logic. You may want these dashboards for SRE reasons or debugging capabilities, but that's not the software you're there to build. So they created a thing called Orchestrion which is I'm not sure how they do it, but they process the source code at compilation time and just automatically insert instrumentations to give you traces. Interesting.

Shay Nehmad:

Yeah. Very very, cool. They use it for multiple products at Datadog. If you never used Datadog before, it's a huge platform with a lot of capabilities. I'm not saying that necessarily is a good thing, because all of these capabilities are separately priced and very expensive.

Shay Nehmad:

But it's not just used for tracing. At least at Datadog, they also use it to run their new exploit prevention, thing. It's a sort of a reachability analysis. It's just very interesting. I never thought about compile time instrumentation as an option.

Shay Nehmad:

Right? I just thought about either you patch the binary which is very dangerous, you manually instrument which is time consuming or you do things like eBPF which don't give you a lot of visibility and don't always work, and they don't work locally, and they're like kind of iffy. But the orchestration is almost fully automated and gets you all the features. So I really really like it. I can't wait to start using it actually.

Shay Nehmad:

I really hope it's useful outside of the Datadog sphere. And it's a very cool approach. I didn't know existed before, to be honest. Cool stuff.

Jonathan Hall:

Cool. One other lighting round item I'd like to bring up is a, blog post that was brought to my attention by one of my, Go mentees. It's called building a distributed log using s 3 in under a 150 lines of Go. Damn. The basic idea is it's an open source project that the the author of the blog post is is published, and it's a way to log to an s 3 bucket.

Jonathan Hall:

So if you need to keep your logs around sort of indefinitely, for compliance reasons or just because or because it's fun or whatever, this little tool will do that. Yeah. Maybe you like your logs and you you know, if you wanna collect them. They still let you do that. My my mentee really liked it just because it was, kind of impressive how you could do so much in a 150 lines of go.

Jonathan Hall:

And, that's kind of a whole project. So I won't say more about it. There's a link in the show notes if you wanna check it out. Very cool.

Shay Nehmad:

I think people usually say Go is a very verbose language, and you end up with a lot of code for not a lot of bang for your buck, but that isn't always necessarily the case. It's only when you need to represent really high level business stuff. But when you just are building a log thing that goes into s 3, you can't get any better than that. Yep. One final item, this is a watch recommendation for a lecture that was released just now from a Golang meetup in Prague 2 days ago from Robert who has a last name.

Shay Nehmad:

I'm not gonna say it because there's no chance. It's like lasfrashkak, something like that, about rethinking domain driven design in Go from myths to reduced project complexity. I watched it over lunch today. It was very, very good. You should do that as well.

Shay Nehmad:

Cool. Especially if you're like in architecture slash middle management slash team lead sort of role and you're scratching your head why things are harder than you expect them to, this will answer a lot of those questions. Really good stuff. And it's about go, like, it's not generic, architecture lecture. And that wraps up our lighting round.

Shay Nehmad:

Stick around for a short break. Hello. Like Jonathan said at the top of the show, this scary Friday is a great time to give us your money. We want your money. Is that scary enough?

Shay Nehmad:

Yeah. This show is supported by our beautiful Patreon supporters. If you wanna join that group and kick, $8 a month our way, we would really appreciate it. This is a hobby. We do it for fun, and to learn but it's a rather expensive hobby mostly for editing fees and and hosting fees.

Shay Nehmad:

Supporting us via Patreon is the best way to support the show. If you wanna reach us, you can go to cupago.dev. You can find the links to everything there including the our Slack channel, hashtag cupago with some interesting conversations. You can email us at news at cupago.dev. And another way to support the show is to share it.

Shay Nehmad:

Share it with a friend or a colleague or leave a review on what wherever you listen to your podcast like Apple Podcasts, Spotify, blah blah blah because it helps us climb the charts and just reach more people, which is fun. We last week, we said we want to do a live episode for our, a 100th episode celebration that's gonna be in, like, 2 months ish. People gave us really warm, responses on that. So, yeah, it's definitely happening. We're thinking about some fun ideas, maybe doing the live participation, polls, Twitch, YouTube live, whatever.

Shay Nehmad:

We don't have a we don't have it set in stone yet. So if you have a cool idea or if you wanna help us arrange that, that would be very cool.

Jonathan Hall:

You know, sorry. If it if it happens to fall on on Friday 13th again, we should do some live coding because that's pretty scary.

Shay Nehmad:

The scariest of all. No. I'm not the the main thing that's gonna be scary is how rusty I am with, Google. Cool. So or you're suddenly gonna see my setup, and you're gonna be, like, you're using VIM with Versus Code with these plugins?

Shay Nehmad:

For the amount of time we've podcast together, we never recorded together. I mean, that could be a good thing to do in the live episode, actually.

Jonathan Hall:

That sounds like an April first thing to do.

Shay Nehmad:

Yeah. For sure. We could try one of these, coding challenges we talked about recently. Oh, yeah. Yeah.

Shay Nehmad:

I I get his newsletter, and every time, like, yeah. Yeah. I'll do that. That sounds like he recently their latest coding challenge was, like, SoCAT. Like, yeah, that would be so cool.

Shay Nehmad:

I look at my calendar and I cried for 10 seconds and I went to my next meeting.

Jonathan Hall:

Yep. Yep.

Shay Nehmad:

So, yeah, that that will happen. We'll give you details, as that, comes up. And finally, one super boring update. If you're buying things from us in the swag store, you can buy some cool stuff like, a hoodie or a cup. Stickers.

Shay Nehmad:

Yeah. Stickers are pretty cool. We need to do some changes, to comply with the EU's general product safety regulations, and everybody just turned off the podcast.

Jonathan Hall:

Where? Where?

Shay Nehmad:

Yeah. So everything in the EU needs some additional product information. We're gonna need to turn on that setting. So basically, if you're in Europe, our products are not gonna be available for a while. You're you're gonna have to wait.

Shay Nehmad:

Sorry. I need to update everything in the GPSR section in case our cups are extra dangerous. Yeah. And, no politics, but thanks to you for, doing some regulation. You really needed a bit of that.

Shay Nehmad:

You you lacked. You lacked some regulation. So yeah. But the product's not gonna be available for a while until we figure it out with, our supplier, Printify. So if you really, really, really want one, you're just gonna have to wait until we And

Jonathan Hall:

if you do really, really want one, let us know so we know that somebody's waiting, and maybe it'll maybe it'll Yeah. Fire at our buzz.

Shay Nehmad:

Cool. Thanks for listening to our show this week. That's all we have for you. For Rogram exited. Goodbye.

Shay Nehmad:

Rogram exited. Goodbye.