- Upcoming conferences
- 🇯🇵 June 8: Go Conference 2024 @ Tokyo, Japan
- 🇩🇪 June 17-20: GopherCon EU @ Berlin, Germany
- 🇳🇱 June 19-21: DevOps Days @ Amsterdam, Netherlands
- 🇷🇺 June 24-25: Golang Conf 2024 @ St. Petersburg, Russia
- Proposals
- 👍 Accepted: go telemetry subcommand
- Previous discussion on Episode 62
- ⛔ Declined: Notify of new major dependency versions
- Previous discussion on Episode 62
- 🆕 New: Make math/rand.Seed a no-op
- 👍 Accepted: go telemetry subcommand
- The unique package has been implemented
- ✅ Previous discussion on Episode 33
- Around the community
- 🤔 Reddit: Is it idiomatic to create a constructor that returns an interface?
- GitHub CLI 2.49.1 includes contribution from Shay
Creators & Guests
What is Cup o' Go?
Stay up to date with the Go community in about 15 minutes per week
This show is supported by you. Thank you to all our existing patrons. If you wanna join as a member, wait around till the ad break to hear more. This is CapaGo for May 17, 2024. Keep up to date with the important happenings in the Go community in about 15 minutes per week.
Shay Nehmad:I'm Shay Nehmad.
Jonathan Hall:And I'm Jonathan Hall.
Shay Nehmad:And this week's episode, you can run on one x. You don't need to 2 x it. We don't have an interview. Just the hard news. Hard.
Shay Nehmad:I'm imagining the BBC theme, like Yeah. Breaking news. There's a conference a few weeks from now.
Jonathan Hall:This just in. Shai will be flying to Amsterdam. Woo hoo.
Shay Nehmad:And many more. Weather, sports. Wait, then no sports. No sports here, all nerds.
Jonathan Hall:It's cloudy outside. There's the weather report. Okay. So let's talk let's do it. Let's talk about some conferences.
Jonathan Hall:In chronological order, June 8 in Tokyo. You're in Japan, we have Go Conference.
Shay Nehmad:Go conferenso. Like, something like that. My wife can pull off the Japanese accent really well.
Jonathan Hall:If you speak Japanese, this would be a great conference to go to. It looks like it's all in Japanese.
Shay Nehmad:After that, we have 2 events that coincide. You'll have to pick you'll have to pick and choose. Isn't that difficult?
Jonathan Hall:It it's it might be. They're close enough even that you could theoretically do both if it weren't for the fact that they were at the same time.
Shay Nehmad:So what's the first one?
Jonathan Hall:The first one is GopherCon, Berlin. This is the big one. If you're in Europe, this is the traditional GopherCon Europe. Of course, this year, we had 2 GopherCon Europe's. This is the second one.
Jonathan Hall:This is the one that's been around for longer, June 17 through 20. Check out Gofer Con if you're in Germany.
Shay Nehmad:Yeah. And if you plan on going and you're a listener, I'm sure that, we have probably 1 or 2 people or 10 or 20 Mhmm. Who listen to the show and go. Yeah. And are planning to go to go for Connie Yu in in Berlin.
Shay Nehmad:So if you're planning to go, drop a message. Last time someone did it, they found another listener and, like, met on the conference floor. That was pretty cool.
Jonathan Hall:Yeah. Send send us a photo of the the cup of gophers together, a gopher converter, Robert, and that'd be awesome.
Shay Nehmad:That will be awesome. And I'm just gonna do the same because I will be at DevOps Days Amsterdam, June 19th to June 21st. Jonathan and I are planning to also do something, probably a physical episode, where you can join the recording. We're looking for a space right now in Amsterdam. If you hear about anything or you have a space in Amsterdam, we would love to know about it.
Shay Nehmad:So I'll be there. And also, Jonathan and I will finally meet and I will discover if Jonathan has legs, which I am yet to confirm.
Jonathan Hall:We'll also probably try to get together for some drinks in the evening. So if you're not going to DevOps Days and you wanna meet the 2 of us in person, just reach out on the channel and we'll we'll make it happen.
Shay Nehmad:Amsterdam, on the evening of 19th, June 19th. It's gonna be fun.
Jonathan Hall:One last event to talk about. It's gonna be a short description because I don't speak Russian. But if you're in the Saint Petersburg area, June 24 25, Golangconf 2024 is happening there. That's all I can say because I don't speak Russian. Let's talk about some proposals.
Jonathan Hall:How about it?
Shay Nehmad:Yeah. So I'm tired from events. Probably from going to all these events, you're gonna get a con flu. You know what I mean? Let's stay home and talk about some programming that we can do from the comfort of our, couch.
Shay Nehmad:We have a few updates on past proposals. So we're gonna breeze through them. If you haven't listened to the previous episodes and you wanna catch up, you can either listen to the previous episode or just go to the show notes and the proposal is there. But we, told you about the go telemetry sub command that they're planning on adding, and we talked about whether we should include the data in the view and or not include the data in the view, whatever. This was pretty much a shoe in to get in.
Shay Nehmad:There was already an x package that did it and it's just moving it to the Go toolchain. It got accepted. There's gonna be a new command. It's gonna be called the go telemetry, and it has a few very simple subcommands. On turns it on, off turns it off, Local turns it on but doesn't send any data to the server.
Shay Nehmad:Clean deletes all the data if you wanna, I don't know, anonymize it or just save up on some space, even though it's very, just a few kilobytes, like, no problem. And finally, you can look at the config as well. Telemetry config just lets you know where's the data and when did you start collecting. I imagine this being maybe remotely useful for big companies who wanna track, like, some internal telemetry as well for Go developers. But again, this is mostly for the Go team and it's gonna improve the tool.
Shay Nehmad:I highly recommend, you know, if you listen to this, go to your terminal and make sure Go telemetry is on in, like, a few months when this, gets merged. Just to help the Go team know what they need to do, and improve the language going forward. I think this is a great proposal. It also had 0 controversy or arguments or bike shedding about it Mhmm. Yeah.
Shay Nehmad:Which is rare to see. So this one's in. What's a new one?
Jonathan Hall:Yeah. Another one, another quick update. We talked I think it was last week even also. We talked about the proposal to have Go Build and Go Run notify you about new major versions of dependencies available And we both weighed in on the Ne side. Well, the NAS have it.
Jonathan Hall:It's been declined, so we won't have that. You'll still have to use, what's the one from GitHub? Dependabot? Dependabot. Yeah.
Jonathan Hall:You still have to use Dependabot or or it's equivalent, third party SaaS tool or whatever to to do that for you.
Shay Nehmad:Whatever tool you choose, I I do think it's important to realize that a major version has it's like just a social contract. Right? And people can upgrade the things in breaking changes in in patch versions even. Mhmm. Especially if they're malicious actors, You know, turning on dependable doesn't mean you have supply chain security.
Shay Nehmad:You and when I said, like, nah, last time, one of the things we mentioned was you still have to manage your dependencies, and it's almost impossible to do it all the way down. Mhmm. And I talked about it with my or CISO at Orca about, like, how we do it
Jonathan Hall:and, you
Shay Nehmad:know, it's kind of weird for Orca because we have our own shift left, the thing we rolled out, and we're trying to talk for deep, but we also really wanna be strict about security just because we have all these customers and whatever. So, he told me he actually does try to every now and then just make a list of all the dependencies and review them 1 by 1 and make sure, you know, look them up in the news. Even though we have the tool that does it and all the automated tooling and all the whatever, it just walks through them 1 by 1 and and, like, sometimes you find if you find duplicated dependencies and things you can clean up, which it just lowers the attack surface as well. So I think while you can buy a tool, you know, dependabot or or any SaaS tool or Orca or whatever, There's no escaping the fact that if you decided to, import a third party dependency instead of solving a thing yourself, You're dependent on it and it has costs. It makes your binary bigger.
Shay Nehmad:It has maintenance costs and trying to avoid them using tooling is is one way to do it. But at the end of the day, you need to be mindful of the fact that you have a third party dependency. It brings in problems, performance problems, security problems, licensing problems. You have to pay the maintainer to work on it. Like, over time, it it might be problematic.
Jonathan Hall:It was a cost. Yes.
Shay Nehmad:And it's very good that Go acknowledges that and is like, yeah, I'm not gonna notify your own versions. You have to do your own dependency management because it's different for every library. There's one update, one last update on a past news item, the unique package. Do you remember when we talked about this proposal?
Jonathan Hall:It's been a while,
Shay Nehmad:but, yes, we did talk about that. So this time, the link is not to the proposal.
Jonathan Hall:I think we called it interns. That was early enough that it was still called intern.
Shay Nehmad:Yeah. Right. It used to be, intern. Now it's called the unique. The package is called unique, which I think is better because in interning is, like, a very specific, I think, c plus plus term or whatever.
Shay Nehmad:What I want to draw attention to is not this specific proposal because I think, honestly, you know, all the people who are going to use it already commented on the proposal itself. Sieves and DS Net and, you know, Joe Tsai and all these people, friends of the show. It's just the implementation. It's very simple. It's very clean.
Shay Nehmad:Has nice, like, channels, selects, maps, a few generic functions, all of them very short or them well tested, documented. I think this is just a very, very good, like, piece of code that if you wanna teach some new features of Go or you wanna see, like, what standard Go code should look like, this is a very good thing to take a look at. It's less than 500 lines of actual code, including documentation. And it's very, very simple, and that's contrast to how long it took us to even understand what this does. Right?
Shay Nehmad:Even in preparation for the show when we recorded, we're like, wait. What is interning? What does it mean? Talked about it with Josh Bleecker. Right?
Shay Nehmad:The proposal itself is miles long, and the implementation, like, the interesting part of the implementation is probably, like, a 150 lines and very simple, like, idiomatic Go code. So I really enjoy just reviewing the whole thing and trying to, you know, go through the stack traces and understanding how it works. Because it's a lot of complicated discussions, but they were worth it because the end result is very, very simple.
Jonathan Hall:You say idiomatic Go code, yet I see an underscore import for the unsafe package. Well There there there's 2, like, anti patterns sitting in in one line right there. I know it's for a good reason. But Yeah. Yeah.
Shay Nehmad:It's for a good reason.
Jonathan Hall:Don't do these tricks at home.
Shay Nehmad:Yeah. It's this, poor request was written by professionals in
Jonathan Hall:a controlled environment. Don't
Shay Nehmad:try it at home, kids. So, yeah, it's fun to, like, look at all these things we updated on and seeing that this time our predictions were right. Right? We GoToThemetry said it was gonna go in. The dependency versions, we said it's gonna go out.
Shay Nehmad:And, unique way we I remember us saying the implementation is gonna probably be very simple. So it's official. We're that octopus that knows to predict, you know, World Cup results.
Jonathan Hall:Yeah. Yeah. We're we're basically fortune tellers now.
Shay Nehmad:Yeah. Give us all your money, we'll buy stock. So what's your, what's your, prediction for this new proposal?
Jonathan Hall:Let me flip a coin. Let's see what it how it comes out.
Shay Nehmad:Let's flip a coin, that's nice. But with math rendv2. Not that's not the original one.
Jonathan Hall:So so this, this proposal is, following on the theme from last week about randomness. It's a new proposal from Russ, just created last week. The proposal is to make mathrand, not v 2, the old one, to make the seed function, the global seed function, a no op.
Shay Nehmad:And that seems like a breaking change.
Jonathan Hall:Exactly. Yeah. It seems like a breaking change. Right? And and technically, I I believe it could be for some cases.
Jonathan Hall:But I think there's a really good reason for that. Now the first thing he says is this could be reversed by setting go debug equals ran seed no op equals 1. So if you really depend on that that seed value, you can re enable it with this, compile time, build flag. But the argument is that in in the past, I think just recently actually, they set the seed. They they changed the behavior of the package to set the seed basically securely when it's not set for you.
Jonathan Hall:So now, when people set the seed to something like time dot now dot unix or something like that, which is very common and, thing to do, they're making it less secure than it is by default now. So the reason to make it a no op is to make your code that accidentally uses mathrand more secure.
Shay Nehmad:So it's just a global seed.
Jonathan Hall:So you could still create, still set the seed on your own, non global, random source. So Yeah. That would that would be the other workaround.
Shay Nehmad:We have a few global resources in Go, that I don't really like. Like, there's the global HTTP server or something like that in the HTTP package. You know what I'm talking about?
Jonathan Hall:And the client. That's even worse, I think. Yeah.
Shay Nehmad:Yeah. Yeah. The the
Jonathan Hall:it's like Both of them exist.
Shay Nehmad:I never use it because literally anything including libraries that I import can can mess around with its state and and and cause problems. So you always wanna create like a local thing for your current scope. It's also just better coding. Right? Even if if you're not worried about the global, like, even if you're a 100% sure that your program is, like, single threaded and the access to that global resource is locked, which is not something the standard library promises, not in global not in ran seed and not in, that HTTP client case, it's still harder to test.
Shay Nehmad:Right? And it's harder to promise, I'm not sure how you pronounce it, but, like, idiompancy?
Jonathan Hall:Idiompotency? Idiompotency. I've heard pronounced in place, but yeah.
Shay Nehmad:That whenever you run it twice, it's gonna do the same thing, and it's not gonna do the same, effect if you already did it once. It's very hard to promise things like that when you have global state. So I think it's very reasonable to break this promise on the basis that any library you import or upgrade could break it by accident anyway. So people who will get burned by this being broken, you know, the the refactoring is not very hard and it's you shouldn't be doing it anyway. That's sort of my feeling.
Shay Nehmad:But the problem is that the Go team, when you wrote that code, maybe 5 years ago, the Go team told you this is how you should do it. This is what the docs said. So Right. It is a broken promise, and I'm sure that there are gonna be, like, a few dozen developers who are gonna be, like, very angry at this decision, but for the greater good of the Go community, this is definitely a a good proposal. And it got my upvote.
Shay Nehmad:There is one downvote. I'm wondering who's, like, no. Please allow me to keep my super fragile code. And this will only by the way, this is a Go debug thing, so you can opt out easily. Yeah.
Shay Nehmad:And if you retire the Go debug thing because of the, like, compatibility promise of Go, it's gonna be 2027. So, like, I'm sure you can find time in your calendar before 2027 to replace the global seed call to something else. Yeah.
Jonathan Hall:Alright. Shall we move on to some community news? Cool. I saw something on Reddit that I think we should talk about a little bit.
Shay Nehmad:I really hope it's not, like, responses to my comments on, oddly satisfying. Stuff like that.
Jonathan Hall:Yeah. There's one comment in particular just says, you suck. That's all it says. The question asker on Argo Lang, Sean 9999 says, I have to see this pattern a lot and I wonder if it's a good idea. And the, the pattern is you define an interface, you define a struct that implements the interface and you can create define a constructor that constructs that struct and returns the interface type.
Jonathan Hall:This is a common pattern. I see it frequently. What do you think, Shay? Is it idiomatic or advisable?
Shay Nehmad:Idiomatic and advisable are very two different things, but I think that one thing that stands out to me is if you use this pattern automatically, you're probably coming from, like, Java to to go. Right? Or c sharp to go. You have a few patterns where you have, like, people from c coming to go, They'll define all their variables at the top of the function even though that makes defers harder and the code less readable. If you have people coming from c plus plus, they'll really try to implement the templating engine at some point.
Shay Nehmad:I think the most comfortable migration is from Python actually. People who come from Python into Go or they feel good because they have the type safety and everything, but it's still the only thing they need to wrap their head around is the error handling. And this pattern of, like, okay. Here's a a lot of boilerplate to wrap a single struct that has a single field, is very Java like. Right?
Shay Nehmad:Where you have to write 17 lines to implement, main or c sharp or stuff like that.
Jonathan Hall:Where you have to
Shay Nehmad:have an SLN file just to run the hello world. I don't think it's a good pattern just because you don't need an interface if you're not using, like, polymorphism or something like that. And the interface is implicit in Go. Right? Like, even if I don't have the interface defined, if the struct implements the function the interface defines, the method and, like, it receives it, then it implements that interface implicitly, and it's just noise.
Shay Nehmad:I might need the interface if I have a few different implementations. But as long as you have a single implementation, it doesn't help in any way. And what it does, it it removes you from the struct itself, which is worse, I think. And in this example here by Sean, he he they returned the interface. Right?
Shay Nehmad:They don't return the struct. And I've heard, although I'm not sure how to justify it, that you should accept the most general type you can, like an interface and stuff like that, but you should always return the most specific thing you, you can return. It makes sense to me, but it's hard for me to to say why. Like, it's a good rule of thumb, but I wouldn't know how to justify it if I wrote it in a code review.
Jonathan Hall:So I I I generally agree with you. And I think you hit on the the really important topic, really important point. If you have multiple implementations, you know. So the example here is a dog because, of course, all object oriented examples are about animals. So, you know, if you have multiple What
Shay Nehmad:do you mean examples? A 100% of you the code you don't write isn't about taxonomically, you know, subdividing animal groups and their behaviors?
Jonathan Hall:Well, a lot a lot of my code is, but occasionally, I also, seed random number generators.
Shay Nehmad:Globally only. Anyway, sorry. So the example here is dog. Yeah?
Jonathan Hall:Yeah. The example here is dog. So, you know, if you have multiple dog implementations, then defined in the same package probably, then I think it's reasonable to, return, an interface. And that's, now that I think about it, that's probably the way I I follow the rule. If I'm implementing multiple implementations, I I define the interface and return it.
Jonathan Hall:Otherwise, I return a concrete struck type. I just make the in this case, it's underscore it's it's lowercase dog on exported. I would, make that struct exported and capitalize it and not create the interface. And let my consumer create an interface if they need to for testing purposes.
Shay Nehmad:So here's a question. Let's say I do wanna do the thing you did. I have let's take a more realistic example, d b instead of dog. Right? Mhmm.
Shay Nehmad:So I have and you like like database code anyway, so you might be the right person to ask. So I have real DB connection and mock DB connection. Right? These are the 2 implementations I have, the 2 structs. Right.
Shay Nehmad:Do you call the real thing that people actually wanna use exported DB connection and the interface, like IDB connection, exported? Or is it the other way around? The interface is the correct name, and then you have dbdbconnectionimple and dbmeconctionmock. So it depends in in my case. If this is an internal package, you
Jonathan Hall:know, an internal application where I'm the only consumer of that library or or my team is the only consumer of that library, I'll probably do basically what you described and I'll create the interface. And in fact, I might create more than 1 interface. I might have like a user's interface and a and an orders interface and so on that maybe all reference the same underlying implementation and that's just to make it easier to pass around and and see, you know, which part of the database am I using or which repo am I using or whatever. If it's a a library that I'm exposing to the world, you know, an open source project or something that's used by multiple teams in the company, then I'll be a lot more careful about how I do this. And I will I'll just put more thought into it.
Jonathan Hall:That is I I don't know that I have like a canned answer. I'm just gonna have to put a lot more thought into how pristine do I want this API to be considering that it's it's really meant to be an API. It's used by others who aren't maintaining it.
Shay Nehmad:So there are no like you said, there are it's always it depends. There are no strict answers. But I do think if you always use the pattern of defining an interface, defining a struct, defining a constructor that returns the interface, you should rethink your ways. Just a struct, that's exported does the same thing with less words and is easier to maintain. And it's sort of, Yagni.
Shay Nehmad:Right? Like, you ain't gonna need it. This is something that's at least if you're considering, like, idiomatic Java or I should say idiomatic according to university, like Java and c sharp, the, you know, professors will dock points if you don't define an interface for every class even if you have just one implementation. Because you should pass an interface, not a class because it has a different meaning in these fully object oriented virtual table thing languages. Right?
Shay Nehmad:But that's how it works in Go. Interfaces in Go are implicit. And I would say, if you're still not convinced, the best way to understand, at least my view on this, is to read, about the implementation of interfaces. Like, how interfaces work in Go, what are pointers, things like that that when you come from Java or c or c sharp or languages like that, you never think about. Right?
Shay Nehmad:It's a pointer to an interface. It's a reference to an interface. It's a reference to the concrete class. It's a reference to the virtual table, whatever. Reading about these things will make you a better programmer anyway, but, it will definitely clarify why you don't need the interface if there's only one implementation.
Shay Nehmad:Cool. One last community thing to talk about. Have you seen the new release notes for the GitHub CLI?
Jonathan Hall:You know, I don't use the GitHub CLI. I like pain, so I use curl for everything.
Shay Nehmad:By the way, Jonathan uses Linux, just in case you didn't know. So recently, and when I say recently, I I mean, a long long time ago, it was, like, March, February. At work at Orca, we have, we use GitHub. We use GitHub actions and we have really long action names, like, for the specific jobs and the specific steps. You know what I mean?
Shay Nehmad:Just because we have, like, unit tests and then a matrix of unit tests because we split them because we wanna make the CI faster, and it ends up concatenating all the arguments and it's very, very long. And we are working in my team about trying to detect flaky tests. Wondering this is a different conversation, so we'll maybe, just do a short tangent. But if I told you, I'm worried about having flaky tests in a go code base, please detect them for me. What are your, like, tricks up your sleeve to detect them?
Jonathan Hall:Run the test suite a bunch of times and see what Random
Shay Nehmad:order. Right?
Jonathan Hall:Yeah. Change the order. Yeah.
Shay Nehmad:So that's exactly what we did. And then we found a few tests that had, you know, we have thousands and thousands of tests in the code base. We found a few tests that, like, change the global variable or dependent on a global variable not being changed or use the DB and then clean up after stuff like that. It shared the same IDs, just because, you know, 111111 apparently is a very lucky number for IDs. So we wanted to look at the logs of the CI job that did it.
Shay Nehmad:Right? Because it takes hours and hours because you run them, like, 10 times. So we ran it on CI obviously, not on someone's machine. Then we wanted to look at the logs and it failed because the internal zip file, could truncates the job names and then the GitHub CLI can't find them.
Jonathan Hall:Lovely.
Shay Nehmad:Yeah. And lovely is exactly the this is the class of bug where, like, really? But I we really needed this for work, so I fixed it. And after a long back and forth where, the GitHub team, specifically, William Martin from GitHub, who's actually in Amsterdam. Maybe I'll meet him in the conference.
Jonathan Hall:Who knows? Nice.
Shay Nehmad:You know, asked me to do some testing and do some emojis and and characters, special characters, truncate after, u t f 8, Hebrew, like, whatever. We ended up, merging it like a week ago and the new version of the GitHub CLI, 2.49.1 includes that fix. This is a super minor fix that probably only affects, like, a small amount of people. But it's fun. It's fun to do real open source where you fix a thing that you actually care about.
Shay Nehmad:And, obviously, it was in Go.
Jonathan Hall:And now you can put GitHub on your CV?
Shay Nehmad:For sure. I'm not sure I want that. But but, yeah, I made my first contributions, and it's really fun to see in the auto generated release notes, you know, no new contributors. You see your name. It it feels good.
Shay Nehmad:Since then, they already released a new minor version, but that doesn't include any of, my code, so who cares?
Jonathan Hall:Did they did they fix a bug that you introduced?
Shay Nehmad:No. Okay. Well, then then we're good. We're golden. It remains to be seen.
Shay Nehmad:But actually, they kept me really honest with, implementing a good unit test there. I was pleasantly surprised by their they weren't just like, okay. Whatever. Let's accept it because you tested it manually once. Mhmm.
Shay Nehmad:They really thought about all the edge cases and insisted we add them all to
Jonathan Hall:the test. It works on Shai's machine. That's good enough. Right?
Shay Nehmad:Listen, my machine is cursed, man. If it works on my machine, it's good. My machine is like a fluorescent light. It attracts bugs. Uh-huh.
Shay Nehmad:Yeah. So new version of the GitHub CLI, which is written in Go. And from my experience, if you're looking for some open source work, their team is super super nice and, you know, if you're looking to make a contribution, you have some free time and you use GitHub, this is a really good, project to join.
Jonathan Hall:I'll just add my vote of confidence. I haven't worked on that particular project, but I think working on a commercially backed open source project is a great way to get started. An SDK or something, because they have people who are paid to to respond, you don't gonna just get ghosted by some maintainer who is busy, raising his his 3 year old kids or something.
Shay Nehmad:Mhmm. So, yeah. It's their day job to accept these contributions and it's a more effective way for them to manage a project than just writing all the code themselves. It is better for them by the way, specifically GitHub, of course. Right?
Shay Nehmad:Because now next time I need to pick an, VCS provider, I won't go with GitLab. Right? Because I have an emotional attachment to GitHub. Although, I wouldn't pick up, GitLab anyway. I don't like their interface, but it's been a few years since I used it.
Jonathan Hall:I feel the opposite. I prefer GitLab over GitHub largely because of their interface, but it's alright.
Shay Nehmad:I I I hearken back to, SVN on Windows, file shares. That was the best. No. It wasn't. It was horrible.
Shay Nehmad:It was terrible. Nostalgia glasses. Alright. That's all we have for this week. Something's languishing in the backlog.
Shay Nehmad:For those items, we apologize.
Jonathan Hall:You'll have to stick around till next week.
Shay Nehmad:Wait around to the ad break to hear some cool stuff. Welcome to our ad break. We're gonna make this super quick. You You wanna reach us, you can find us at kapago.dev, that is kapago.dev. One of the links you can find there is our Patreon.
Shay Nehmad:This show is our hobby, but it it is pretty expensive, and we'd like your help covering expenses. So if you are already a member, first of all, thanks a lot.
Jonathan Hall:Thank you.
Shay Nehmad:Financially contributing to the show really just helps us cover for expenses and feel a lot better about doing the show because we know we are willing to pay, to to help us do it, which validates it a lot more than downloads or comments or anything. It's it's an actual contribution to the to the show, which is nice. If you also wanna be a part of that beautiful group, you can find our Patreon link on capago.dev. All the links are there. If you wanna talk to us, especially about meeting us at Amsterdam on, June 19th, because I will be in Amsterdam in June 19th and so will Jonathan.
Shay Nehmad:And it's a perfect storm of gophers. Talk to us on the gopher stack. We have a channel there called Kapago, kebab case with hyphens. Or if you prefer to stay away from Slack, you can email us at news@kapago.dev. If you wanna help with the show in other ways, you can.
Shay Nehmad:You can buy merch. There's some hoodies, some cup, a single wireless charger have been sold in the year and a half we've been doing this show.
Jonathan Hall:And you can share the link with your friends and colleagues.
Shay Nehmad:Yeah. For sure. We don't pay to advertise and we don't want to. But we just want word-of-mouth and people to like the show and talk about it, like, at work. Oh, you know, this podcast, I heard that GitHub CLI is really cool, so let's whatever.
Shay Nehmad:Actually, I now that I think about it, it is possible that the GitHub team will get the link to this episode. Right? I mean, they are Go developers. Mhmm. It it could happen.
Jonathan Hall:Could happen?
Shay Nehmad:So everybody share this episode specifically with GitHub employees. Pester them, wait outside their doorstep, and just give them QR codes with, with the show. Alternatively, if you don't wanna get arrested, you can just, rate us and leave a review on, like, Apple Podcasts and and Spotify, whatever. This helps with discoverability a little bit, and just talk about the show in Go related events or work or university or whatever. That's it.
Shay Nehmad:We're really excited for the physical episode we're planning on 19th. We still don't have a concrete plan. If you wanna help make it happen, specifically if you have a space, a physical space, that would be super helpful. And we'll see you all next week. We don't have an interview for y'all today.
Shay Nehmad:At least one of us will see you next week.
Jonathan Hall:Alright. Awesome. Bye, everyone. Until then.