🤌 The Gopherfather: Go 1.25, slog multihandlers, and more, capisce?
This show is supported by you, our listener. Stick around to live for the news to hear more about that. This is Cup A Go for July 11 or 12/2025. Keep up to date with your
Speaker 2:flat circle.
Speaker 1:This is Cup of Go for 07/12/2025. Keep up to date with the important happenings in the Go community in about fifteen minutes per week. I'm Jonathan Hall.
Speaker 2:And I'm gonna make you an offer you can't refuse on the show Cup of Go.
Speaker 1:What did you do with my cohost?
Speaker 2:You went sleeping together with all the YAML proposals. Don't worry about it. So anyway, this week, I wanna tell you about the linter. You're killing me, Ma. You're killing me with all the linter.
Speaker 2:We've decided that my mobster impression is better than Jonathan's.
Speaker 1:Yeah. Is not same words.
Speaker 2:In two weeks, he'll do the show as a as a mobster, we'll see how it goes. We'll see. Doing, Jonathan?
Speaker 1:I am alright. Getting ready to go on vacation.
Speaker 2:We have a lot of, topics to cover. We sure do. Again, our back news backlog is becoming longer than our news this week column, which is always a bad sign.
Speaker 1:It it feels like the Go team is back in proposal zone and kicking out new interesting proposals, so we have things to talk about in that regard. We have new releases to talk about.
Speaker 2:Yeah. We have some conferences to mention, but let's start with the new security release. So there's one point twenty four point five and one point twenty three point eleven, like a minor point release, which is fixing unexpected command execution in untrusted, like repos. So some usage of the Go tool chain may cause, you know, unexpected commands. Like, it's just because how Go tries to figure out which version control system is being used.
Speaker 2:So you embed the build information. So if you're using, Mercurial or Git, you know, like if you have multiple configurations, it might lead to unexpected behaviors and even unexpected commands. It's a pretty cool, like, little vulnerability. It's just that our last show was super focused on vulnerabilities. So I'll just say you should probably upgrade.
Speaker 1:But to be clear, if I understand this, this really is very niche. Like, it only happens if you have, say, a Git repository with a .hg directory or a Mercurial repository with a .git directory or something like that, right?
Speaker 2:Yes. But I think it's the sort of thing that people could very easily try to introduce into an open source library that people clone and you wouldn't notice. I think that's the vector
Speaker 1:people Certainly, are it could happen if you've migrated from one VCS to another and forgot to clean up the old metadata or something like that. Yeah. Yeah. So it's a niche case. It shouldn't affect most people.
Speaker 1:But like like you said, somebody could intentionally try to introduce one of these directories. So, yeah, upgrade.
Speaker 2:I just wanna shout out Ryutak, the 21 year old security researcher with the beautiful pink, like, you know, rainbow colored pastel site and the cute emoji, you know, with a ton of, hits on HackerOne and a blog and whatever, like the most hardcore, you know, security research together with the most like anime, Kawaii, the sort of site that's literally written in Comic Sans or something. I love that. I love the security community sometimes. So anyway, now the tool chain will not do that anymore. So it's an easy upgrade.
Speaker 2:It doesn't it literally will not impact your program. So it's a no brainer to upgrade this time because it has zero risk for, you know, changing, like, how your program behaves or anything because it's actually in the tool chain, not the program. So go upgrade.
Speaker 1:And related to that, 1.25 RC two has been released with the same security fix, and I don't see it mentioned that any other changes have been made since RC one, likely have been a few others. So if you're testing the latest one twenty five RC, just update the version two, RC two, and start running your CI pipelines on that one.
Speaker 2:RC two is normally the last one or is there like, are we expecting more?
Speaker 1:I don't know if we could say should say we're expecting more, but I think the whole idea of an RC is that they expect that to be the last one or at least potentially could be the last one if they don't find any issues. So, yeah, within about two or three weeks, we'll know because the final version or whatever it is, whichever the RC is at that moment will be tagged as the final one and released. It has been a while since we've talked about conferences. I just hopped over to the Go Wiki somebody's updated a bunch of conferences there. So we're gonna talk about the the next upcoming one, South Africa, GopherCon South Africa.
Speaker 1:This is the first GopherCon South Africa. It is also online. So even if you're not physically in South Africa, you can still attend virtually August. Got a list of speakers up on the website, including Dave Cheney and Alex Rios and a number of others. Great gophers gonna be teaching us all about Go.
Speaker 1:So check out GopherCon South Africa, August. And on the next episode, we'll talk about some other upcoming conferences further in the future.
Speaker 2:And if you have like more conferences or meetups you're setting up, let us know on the channel. We've actually had an interesting discussion about how people come, like learn about the show and how do they get to us because we don't like do advertising or anything like that. Right, Jonathan? And one of the people on the channel was like, oh, I heard about it in some conference. So it's just fair for us to, like, if you're arranging your first meetup or in your local whatever community, just let us know and we'll try to push it.
Speaker 1:Yeah, absolutely.
Speaker 2:And I think we I think we do have, you know, that's a whole different discussion, probably enough for for the show, but it was interesting to learn how people, like, funnel into our show because I'm still amazed we have so many, like, subscribers and people that actually listen to this.
Speaker 1:We're up to five eighty on the channel now, it's pretty amazing.
Speaker 2:Goddamn. One thing that happened yesterday, I was working with one of the parents from my kid's kindergarten. She's like a brand marketing person and she's Chinese and she's like working with advertising marketing in China. So I checked our analytics and I think like it's unrepresentative how few listeners we have in China versus how many people there are in China. I think we should have more Chinese listeners.
Speaker 2:So maybe we'll just like utilize her to
Speaker 1:get more people in China.
Speaker 2:All that is a long winded way to say we're gonna do a whole conference roundup like in two weeks. So if you have a conference you want us to mention, just let us know because we're mostly relying on social media channels and the GoWiki to find these. But that usually misses like the smaller ones, the local ones, which are usually the best honestly.
Speaker 1:Yep. Cool.
Speaker 2:There's one blog post that I'm afraid of talking about. Uh-oh. Well, let's just preface it by saying I'm pretty dumb. Is that a fair estimation?
Speaker 1:Don't think you're dumb.
Speaker 2:Well, I'm not smart enough to be working on code that requires generic interfaces, but that's what this blog post is about and it's very So we're gonna mention it. Honestly, I think, know, kidding aside, there are some people who who and I have had that happen to me in my career, that you get into some point where you write like a really generic or or really core piece of functionality or like a library or a template that's like super relevant to a ton of people. You know what I mean? Where you're building like the first template or the cornerstone of like a big system. You know what I'm talking about?
Speaker 2:That feeling? But that's not most of my day to day. Like most of my day to day is not very abstract. It's very concrete. Like I wanna do a business thing.
Speaker 2:I wanna connect this API to this thing and run it through that, transformations very specifically without anything very generic. And most of the, like, abstract, the generic stuff is handled by libraries for me, which is why I had a hard time understanding what the Generic Interfaces blog post was all about. Because honestly, I barely even use generics in Go. So, like, you can do more things with it. And I'm like, really?
Speaker 2:Cool. But I read it and I think it's interesting. And, you know, even if you don't even if you're like me and Jonathan, you said you're like this as well, right? Most of the code you write ends up just being concrete?
Speaker 1:Mostly. Yeah.
Speaker 2:So you're not, like, grabbing, generics on a daily basis or even a weekly basis?
Speaker 1:Use generics sparingly, you know, usually for little utility functions, the kind of things that would that might exist in the slices package or the maps package, but just don't for various reasons, legitimate or otherwise. You know, I want to convert, a slice of ints to or a slice of this to a slice of that or something like that. You know, I have a lot of little utility functions that use generics. I try to limit my generics in most other cases.
Speaker 2:It's funny that you say you should you're trying to limit your generics because actually, this is what this blog post is all about. Yeah. Because because an interface in Go is a type, it can have type parameters. Meaning, you can have an interface, that is generic. Right?
Speaker 2:So you could say type and the example I've managed to come up with that is concrete enough like a tree because whatever. I I will never implement a tree, right? So what's the point? You want to define an interface and you want it to have a function that returns a thing, and that thing could be of like any type, right? So you define your interface, and then the interesting part is that you can use, that interface in another interface, pass the generic into it.
Speaker 1:Yo, dog, I heard you like interfaces, so I gave you generic interfaces, so could use interfaces in your interfaces.
Speaker 2:Yeah, I lost you. I lost you. So here's an example. Let's say I'm implementing a backend, right?
Speaker 1:I'm implementing a backend.
Speaker 2:Like a normal CRUD repo pattern. Yeah. I want to define a repository, right? But I'm like, all of my things, you know, like my user and my post and my product and my order, they're all just CRUD. I can create, get, delete them.
Speaker 2:So I don't need, like, the you know what I mean? I don't need to implement the repository interface differently for user and post and product and order. Right? I could just define it as a generic interface that gets any. But that's not a 100% correct because I do have some constraints on it.
Speaker 2:Like the ID needs to be an identifiable and it needs to implement get ID, and it needs to be comparable, right, because I'm I'm getting it, etcetera, etcetera. So what you could do is you can define an interface called identifiable, which returns an ID. And then define another interface called repository, which has an ID that is comparable, which is a thing you can say about the type interface, about a generic type in Go. You could say, okay, this is not just any type, this type has to be comparable. So you constrain it, and then you say, oh, and the item is an identifiable item that gets the ID.
Speaker 2:So you have a generic interface that is self referential. The use of it is basically you get compile time safety. Like if your type doesn't implement get ID, it fails during build and zero boilerplate. Like the handler, you'll implement it once and then reuse it. And also there's no overhead of like interface boxing, like overhead with function pointers.
Speaker 2:And, you know, I think some people would say this is like very readable. To me, it screams the C plus plus templating, oh my God, I can't read this, I'm afraid, I don't understand. But honestly, after looking at it at it like two or three times, it does make a lot of sense. And again, it gives you the compile time safety, so that's great. I'll jump to the end of the blog post because there's a few more features here to look at and how to implement it and what do you do if you don't constrain it and point to receivers, blah, blah, Like, if you want to express constraints on receivers self referentially, can use generic interfaces, but the blog post ends with, do not overengineer things.
Speaker 2:A less flexible, but simpler and more readable solution may ultimately be the wiser choice. And like, oh my God, that is so right. Like, would much rather just implement the CRUD three times or like 16 times than have to deal with this generic stuff. Unless it's a hard requirement, like, because you're implementing a library, right, and you literally don't know what will go on, I don't like, I wouldn't use it. I I can't see myself reaching for it unless absolutely required functionally just because it's so hard to read.
Speaker 2:I don't know if I'm like, I'm in the minority here. Like, would you reach for generics if it reduces three concrete implementations into one handler?
Speaker 1:I might. It depends on how complicated that is.
Speaker 2:Depends on your mood?
Speaker 1:Perhaps. Mostly depends, I think, on, yeah, on on the trade offs. I mean, three is kind of borderline. If it was 12, very likely I would switch. Yeah.
Speaker 1:The blog
Speaker 2:post has, many more details, and it's really well written and has code examples and everything. So if you're interested, I suggest you go read it and don't just trust my understanding of it. Blog post by Axel Wagner. So thanks a lot, Axel. And you said that the Go team is back in proposal land.
Speaker 1:Yes. They have come up with a bunch of new proposals and two in particular I wanna talk about. Let's save those until after a short break. As I said at the top of the show, the show is supported by you, our listener. Thank you to all of our Patreons who contribute financially to supporting the show.
Speaker 1:Your contribution helps pay for hosting and mostly for editing of the show. We do have a professional editor who does a great job of making us sound a lot smarter than we really are.
Speaker 2:As you heard at the top of the show, he is very required.
Speaker 1:But you can also support the show just by sharing it with friends, with colleagues, with worker coworkers and co students. As Shai mentioned earlier in the show, we just had a thread this last week about how people found the show at conferences and a bunch of people are joining the channel. I think we had three or four joined just recently. So yeah, if you're new to the show, share share it with a friend. If you're if you've been a long time listener, share it with a new friend.
Speaker 1:We love the word-of-mouth because we don't pay to advertise.
Speaker 2:We love the word-of-mouth because, it's great and not because it's free. Just like to to clarify that last sentence.
Speaker 1:I mean, we would pay you for word-of-mouth if we could do it without biasing your word-of-mouth and and if we had money.
Speaker 2:You know what? Honestly, if someone shits on the show, I still prefer I still prefer it to to them not not telling anything. Like, these two bozos, they're talking about generic interfaces and they don't know anything about it at all.
Speaker 1:Somebody's probably saying that under their breath. I hope they tell us.
Speaker 2:You know what? It's probably the same, like, 3% that, use Go and respond to the Go survey and they're like, I'm unhappy with Go. It's the same like devout listeners of the show that think we're bozos.
Speaker 1:I don't know. Honestly, I don't think I would listen to the show. I think I would think our chatter is silly, but I don't listen to same sorts of podcasts I participate in. So I know I'm probably a weird person like that.
Speaker 2:What do you mean it's a silly? No, I'm just kidding. So, yeah, support us on Patreon. That's the most direct way to support the show. And if you want to spread the word, then word-of-mouth is the best way, but also leaving a review on Spotify, Apple Podcasts, or just wherever you listen to your podcasts might help some algorithms and AI, whatever, pick us up and get to people like that way through their feeds and not necessarily from one another.
Speaker 1:The other way to spread the word is to go buy a bunch of our swag. So you're carrying a gopher, a brewster or a cup of coffee mug around everywhere at work or wearing the t shirt or the hoodie. Every time you go out, the people are gonna be asking you, who's that cute gopher on your shirt? And you can tell them all about the podcast.
Speaker 2:Yes. And you can find the store at cupago.dev. It's actually store.cupago.dev, but, like, whatever. All the links are in cupago.dev, including links to our Slack channel we've mentioned, hashtag cupago in the gopher, Slack, the gopher workspace. And finally, you can email us at news@cupago.dev.
Speaker 2:That is news@cupago.dev.
Speaker 1:Send me email, please. I'm tired of all the spam I get about, oh my gosh, you only have a 115 episodes? Or you only have three listeners on YouTube or whatever stupid spam crap I get. I want some real email from at the mail address, so please
Speaker 2:The email spam is certainly kicking up lately. Definitely. I keep getting these, like, AI generated emails like, oh, you're hiring for your company. Do you need help recruiting? Blah blah blah blah blah.
Speaker 2:I'm so excited by your mission of yeah. Yeah. Whatever. Quick programming note, next week, it's summer, summer vibes, baby. Next week, both of us are traveling and we decided not to try to shove an episode into a super busy week schedule.
Speaker 2:So we're taking a week off.
Speaker 1:Yes. A week off. I'll be busy fishing in Branson. If you happen to be in Branson and wanna hit me up for a a pint or a coffee, let me know. But otherwise, I'm planning just to be sitting on the docks fishing and swimming and whatever else in Bransonville.
Speaker 2:I'll be camping in Lassen Volcanic National Park. I got my America The Beautiful National Park pass, and I'm itching to use it.
Speaker 1:Awesome.
Speaker 2:So no episode next week. Just take a week off. Go team. Just, like, go work on Rust or something. Like, give us a week to catch
Speaker 1:up. To hold you over until then, we do have a little bit more news for you, so let's get to it.
Speaker 2:Yeah. But if you if you really need your fix, just, pause the episode now and start it again next week.
Speaker 1:So the first proposal I want to talk about is a proposal for the LogSlog package, which we all know and love. This is to add multiple handler support for the logger. So if you've used this package, you probably know that you get to pass in a single logger logger handler that is. And if you want to do more than one, you have to use a third party package. There are one or two popular ones out there.
Speaker 1:The one I usually use is from Samber, github.com/samber samber/slog-multi. The big open question on the proposal is why not just use the third party package? Why does should this be part of the standard library? There's
Speaker 2:Why a X list and STD Lib is a thing that the Go team loves to reference when people suggest stuff. I remember it from when they burned my YAML proposal, which is like, you need a good reason to put stuff in the standard library because it basically means that the Go team will have to maintain that piece of code forever. So it's a legitimate question. Why
Speaker 1:do we
Speaker 2:need this if there is a third party library?
Speaker 1:And there are some back and forth here. Most of the emoji voting seems to be in favor of adding it to the standard library. Not that that's gonna sway the team. My personal opinion, and I may add this as a comment on here, my personal opinion is I think this should be part of the center library because I want rock solid code I can trust doing this for me. And I have written enough handlers, like three or four.
Speaker 1:I know it's a real pain in the rear end to get it right. And I don't even know if I got it right. I don't know if this third party got it right because there's, like, memory utilization concerns. There's you know, you wanna make sure things are called in the right order. Writing a handler for SLOG is not an easy task to if you wanna make sure that it's memory efficient, and so on.
Speaker 1:So I would love for this to be part of the standard library just so that I don't have to worry about whether or not this third party I chose is solid code or has security vulnerabilities. And I certainly don't want to write it myself for every application because I need this in virtually every application I use.
Speaker 2:Wait. Those are my have multi handler in every project you why are you writing to the console and to a file or something?
Speaker 1:I almost always log to my regular log, and then I almost always log to Sentry IO also for errors.
Speaker 2:Sentry is good.
Speaker 1:Sometimes to third or fourth party logs, sometimes to the console and to, you know, a third party logging application or something. And further on that topic, Sentry just released a couple weeks ago a new version of their Go SDK that includes a logger handler in it. So there's even less I I I'd written my own Sentry log handler before. I intend to retire that now and use theirs. But, yeah, I use this in virtually every application I use.
Speaker 1:I I use the very package he mentions, but it makes me nervous every time I do it because I have, you know, I have less trust for some random third party library than I do the standard library.
Speaker 2:And here's a question. If you have a multi logger, is it happening, like, one at a time?
Speaker 1:That's a good question. And that's one of the questions I don't know about Or the one
Speaker 2:of them fails, like Yeah. When you have one handler, you don't have to worry about all this stuff, but I would like, if you it's very unclear how it would happen. I mean, I guess I guess the best solution is for the normal, implementation to be the simplest. And then if you do want it to be concurrent, you you use a a third party library. Right?
Speaker 2:Or something like that.
Speaker 1:I think I would probably handle them by default. I would handle them in parallel, probably.
Speaker 2:In parallel by default?
Speaker 1:No, no, no, no. In series? In would
Speaker 2:be One in at a
Speaker 1:time. Yeah. Because I would already expect my logger to be as lightweight as possible. And if it's going to be blocking, I would expect it to do that in the background already. If it's going to take it five hundred milliseconds to send something over the network or something, I don't want it blocking my application to do that if possible.
Speaker 1:I'd hope it would have a buffer in place and, you know, build up a buffer and flush it every now and then, which most loggers do anyway, the fancy ones.
Speaker 2:That's super interesting. I also use a multi logger, mostly for development, actually. Like in production, I have Sentry instrument instrument my thing normally, but in production, I have super verbose logs written to my console while I'm working, right? Because that's the entire point of debug logs, like when I'm running But I'll also writing the real logs, like info level and up to a file in JSON format. I make sure like all my logging is actually correct.
Speaker 2:So I have a JSON file, like a rotating five megabyte file locally to make sure that the output is as I would expect to see it, like in whatever is consuming my logs. Unfortunately, it's a bad, like, cloud log service right now. I will not name them. It's super shitty.
Speaker 1:So it's not Spark, Spark Logs?
Speaker 2:No. It's not. It's not Spark Logs.
Speaker 1:That would solve all your problems, of course.
Speaker 2:No. No. It's a big one. And, yeah, like, having that multi logger in the standard library would would make that again, like like a lot of things, it would make it easier, but if they were to reject it, I would be like, Ah, you know how it is, go team, they wanna keep the implementation stable. I would accept it either way.
Speaker 2:But scrolling through the proposal here, it seems like it's, like, active, it seems like it's going, you know, seems like it's going, trending towards positive. Yeah. If you have a specific use case, pretty smart to jump on the thread here and and put it in. Right? And finally, like, Filippo Valsorta, which we hosted on the show.
Speaker 2:Right?
Speaker 1:Yeah. Been a little while, but, yeah, thanks for coming on, Filippo.
Speaker 3:So I'm Filippo Valsorta. I've been maintaining the Go Cryptography Standard Library since 02/2018. I've done that first at Google as the lead of the Go security team, and these days, I'm doing it as a independent open source maintainer.
Speaker 2:So, anyway, he commented here with, like, his multi handler implementation that he wrote. And he says like, I copied this to do three different projects, which are all the projects that have adopted S Log, so please give me this in the standard library.
Speaker 1:Yeah. And I think that's a great example. Like, it's not a lot of code. It's what, two dozen lines maybe, maybe three dozen at most. So it's not like we're asking the standard library or the Go team to take on a huge burden, but I would just rest easier knowing that this has been handled in the best way.
Speaker 2:Honestly, standard library contributions have a Goldilocks problem, where if it's too small, if it's like a three three lines of code, they'll be like, just copy it, right? It's better than dependencies. And if it's too big of a change, like Introduce Yama, they're like, it shouldn't be in the standard library. So it's a Goldilocks problem where it has to be a feature that's like, you know, just right. Anyway, that's a cool proposal.
Speaker 2:I I like it. Interesting.
Speaker 1:Next up, here's a proposal from an obscure gopher named Rob Piquet. Oh, no. Pike. Rob Pike. I actually
Speaker 2:Like the blanket type. You know that blanket that has squares on it, Pike blanket? Then you go to sleep on it and you wake up. You, like, fall asleep on the couch. You wake up.
Speaker 2:Your whole face looks like a waffle.
Speaker 1:Wow. Yeah. So I love this proposal. I hope it makes it in. This proposal was proposed in 2021.
Speaker 1:It's been sitting around a while, but it just moved into the active column for the meetings notes. So that means the Go team is actually looking at it to decide if they want to implement it. What's the proposal? Add an expression to create pointers to simple types. Here's the pre this is the the whole proposal is worth reading.
Speaker 1:It's it's fairly long and detailed. He actually he's actually proposing two specific things. He's proposing we do both of them. Let me read the preamble though. As you probably know, it's easy to create a pointer to a struct.
Speaker 1:You do ampersand, struct name, and then your little curly braces or whatever the contents of the struct is, right? And the result is a pointer to the struct. It's interestingly and perhaps ironically very difficult to get a pointer to a simple type like an integer. You can't do ampersand three or ampersand int paren three at all. Now ampersand three is problematic because we don't know the type, but even if you put the int in there, it's still not possible to do that.
Speaker 1:So he's proposing it would make that possible. And he gives two different ways that would both kind of independently solve the same problem, but you could also sort of and he's proposing we do both with the with the with understanding that maybe during discussion we decide that one or one of them is better than the other and we should only do one or not the other or whatever. However, all of that said, my favorite comment in the whole proposal is part of the template. The template asks this question, would you consider yourself a novice, intermediate, or experienced Go programmer? And Mr.
Speaker 1:Rob Pike replies, I have some experience. I've heard of it. For those of you listening who don't know who Rob Pike is, he is one of the co creators of Go. So yes, he does have some experience. There's literally only one or two other people on the planet who could possibly have more experience than him or more likely tied for the amount of experience that he has.
Speaker 1:So anyway, I would love this proposal to be accepted in either form or both forms. I'm not going to go to the details of those because it's fairly detailed, but just read the proposal. The TLDR, it would be possible to do ampersand int curly brace three close curly brace and get a direct pointer to an integer or a string or a boolean or any other basic type. If either of these co proposals are accepted, I really hope that makes it into Go 1.26. That would make that my favorite Go version for a while.
Speaker 2:Actually filling the template here is like, yeah, the question about experience is pretty funny, but I just read through the entire, his like answers of the template and it definitely feels like, you know, you remember that scene in Hitchhiker's Galaxy where he needs to fill out the form? He's in the Vogon's ship and he needs to fill out the form. And there's like this lady at the count the alien lady at the counter is like, oh, you have to get the blue for have a vague, like, they're standing in line like, oh, I'm an Englishman, that was made for queuing. Like this very cynical it's like, what other languages do you have experience with? And it's like Fortran, C, Fourth, Basic, C, C plus plus Java, Python, and probably more, just not JavaScript.
Speaker 2:Is this change backward compatible? Yes, don't worry. That's like a good Yeah. Wow. Good good answers.
Speaker 2:How would the language spec change? Answer it above. Why is this question here twice? How would we measure it? Eyeballing.
Speaker 2:It's just like the dead ban, responses are pretty great.
Speaker 1:I don't know, that makes me feel a little bit better about when I fill out one of these forms and I feel like the questions are kind of ridiculous or don't apply. Apparently, I'm not the only one and I didn't even create the language.
Speaker 2:Yeah. Yeah. I mean, I just had to fill out all the visa forms just a few months ago and that was the craziest form I've ever had to fill. You like have to fill out countries. My wife is from Ukraine and they won't accept like Ukraine.
Speaker 2:You have to fill out, okay, she was part of the Soviet Union from this year to this year and then the Soviet Union crashed, so she changed. Like, do you have any documents like to prove that that happened? Like to prove that the Soviet Union like crashed? I gotta have the papers. Back to the content of the proposals though, not just the forum.
Speaker 2:Although Rob, it's pretty funny. Good work. Why would I need the pointer to a const, like simple type?
Speaker 1:Don't you ever need that? I need it all the freaking time.
Speaker 2:Just to, like, pass the number three into a function and things like that?
Speaker 1:Oh, or a pointer to three or a pointer to
Speaker 2:the Yeah. Mean, to pass a pointer to the number three to a function.
Speaker 1:Yeah. I mean yeah.
Speaker 2:No. But I mean, like, you can you can do it. Right? You put it in a variable and then you
Speaker 1:put a reference to variable. It's two steps. Yeah.
Speaker 2:I mean, yeah. It's two steps, but it's not like you have the variable and then you have the pointer. It's not like two steps to get one thing. You know what I mean?
Speaker 1:What? Yeah. It's two steps to get one thing.
Speaker 2:I mean, you use the pointer, but you create a value and then you
Speaker 1:And then you point
Speaker 2:to point to the value. I mean, it's
Speaker 1:you okay. Don't have to do that for composite types like like structs.
Speaker 2:Yes. That's true. But I just don't feel like I'm I'm not saying this is a bad proposal. I just feel like this is such a non problem in the sense that, yeah, it's like an it's a small thing that's not the most elegant.
Speaker 1:Don't know.
Speaker 2:It's like friend of a friend. Like, I I feel like, okay, if we're looking at ugly things in the language that people try to use and are complicated, why not fix like the time format or the things that people actually complain about?
Speaker 1:People complain about this all the time, man. I complain about all the time. I I I have
Speaker 2:about Go every week for a few for, like, two and a half years, and I've never heard you mention it.
Speaker 1:But Go
Speaker 2:listen to the entire archive right now.
Speaker 1:I have I'm sure I've mentioned it before. I've mentioned it in my 10 things I hate about Go video. I know that.
Speaker 2:Oh, maybe you leave all that energy to the to the the the, like, videos and LinkedIn comments, and then I only get the positive, Jonathan. Maybe so. Cool. Cool. Cool.
Speaker 2:So is this, like, happening? Is this, like what what's the state?
Speaker 1:It's it's the status is added to minutes. So that means it's recently come to their to the top of their stack of of things to consider. I imagine over the next few weeks, we'll start to see more comments about this, hopefully from our listeners who either agree with me or agree with you that it's either really important thing to add or it's not important at all. But, yeah, go leave a comment on the proposal. And then, yeah, I don't know.
Speaker 1:Within a few weeks, we might start to see whether it's likely accept or likely decline.
Speaker 2:Yeah. I'm not I'm not against it. I was just saying it's not hugely important.
Speaker 1:I think that's it for the news. I have one lightning round item, so let's play that music.
Speaker 2:Lightning round.
Speaker 1:Alright. On the lightning round, I think it was two episodes ago when Jeremy was here. He mentioned Fang from Charmbracelet, the new tool to make COBRA applications more colorful and exciting and everything. And I mentioned in the commentary of that episode that I think it's cool, but I wish it would work for other CLI libraries as well because I feel like COBRA is kind of non idiomatic in some ways. Without trying to disparage the author, he just wrote this long before Go's idioms had been established.
Speaker 1:A simple example would be context handling. COBRA existed before the context package did, so obviously it didn't support context handling. And that's been sort of bolted on, but in a slightly awkward way for backward compatibility reasons. So the question came up in our Slack channel, if I don't like Cobra, what do I like instead? And so I want to call out the library urfavecli, U R F A V E.
Speaker 1:It's on GitHub, of course. Github.com/irfave/cli. They have a version three, which came out a few months ago, I think, and has is an improvement over the v two API. I haven't used this enough to say positively that I think it's better in all ways than than Cobra, but it is more modern. So that's one to check out.
Speaker 1:If you're also a little bit frustrated with how Cobra works, maybe you'll check out Perfaze slash CLI.
Speaker 2:Is that the sort of thing where you're still, let's use a library for it and not just a standard lib if you need to implement the CLI?
Speaker 1:Yeah. So maybe it's worth talking a little bit about what these libraries do. They because I feel like there was some confusion about that on the channel as well. They they kind of it's kind of like a web framework for CLIs. So it it ties in flag manipulation, reading configuration variables from a file, and then executing commands and subcommands.
Speaker 1:And so, like, if you have a command, I don't know, like, Kubernetes or something and you type kubectl space and then, I don't know, apply or whatever
Speaker 2:you huddle? Yeah. Stop. It's cube cube c t l.
Speaker 1:Yeah. It's cube cuddle.
Speaker 2:Oh my god. I'm learning a lot about you this episode, John.
Speaker 1:So anyway, the point is, like, each subcommand can have its own help section and all that stuff, right, to arbitrary levels and then and they could each subcommand can have its own flags. So it it helps to orchestrate all this stuff together. So it's more than simply just parsing mainline arguments in your preferred way or whatever, which some of the discussion on the channel was about. It certainly relates to that, but it's much, much more than that as well. So if you're looking for a full fledged CLI library, this is one to consider.
Speaker 1:If you just want a really simple CLI with flags, just use your own flags and you don't need a library for this. I think that wraps it up.
Speaker 2:That's a show.
Speaker 1:I'm going fishing.
Speaker 2:We're going fishing or we're going camping. So no show next week. Enjoy your break from us, and program exited.
Speaker 1:Program exited. Goodbye.
Creators and Guests
