๐ Iterating through the week's news
This show is sponsored by you. Stick around till after the news to hear more about how you can help sponsor the CapExpo podcast. This is Cup of Go for February 23rd 24. Keep up to date with the important happenings in the Go community in 15 minutes a week or so. I'm Jonathan Hall.
Speaker 2:And I'm Shayne Ahmad. Everybody say congrats. The biggest news of the day.
Speaker 1:Congrats. My sister just gave birth. Yay. A brand new gopher.
Speaker 2:I don't know about that. Maybe by the time she grows up, we won't need programming languages anymore. But anyway, yeah. My sister gave birth. So we're gonna do a quick show and then I'm gonna run off.
Speaker 2:And Jonathan's then gonna do the super interesting interview we have alone. So let's get started. Awesome. I'm hyped.
Speaker 1:I'm hyped. Just to clarify though, the interview is not for this episode. It'll be in a coming episode, because it's later this afternoon. But, so we don't have an interview for you on this show today, but stick around. We do have interviews coming up in the coming weeks.
Speaker 1:So Shai, congratulations to you, to your sister, to your family. If anybody wants congratulate you about that in person, is there any opportunity to do that coming soon?
Speaker 2:Yeah. So you can go to the CapaGo Slack and say congratulations to my sister. She's named Hagar, h a g a r. Just write something nice and I'll show her screenshots. I'm sure she'll appreciate it.
Speaker 2:She doesn't listen to the show. I'll I'll show her the screenshots from the Slack channel.
Speaker 1:Awesome.
Speaker 2:So let's talk about good news. Even though the most exciting news is, my new nephew.
Speaker 1:Yes. Yes. So in exciting good news, if you wanted to to congratulate Shai in person, there's gonna be a meetup coming up in Israel. They're they're getting back on track with their meetups. So March 12 at Orca, where Shai works, you could go say hi to Shai in person, shake his hand, and learn about some Go stuff in person.
Speaker 1:So check that out.
Speaker 2:And there's another meetup if you wanna meet Jonathan, on the flip side, at Creative Fabrica, February 27th. Yeah.
Speaker 1:That's on Tuesday. Coming right up.
Speaker 2:Yeah. Coming right up. Opens at 6:30, then some talks, and then some drinks at a nearby bar. Funnily enough there's a section called what's new in go, which was the original inspiration for the show you're listening to right now and 2 cool talks. There's one lightning talk which I'm like, I don't know.
Speaker 2:And but the talks themselves looks pretty interesting. Combined units and integration testing. That sounds super useful. Like, I would I would listen to that on YouTube if you're recording it. Do you record the meetups?
Speaker 1:We have occasionally, but it's not a regular occurrence. So I wouldn't hold your breath on this one.
Speaker 2:Well, I guess the best option you have is to sign up for the podcast, follow our episodes, and then when the next episode come out, Jonathan will probably tell us how the meetup went.
Speaker 1:I could do that. Yeah.
Speaker 2:No pressure though. We're just happy that you're here. Alright.
Speaker 1:So
Speaker 2:So last episode or 2 episodes ago, we had our big go 122 episode. It came out. Everybody was excited. And I remember when, 121 came out, there were some issues upgrading. And I've gotten some, mixed responses.
Speaker 2:In our channel, on Slack. People have been telling about some issues, upgrading, some crashes, and unfortunately at work as well. So at work we have some, Go back end code and things that relate to there was some data races, new data races introduced, some compiler bugs. We haven't figured out why yet. It's not like something I did something someone else from the team did.
Speaker 2:So I'm letting them figure it out. But yeah, not a smooth rollout so far. I'm wondering if it's just impossible to avoid in every version or like did we do too many changes this time?
Speaker 1:Well you may recall that last, 6 months ago with the last release 121, I had crashes at my work with one of my clients. That was related to the the way that the init order changed of of initializing dependencies.
Speaker 2:Alright. The init thing. Right? Yeah. But you shouldn't have a lot of coding in it anyway.
Speaker 2:So
Speaker 1:It shouldn't, but this particular this particular, project did. But, yeah, I think the lesson here is be cautious when upgrading. Even though Go tries really hard to be stable and backward compatible, it's not always possible.
Speaker 2:I'm wondering if it's best practice to not upgrade until, like, 2 minor versions are out or even be super conservative. Like with Python, for example, at work, which is a lot less stable overall, we don't upgrade to the major version until the next major version comes up. So we really wanna upgrade to 312 because it has some performance, improvements. Nothing next to go. You know what I mean?
Speaker 2:But still, they're trying they're trying to be a real language, or pretend to be 1. But we don't wanna upgrade because it just feels so irresponsible and, you know, all the package management stuff is really difficult. I'm wondering if, at least for enterprise work you'll stay one version behind with Go as well or because of the Go compatibility promise you you actually sort of hamstring yourself because you by the end of the 6 months, you have to upgrade to the next one. Mhmm. What have you seen in your project?
Speaker 1:I've definitely spoken to people who have the policy of only use latest version minus 1 in Go. I think it's most common though with libraries because you wanna support people who who do that, you know. But, yeah, I've never worked on a project that has a firm policy. No. That's not quite true.
Speaker 1:I did work on one project. I can't remember which one it was. I was just there for a short time but they had a I don't remember what was that a major version of minus 1 or if they just waited you know like a month after the release or something like that I think there was more that they had a sort of a security and stability team that vetted every new new version before it was accepted. So, yeah, I think that makes sense in certain, you know, high risk environments. But, you know, it's it's fine if that's appropriate for your business model.
Speaker 2:So what I would say at the very least is that at this point, I think most of the major bugs have been ironed out and if you wait like 2 more weeks, you're probably pretty safe. So if you've been holding off, you should be fine at this point or maybe, like, 2 weeks from now. I hope that, I can report back in 2 weeks that stuff at work has stabilized and it can be even at our code at work which is messy. It works, then it probably works for you as well. It'll be interesting to
Speaker 1:see what's included in 122.1 whenever that drops, which should be soon. Shall we talk about proposals for a little while?
Speaker 2:Yeah. Let's do some proposals. There's one interesting one that got declined about support for encrypted archives.
Speaker 1:Zip archives in particular. Yeah.
Speaker 2:Yeah. So when you zip of a thing, you know, I go back to, like, Winrar or 7 zip or whatever, you can add a password, which is something just useful, you know, if you have to share some sensitive files. I've done it a few dozen like dozens of times in my lifetime, but never in code. I've never had to do it from, like, inside a project. I just used it here and there.
Speaker 2:But someone proposed, you know, adding support. There's archive slash zip libraries, you can go, and they wanted to add support for encrypted archives since it's in the spec. The current implementation doesn't allow, you know, doing it in the standard library. There are ways to do it in Go, which is important. Like, there are libraries.
Speaker 2:It's just a question of how to do it in the standard lib. And it went the way where people agreed that it could be useful, but there's no clear way to do it in the standard library. And basically, there's no ergonomic API, so it's gonna stay out.
Speaker 1:I think it's really informative to talk about this this comment from Russ Cox, where he kind of enumerates the the caveats, the problems with with doing this. Because I mean, when I hear encrypted support for Zip, I'm like, yeah, of course. That sounds useful. Why wouldn't you do it? And How complicated it can be?
Speaker 1:I mean, you need to, provide a password. Right?
Speaker 2:Simple as pie, but not the cake, the number. When you actually learn about how complicated it can be. Because you can have a password for the entire thing. Right? Yeah.
Speaker 2:You can also apparently, you can encrypt only some files in the zip Yeah. Which is weird. I didn't I'm I'm not sure what the use case is, but if the spec supports it, then we need to support it. Right.
Speaker 1:And you can have a different password for each file if you want to. And you can have a separate certificate. I don't know the difference between the certificate and the password in this context, but you can have a different certificate for each file. You can have a different certificate for each file and for the entire archive. So like it's like whoever designed this encryption spec, just gave it too much flexibility or something.
Speaker 1:Maybe it was a reason, but it makes it really difficult to write a clean API to handle this. And then kind of the clincher for me was the fact that it it supports a large variety of encryption algorithms, so we would have to make archive zip depend on all of those, which would make anybody who doesn't care about encryption needs to import a whole bunch of dependencies just to open a zip file.
Speaker 2:And also, if you allow to, like, bring your own encryption instead, the API is gonna get even a lot worse. Right? Because you wanna somehow make sure that people don't mess up and bring, you know, the wrong encryption method next to the header, but without adding the dependency. Anyway, it's basically if you want it you have a library, standard library is not gonna support it. I'm conflicted about it.
Speaker 2:I think it's pragmatic. It's not perfect. So it's hard it's hard for me to swallow this, decline, but overall I think it's a good good decline. Also, I don't use encrypted zip files, at least not that I'm aware of. So, doesn't hurt me personally.
Speaker 2:But still super interesting. We have more proposals to discuss, a whole bunch of them.
Speaker 1:How should we go through these? Should we, like, read them all through once and then go through one at a time? Or should we go through, like, a list
Speaker 2:Just dump them all.
Speaker 1:How should we iterate over this list of of proposals? Nice. So we have a bunch of proposals and and a blog post to talk about iterator support. 2 have been accepted. 2 are likely accept.
Speaker 1:Although, by the time you listen to this, they may be officially accepted because we haven't seen this week's notes yet on the proposal meeting. Iterators. What is an iterator? Maybe we should talk about that first before we talk about these proposals.
Speaker 2:Mhmm. Let's go super basic. You have a bunch of things Yep. And you wanna be able to iterate over them.
Speaker 1:Yeah.
Speaker 2:The keyword in, Go, surprisingly, is not, iter. It's range. Right. Because 4 just didn't have enough jobs. So they were like, okay.
Speaker 2:We need to give you one more job. So if we combine it with range, you do another thing.
Speaker 1:And specifically, this relates to the range over function feature.
Speaker 2:Which is an experimental feature. Remember that. We talk about it a lot as if it's part of the language, but it's still an experiment.
Speaker 1:Yeah. It's experimental. It is available at 122. If you enable it, it most likely will be full on supported at 123. I don't know if that decision has officially been made yet.
Speaker 1:The fact that some of these proposals have been accepted certainly suggests that they're going that direction. So let's talk about the the proposals. We're not gonna talk about the range over funk details. There are other places to talk about that, and we will talk about it more as 123 comes closer. But the idea is you can use a specially defined generic function to to iterate over arbitrary stuff.
Speaker 1:The proposal, the main one, is a new package for iterators called iter or iter. I don't know how you pronounce that. We're really sticklers about pronunciation on the show, so I need to get that right. I don't know what the correct one is.
Speaker 2:I think I don't know what you how you feel about the functions and the types that this package includes. I hate them. Yeah. I hate them. This is a useful package obviously.
Speaker 2:Right? We wanna be able to iterate over stuff, and if we can make it simple, like go likes, that makes sense. And it's super useful in the standard library as well. It's needed for the Rangeover func, and but even if, Rangeover func falls through it will still be useful, right, for a myriad of other uses. But we ended up with an API that looks with the full Go doc that just looks hard to hard to agree with.
Speaker 2:Why don't you tell us about the the functions and the types?
Speaker 1:Yeah. So I don't know which details to pull out. It gives us 2 types, s e q how do you even pronounce this? See, that's the problem. Right?
Speaker 1:Like, I I can't even pronounce this. Seek seq sequence with a generic any type. So it's a generic function. Oh my gosh. I don't know how to read this.
Speaker 2:Let let me try. Let me try. But this is actually a problem. Like, programming is a collaborative activity and not being able to say the things out loud would make it hard to work on it in an office, right? Imagine me trying to ask you hey what do you think about seek 2?
Speaker 2:Like And
Speaker 1:by the way, that that's the worst part of this is is I I hate functions with numbers in them.
Speaker 2:So the types are seek, s e q of a generic type any. It's basically an iterator over sequences of values that are that is generic. You yield the values 1 by 1 and they could be of any type so you could yield a string again and again and iterate over them you could yield an int and iterate them over them again and again and you return true or false as well to know when you're done. Right? So the use case would be you iterate over a a seek and when you get false, you're done iterating over that seek of any type.
Speaker 2:It's any but generic. Right? So it it will be type safe. It's it it won't be a string and then an int. You can expect it to be the same type.
Speaker 2:Just you can reuse the same type. The other type is seek 2, which is an iterator over sequences of pairs of values, like key value pairs. Mhmm. Now that makes sense. Like, what's the use case for seek 2?
Speaker 2:And why don't we have seek 3 or seek 4?
Speaker 1:So I think the use case for seek 2 is is so that they actually mentioned 3 common use cases. Key value, index value, or value error pairs. So I don't think the index value is that common. I mean, I I guess if you're trying to iterate over an array or a slice or something that, you know, they come in order.
Speaker 2:I think it makes sense for the use case that immediately jumped on to me was, messaging queues with an offset. Right? Yeah. So you have an append only log and the first index is not necessarily 1. The index, because it's generated, could be the latest offset you've read from the message queue.
Speaker 2:And then if your service crashes and you pick up from that, offset again, you haven't committed which messages you've read, you range over the index and you get you report back, okay, I'm starting from offset whatever. And then when you range, you see that indeed that's the offset you're getting.
Speaker 1:I just wish they would call it seek kv or something like that instead of seek 2.
Speaker 2:The seek 2 and the function pull and pull 2, it literally looks like a typo to me. Like, I look at it and I'm like, it it doesn't make sense. It's fair. It's within the rules of the language. It's within the style guide.
Speaker 2:It's all good. Just looks. I I don't know how I would've done it better, which I guess is the way to say. It's the best option out of a bunch of bad ones, but, no.
Speaker 1:Anyway, I I am excited for the feature. I I want I have a library, my open source library that I maintain, I think would benefit greatly from this Range Rover funk thing. I'm not excited about the aesthetics of it. I think it's ugly. I think it's gross.
Speaker 1:Maybe it'll grow on me.
Speaker 2:It's important to say that, it's sort of plumbing. Right? It's not the poor stuff. Yeah. Most people won't call seek 2.
Speaker 2:It's kind of internal to do a lot of data types that we would use, which jumps to the next proposal. Right? Adding iterator related functions to maps, which looks a lot better and was accepted and I'm very happy about that where we got 5 new, you know, functions for maps in the maps like package in the standard library, which are super pretty. Right?
Speaker 1:So we have all which allows you to iterate over all key value pairs in a map, as opposed to, just returning them all at once.
Speaker 2:That's exactly where you would see the seek to Yeah. In fact portable Frankenstein type. Right? Because it gives you the key value pairs, but not as a slice, but iterating over them. Right?
Speaker 2:So you can go over 1 by 1.
Speaker 1:Then we have keys and values. These have been requested forever, even before generics existed. You know, people wanted the ability to return all the keys or all the values of a map. That will be possible using the iterator thing now. I'm still not convinced that there's not a case for a non iterator version.
Speaker 1:Like sometimes, I just want a slice of all the keys or values in a map. It's not hard to do manually, which is what happens. You do a for loop and build that yourself, but now you can do it with an iterator. So then we have insert, which allows you to sort of merge maps together, without reading the source map into memory all at once. Reading it in memory isn't the right way say that because it's already in memory, but you don't have to copy it all at once.
Speaker 1:You can copy a key value pair at a time as you insert it into the target.
Speaker 2:And jumping into you know, you said you have keys and values and you want to just get a slice from them. Right? Mhmm. This is sort of there's another proposal that's on the final comment period and looks like it's just gonna get accepted maybe next week, which allows you to do that, which allows you to collect the sequence into a slice of elements. So you could really compose all these functions together kind of beautifully.
Speaker 2:Each one of them on its own looks kind of weird because suddenly you have to work with an iterator or a seek or all these types. But as a whole package, they will work well. Assuming this function gets, you know, the the other proposals will get accepted, which I think it's a very safe assumption to say.
Speaker 1:Yeah. I think they're just earning out the details, really. It's not a question really of will this be accepted, but
Speaker 2:in what form. So if you use keys, values, or, you know, even all on their own, they're gonna be kind of clumsy to work with because we're used to working with map or with, slice. Right? They're useful, easy to use data types for your usual code base and whatever. So you could connect that with the last, API both here and in the slices proposal.
Speaker 2:So both in maps and in slices you'll have collect which I think is the way to say give me your new weird, sequence types and just give me the types I'm used to. Right? These proposals line up pretty nicely to give us a lot of that iterator item by item, message driven, all these sort of, options that were kind of clumsier to implement so far. And generically and stuff like that, it looks looks cool.
Speaker 1:Yep. Just to round out, that thought, there are some proposals to add the same sorts of things to the bytes and strings packages. So you can split a string without having to do it all in the memory at once. You can do, you know, token by token, and things like that. So I think, I think it's good.
Speaker 1:And and as you said early on, a lot of the ugliness is kinda hidden behind the scenes in most cases. Like, you you don't have to care about EIDR seek and EIDR seek 2 when you call strings dot lines. It just is is nice and handy for you.
Speaker 2:Yeah. I think it you might even, like, in I don't know, 2 Go versions from now, you might use, you know, iteration by default and not even realize that you're reading, line by line. And I don't know if they would wanna change the default behavior because it might change the performance of so many existing programs that might be faster by, like, reading the entire thing into memory. And suddenly you're like, okay, let's do it only if the file is, smaller than the average page size of the disk that I'm reading for. It's like you're getting into details that most people wouldn't care about you but you might want to keep things the way they are for most people and then roll out an experiment where you change the default for like a year and then only after that year change the default from 2 to false like do a very progressive delivery on that, right?
Speaker 2:So we might be able to use all this stuff really soon but I think to make it default, it's gonna be a really long time. One last thing, with all this, iteration and ranges and all that, we wanted to mention a blog post that someone sent on the Gopher Slack and I really like. It's a new blog which I'm always happy to to shout out. So Richard Ullmer, rulmer.xyz has a new homepage. And Richard is planning to add more articles related to open source software, UNIX, and life in the command line.
Speaker 2:So no pressure, Richard, but all our listeners are now, making your, website their homepage. But the, you know, the interesting thing here is his blog post about whether range over funk is a good proposal. Right? It's already in the language and it's already a go experiment. But we have seen the Go team, you know, back away from stuff they've worked on for a long time in the past.
Speaker 2:I think the biggest example is telemetry. Right? Community said no and Go team were like, okay. We're not doing it.
Speaker 1:Well, they're doing it but it's it's opt in now instead
Speaker 2:of Yeah. Opt in versus opt out. Yeah. So they might back out. I I think it's a relevant question, you know.
Speaker 2:It's a relevant article and I'll jump to the end. It's short, well written. You can read it. And the conclusion is it's a big trade off. Right?
Speaker 2:We can do the range over, like, split, for example. You can have a string and then split and then range over the results and put it in a library, and if you don't do that then you need to write the thing yourself. And it's useful to have that sort of mentality of keeping things simple. That's the cost. Right?
Speaker 2:You gain you can hide away the ranging over things in a library and do it sort of genetically and only write it once. But the cost is an interface that's really hard to understand. I don't know how you think about it what I think I saw you writing in the channel that reading you know funk split funk funk funk int stringable return funk yield you don't like that. So I I
Speaker 1:don't remember if I if I commented specifically on the yield thing. But, yeah, I I do think that this rendezvous funk is confusing, to read. In fact, that's one of the reasons why I haven't experimented with it yet and I and even when the proposal was first made, I kind of ignored it because I tried to read through it and I was like, this hurts my head. So I think it's a very verbose way to to accomplish the goal. I don't know of an alternative.
Speaker 1:As you said earlier, I don't know of a better alternative given the constraints of the Go language as it stands. And my hope is, although my I'm reserving judgment until I see it more in public or more out in the wild, my hope is that the most ugly offenders will be hidden under the covers. And we can just return an iterator and not worry that it's of type iter dot seek or iter dot seek 2 or whatever, and just pass it to a range and and be done with it at the end of the day. If we can do that, I am in favor of this proposal and and all of the related proposals. But I completely identify with what Richard has said here that this feels like a non Go sort of trade off.
Speaker 1:Like, we're we're we're giving up a lot of simplicity, and we're we're turning to magic. And Go has always been about avoiding magic.
Speaker 2:Yeah. It's you have to complete a generic function that returns a function which accepts a function as a parameter. It's possible, and you know, people from, like, Closure and Scala are probably laughing when they're hearing us complain about it right now. But normal people prefer their programs to be functional without functional programming. I mean, I don't want this, although there is the counterargument which what is better, a functional programming or dysfunctional program.
Speaker 2:Someone, tossed that at me recently. But, again, the the interesting line here is I don't wanna imagine debugging range over func code.
Speaker 1:And I think
Speaker 2:looking at the how the code looks, I agree. It's gonna be Yeah. Hard for me to understand what's going on. Richard doesn't, say don't do it though. The conclusion of his blog post is measure, do it slow, and see if we can still optimize without having a construct as complicated as Range Rover func.
Speaker 2:So I think what he's saying is it's a good first iteration, but it might not be the last iteration, at least not for now Mhmm. For for this, proposal. So lots of, iterator related activity this week. A lot of interesting stuff. So, from around the community, someone at work shared a living off the pipeline, which is a cool little project from Boost Security.
Speaker 2:I'm happy to shout there them out because it's a really cool blog post. So Boost Security, they do DevSecOps automation basically trying to secure your shift left thing. They, collected the list of basically remote code execution by design where you have a command line tooling and whatever just open up your machines specifically CICD pipelines for remote code execution. We've had a few instances of, you know, this supply chain stuff being a security issue in the last years. Right?
Speaker 2:Some of it being political. People, like, changing their libraries to support some political messaging mostly around the Ukraine war. Some of it has just been, you know, like, malicious activity, people installing crypto jackers in your compilers and whatever. And some of it was just trolling, you know, someone, who that that person who installed the everything library on the Node. Js and whatever.
Speaker 2:They list options for different tools that are normally used in CICD pipelines that can be used to achieve arbitrary code execution just by running on untrusted code changes or someone, you know, injecting your workflow maybe with a new version of a library and you upgrade and you didn't realize. And there are many options here. Apparently, Mypy is open for it because it does evaluation of shell. Right? So if you have Python and you have a plugin, that plugin can run OS system.
Speaker 2:And, you know, you didn't write the plugin. You're not in charge of upgrading it. So you just run mypy expecting static analysis of your code. But in reality, you someone is suddenly running code on your machine. The Go angle on this and I was I didn't think about it.
Speaker 2:I was like, Python, sure. JavaScript, yeah. Like, for sure these are open for attack but can you think of an example where you run arbitrary code on your machine when you run go basic GoCI stuff?
Speaker 1:I think I know the answer you want me to say but my answer is no.
Speaker 2:What what's the what's the answer I want you to say? So I
Speaker 1:think you're talking about Go generate.
Speaker 2:That is
Speaker 1:true. But I don't ever run go generate in CI, so it wouldn't affect me. And I don't think anybody ever should.
Speaker 2:Why shouldn't they? You wanna make sure that people ran go generate to make sure that the code is all lined up according to what it says declaratively. Right?
Speaker 1:I guess I lied a little bit. I do run go generate in CI, but only to compare it with the code that's already in in my, repository. Mhmm. So in that sense, I do run go, go generate.
Speaker 2:I totally agree with you that CI shouldn't ever do a commit. I'm also in that camp. But if you wanna check that the generated code is up to date, you have to run go generate. So go generate, if you don't know, it's a comment you can put in the code like, slash slash go generate, which is used to annotate your source code with like stuff that calls generators. I guess the easiest example is you have something that generates your doc site and you want your docs content to be updated, you know, something different other than Go doc.
Speaker 2:Right? You wanna do like some external whatever hugo build. So you add a go generate command that runs hugo build every time you, run go build and then it generates the things for you. It's also useful for just code generators. Right?
Speaker 2:You wanna generate open API. You wanna generate mocks. That's a super super common case. Right? You wanna generate, mocks every time you change the interface and you want the mock to update automatically.
Speaker 2:You don't want to remember having to update the mock interfaces and implementations. This by design has external programs that you call. And if you run it on c I, like, for let's say to comp or even on your machine. Right? And you put a bad command in the comments, then you can shoot yourself in the foot.
Speaker 2:And obviously, that's a problem when you have code from, 3rd party libraries as well. Right?
Speaker 1:Well, I don't think you will be running Go generate on third party code, would you?
Speaker 2:So you might do so by accident. You might go, like, vendor and then go Okay. Generate and you'll be surprised. That that's all I'm saying. But the thing is 3rd party libraries are not usually maintained by one person who has good intentions and that's it.
Speaker 2:Or one, you know, benevolent dictator for life like Guido or or Linus that pour over every single line of the code?
Speaker 1:Did you just call Linus, benevolent?
Speaker 2:That's the that's what the acronym stands for. I don't I don't make the rules. So I could, sneak in, you know, bad code into good code bases. And actually there was research done by people from some university where they, injected code into the Linux kernel and some shitty PRs. The on purpose added security vulnerabilities.
Speaker 2:And then that that was their thesis. So it can happen. Coincidentally, them and the entire, university including staff were barred from contributing to the Linux project forever, which I think is apt. Don't do that. But it is it is possible.
Speaker 2:Right? It is possible that for your database, server implementation. Right? Client implementation, sorry. Someone will add a p r, you're a busy maintainer, you'll be like, sure.
Speaker 2:Yeah. It looks good. Approve. And they snuck in some go generate command into it. And then when your, CI runs and it's an open source project, so maybe you're not looking at the building close enough, They're mining some crypto on every build.
Speaker 2:Yep. So it's interesting. I don't think it's a huge security vulnerability but definitely if you're working at a company that's big enough, it's worth sending this list to your security team or your like application security engineer. For me some things here were really, surprising. And it they cover a lot of languages.
Speaker 2:So it's not only Go, you have JavaScript, you have Groovy, you have Python, you have some config files. Interesting. Interesting stuff. And also some GitHub actions. Apparently, GitHub script, Mega Linter, issue closer, jq, they all have code execution, possibilities within them.
Speaker 2:So interesting stuff. Some security, thoughts to make you worried when you start your weekend.
Speaker 1:Very cool. Well, we have gone well over time. I think we'll cut it here and stick around for the ad break and possibly an interview. We'll we'll discuss that.
Speaker 2:Yeah. Maybe or maybe not an interview. Let's say let's say like this. After the outbreak, you get interview dash, comma error. Check if error is nil, and if so, you can the episode will end.
Speaker 2:And if you keep listening, then that's an exception on your end. Alright. Alright.
Speaker 1:This show is sponsored by you, our listener. If you are not already a member on our Patreon, we would love to have you join. There are links at kapago.dev where you can, become a member of our Patreon. You can support us financially to help cover the cost of production. We're not trying to get rich.
Speaker 1:In fact, we're not getting rich. We just did the math this morning. I literally spent about $2,000 each last year?
Speaker 2:So you spent about $4,000, and I owe you about $2,000. I might have to fly over to Amsterdam and hand you that and, like, unmark the shekels.
Speaker 1:If you wanna say, shy of the embarrassment of trying to travel internationally with unmarked bills, become a member of our Patreon. Also, you can join our chat. We have a pretty active and and growing community on Slack, on the go for Slack at cupogo. That's kebabcasecupdashodashgo. Come join the conversation there.
Speaker 1:Talk to our interviewees. Many of them are there.
Speaker 2:326 people. That's amazing.
Speaker 1:Pretty impressive, isn't it?
Speaker 2:Yeah. And some people decked out in really, really nice swag which you can buy on our shop as well, which we just did the math and it's it's mostly for you. Let's just say it like that. But it's cool. I like it.
Speaker 2:I have my cupago, cup here which has been, faithfully, gone through my dishwasher, like, dozens of times now, and it's still,
Speaker 1:And it's holding up better than this this generic gopher cup I have where the paint is chipping off quality cup ago.
Speaker 2:Yeah. Quality quality cup. And also, some people, dropped selfies of them with a, with a new hoodie Yes. Which I was opinionated about. I don't know if I it's like, reasonable to get one because it's March soon, and it's hot here here in Israel.
Speaker 2:But I might get one just to, like, you know, close out the winter. Still cold here. Yeah. So that's story.capago.dev. And the rest of the links arecapago.dev as well.
Speaker 2:You can find everything there.
Speaker 1:And on the topic of swag, one sort of silly little topic I wanna mention.
Speaker 2:On the topic of swag, that's not, the segue you can take into the super weird thing you're about to say.
Speaker 1:Why is this so weird?
Speaker 2:It is weird. But before you go into before you go into that arts and crafts project, we just wanna shout out the new Patreon members. So, Thomas Gal, that's a nice hack by the way if you wanna get, shouted out twice. 1st join as a free member and only upgrade to a paid member later. So second shout out, Thomas.
Speaker 2:I know you found a vulnerability in our system. Please report an issue, and you'll get your bug bounty on the way out.
Speaker 1:Go generate. Join Patreon.
Speaker 2:That could be can you imagine? Go generate
Speaker 1:That's how we're gonna fund the show.
Speaker 2:Patreon. We figured it out. No, we're not. We're not gonna introduce vulnerabilities on purpose to make money for you. Only We'll do that for fun.
Speaker 2:Lutz Hukenenen, thank you for joining. Fayconame. Fayconame. That was really nice seeing you. I haven't seen you since high school.
Speaker 2:And Carl Scuse. So thanks a lot, Thomas, Lutz, Carl, and Feiko.
Speaker 1:Alright. Weird swag time?
Speaker 2:Yeah. Weird swag time.
Speaker 1:Alright. So during a drunken conversation post Fazdan with some of the listeners and, potential guests on this show. We were talking about, custom Go swag. The person who who ran the the Go dev room had a dress that she had made from custom printed gopher fabric. So we started talking about, could we do that for ourselves?
Speaker 1:And one of the people at our table is wearing a bow tie. And I I wear bow ties occasionally. You wouldn't know that from a podcast, but I wear one
Speaker 2:every episode. I'm decked out in a full, like, suit and tie. It's really business
Speaker 1:sport. This is a black tie show. People don't know that. But it's a black tie show.
Speaker 2:I mean, if you're listening right now in your, like, in your sweatpants, turn off the show. This is a black tie event. You like to leave your your airpods case at the valet at the entrance to the podcast. So, bow tie. Sorry, Dominic.
Speaker 1:Yeah. Yeah. Yeah. So the the the the the question is or the thought is, what if we had some custom printed, Brewster material? So we're thinking about doing that.
Speaker 1:We're not gonna put it on the store because it's gonna kinda probably be a one off thing. I think I will probably try to get some Brewster printed silk material and make myself a bow tie. But maybe somebody wants to make a shirt or a a beanie or, I don't know, whatever sorts of things you might wanna make with some gopher material, with Brewster on it. If that's something that interests you and you wanna get in, we're gonna probably do a bulk order one time sort of thing. I'll have it shipped to my house, and then I'll chop off the yard as you request and send it to you.
Speaker 1:If that's interesting to you, come to the Slack channel, ping me. We'll start a conversation. We'll see if there's maybe 2 or 3 people interested in getting some Brewster material, and we'll we'll make an order. Cool. That's the weird swag announcement.
Speaker 2:I am not much of a bow tie guy. But if you actually manage to put your hands on fabric that includes the gopher the Brewster, I'll put that on, for the next, gopher meetup. There we go. Send you a selfie. Alright.
Speaker 2:Thanks a lot for listening. And, for some, I'm enabling, John to, like, plan an arts and craft project of creating his own custom bow ties for his own custom podcast that sounds reasonable yeah I do software engineering what are you doing today yeah Yeah. I'm doing, bow ties with a cute, gopher on them.
Speaker 1:Yeah. Why not? Why not?
Speaker 2:Yeah. Why not? Thanks a lot for listening everyone. See you next week.
Speaker 1:Until next time.
Creators and Guests
