1 00:00:00,001 --> 00:00:02,000 We should start a podcast. 2 00:00:02,000 --> 00:00:06,560 Let's get going. Do you want to start with the Python metadata stuff? 3 00:00:06,560 --> 00:00:14,800 Yeah, sure. So I saw a blog post this week. In fact, it was passed to me by Peter Steinberger, 4 00:00:14,800 --> 00:00:25,280 who passed over this blog post from Armin Ronacher, and he thought I might be interested in it. 5 00:00:27,280 --> 00:00:34,640 And it's called Constraints are Good, Python's Metadata Dilemma. And it's basically a post 6 00:00:34,640 --> 00:00:42,160 about a situation that they have in the Python package and dependency ecosystem at the moment, 7 00:00:42,160 --> 00:00:48,240 where you can have this thing in Python. I haven't really used Python. I've done a tiny 8 00:00:48,240 --> 00:00:53,360 little bit in Python, but nothing worth mentioning. And I wouldn't say that I know 9 00:00:53,360 --> 00:00:58,000 the language or certainly don't know the dependency ecosystem very well in Python. 10 00:00:58,000 --> 00:01:03,280 I believe, Sven, you have done more Python than me, right? 11 00:01:03,280 --> 00:01:05,200 I've used it a fair bit, yeah. 12 00:01:05,200 --> 00:01:09,680 Yeah, so maybe you can guide me through this. So basically, the dynamic metadata is 13 00:01:09,680 --> 00:01:16,880 in the kind of dependency manifest for a Python package. You can execute effectively arbitrary 14 00:01:16,880 --> 00:01:25,680 code. And that is now causing a few problems, a very slow dependency resolution, and 15 00:01:25,680 --> 00:01:31,680 difficulty with cache invalidation, fragmented metadata storage. I'm reading some of the bullet 16 00:01:31,680 --> 00:01:40,880 points here from the list of issues in the blog post. And so first of all, correct me on anything 17 00:01:40,880 --> 00:01:42,000 that I've said that's wrong there. 18 00:01:43,600 --> 00:01:52,160 I'd be struggling because setting up dependencies in Python has always been weird. Like, I remember, 19 00:01:52,160 --> 00:01:59,120 now this has been a while, I stopped using Python as a development language, pretty much when 20 00:01:59,120 --> 00:02:06,960 I started on server-side Swift, which was around, I think the last project I used Python ended 21 00:02:08,080 --> 00:02:17,200 like five years ago now. So it's been a while. But I remember, it's always been a pain point 22 00:02:17,200 --> 00:02:22,320 setting up a Python project, because there's pip to install stuff. Then there was another thing 23 00:02:22,320 --> 00:02:30,000 that was kind of, I don't remember, there was also running Python setup.py, the setup file 24 00:02:30,000 --> 00:02:31,520 was a means to install stuff. 25 00:02:31,520 --> 00:02:34,400 Right, I remember doing that a couple of times, yeah. 26 00:02:34,400 --> 00:02:38,560 And I don't remember there was another one that was controversial. Or it might have just been 27 00:02:38,560 --> 00:02:45,280 a dependency that's, I think that might have been a dependency that was setting up. My memory's 28 00:02:45,280 --> 00:02:51,280 hazy there. But the one thing I always remember, I was always happy when I had stuff set up, 29 00:02:51,280 --> 00:02:57,280 and I was successful. It was succeeding to import stuff. That was always the benchmark. 30 00:02:57,280 --> 00:03:03,040 Can I actually import matplotlib and not have a library failing to load? Because the problem 31 00:03:03,040 --> 00:03:07,520 with Python is, if it's a pure Python package, that was never a problem, right? That was always 32 00:03:07,520 --> 00:03:13,920 smooth. The problem was always the dependencies that compile C code. 33 00:03:13,920 --> 00:03:15,280 Like a wrapper or a C library or something. 34 00:03:15,280 --> 00:03:21,600 Exactly, a C library, which is sort of also a thing that we are used to in Swift land, right? 35 00:03:21,600 --> 00:03:23,040 Yep, there's lots of that in Swift. 36 00:03:23,040 --> 00:03:32,000 To the credit of Swift, that's way more reliable than the Python stuff. Just because Swift can 37 00:03:32,000 --> 00:03:37,680 actually compile the C stuff directly. And in Python, you need to have the C compiler and what 38 00:03:37,680 --> 00:03:46,160 not installed at the right versions and all that stuff. It always ended up us writing a Docker 39 00:03:46,160 --> 00:03:53,040 thing to set up stuff. It was always a bit of a pain. And reading that blog post sort of 40 00:03:53,040 --> 00:04:01,280 gave me the idea, oh, this is even worse in areas that I wasn't even aware of. So I think this is 41 00:04:01,280 --> 00:04:03,360 where I hand it back to you to summarize. 42 00:04:03,360 --> 00:04:09,920 Well, and the blog post does mention, it says the challenge with dynamic metadata in Python is vast. 43 00:04:09,920 --> 00:04:13,600 But unless you're writing a resolver or a packaging tool, you're not going to experience 44 00:04:13,600 --> 00:04:20,080 the pain as much. And so this is, we're not talking about the entire environment of writing 45 00:04:20,080 --> 00:04:25,920 Python here. But what it did do was this, and we'll link to this blog post in the show notes. 46 00:04:27,040 --> 00:04:35,200 But what it did do is it reminded me that we have a slightly similar approach in Swift package 47 00:04:35,200 --> 00:04:43,920 manifest, which are Swift code and not metadata. In fact, the start of the blog post, you always 48 00:04:43,920 --> 00:04:49,760 know it's going to be an interesting blog post when the start of the blog post admires the 49 00:04:49,760 --> 00:04:52,160 JavaScript package ecosystem. 50 00:04:54,880 --> 00:04:59,600 But there is something about the JavaScript package ecosystem, which is good. And in fact, 51 00:04:59,600 --> 00:05:05,920 there's a few things and he lists them out here. And that is that the package.json file, which is 52 00:05:05,920 --> 00:05:18,560 the kind of container manifest for a JavaScript dependency, or a package, is a JSON file. So it 53 00:05:18,560 --> 00:05:25,200 is not executable code, it is just purely metadata. And there's a couple of other things here. So 54 00:05:25,200 --> 00:05:29,760 there's a one to one relationship between a package and its metadata in JavaScript, every 55 00:05:29,760 --> 00:05:34,640 single package has one package.json file, which is the entire source of truth in the metadata. 56 00:05:34,640 --> 00:05:35,120 That's good. 57 00:05:35,120 --> 00:05:42,640 Which is also quite a baffling thing to have to call out, right? You immediately ask, well, 58 00:05:42,640 --> 00:05:46,960 hold on, is that are there packages, because this is where that isn't the case where it's a one to 59 00:05:46,960 --> 00:05:49,600 n or n to one relationship. 60 00:05:49,600 --> 00:05:54,800 Swift does also have that one. We're one to one with JavaScript at the moment. Yeah. 61 00:05:54,800 --> 00:06:02,000 Well, kind of, there's a caveat there, but we will get to that, I suppose. 62 00:06:02,000 --> 00:06:06,560 Are you talking about the Swift version specific manifests? 63 00:06:06,560 --> 00:06:07,600 Yes, exactly. Yeah. 64 00:06:07,600 --> 00:06:14,960 Yeah, yes. Yes. I mean, we're already we're already I mean, Swift still feels it's not 65 00:06:14,960 --> 00:06:20,880 a new language anymore, but it still feels kind of new as a language. And already we have artifacts 66 00:06:20,880 --> 00:06:32,320 of things like that. Anyway, so the point that I was making here was, there are certainly aspects 67 00:06:32,320 --> 00:06:39,040 of a Swift package manifest that came to mind as I was reading this blog post about the Python 68 00:06:39,040 --> 00:06:47,440 dynamic metadata. And when we've hit problems where the compiled nature of a package manifest 69 00:06:47,440 --> 00:06:54,400 causes problems for us, when we run the dump package command, which is supposed to turn a 70 00:06:54,400 --> 00:07:01,600 package meta manifest into a JSON file, which is what we can then pass. And that's how we 71 00:07:01,600 --> 00:07:08,160 extract all the metadata for about a package that we can get. And I think one of the key things that 72 00:07:08,320 --> 00:07:15,040 that jumped out to me, which is mentioned in this blog post as well, is that based on, for example, 73 00:07:15,040 --> 00:07:23,840 platform or environment, you can have your package metadata is not consistent. It is it can change, 74 00:07:23,840 --> 00:07:29,360 depending on where you're compiling or where you're running that dump package command. And I 75 00:07:29,360 --> 00:07:35,440 know, I know, I know there's a whole can of worms around opening a discussion on whether making 76 00:07:35,440 --> 00:07:43,440 package manifests code was a good idea or not. And, and I also know that changing it at this 77 00:07:43,440 --> 00:07:47,600 point would also be really difficult. And again, this is mentioned in the blog post, like once you've 78 00:07:47,600 --> 00:07:54,800 once you have Pandora's box open like this, people build all sorts of stuff into that relying on that 79 00:07:54,800 --> 00:08:02,080 feature, and it becomes incredibly difficult to roll it back. I feel with Swift, is it is it too 80 00:08:02,080 --> 00:08:08,640 late to roll it back yet? I think probably not. I mean, we're still I just read a blog post, 81 00:08:08,640 --> 00:08:16,080 actually, just before we recorded this podcast, which is the, the plan on when to make the Cocoa 82 00:08:16,080 --> 00:08:23,840 Pods repository trunk repository read only, which is their plan to sunset Cocoa Pods, basically. 83 00:08:23,840 --> 00:08:29,200 And I think they've given it a two year timeline from now, before they'll make it read only and 84 00:08:29,200 --> 00:08:37,040 finally kind of completely shut it down. But Swift VM has over the last few years has become 85 00:08:37,040 --> 00:08:42,080 hugely popular. But it was around for many years before it became hugely popular. It was around 86 00:08:42,080 --> 00:08:48,400 before it was it was really useful in iOS and Mac OS projects. As I wonder whether we haven't quite 87 00:08:48,400 --> 00:08:53,520 got past that point, where everything of the manifest format might be at least an option. 88 00:08:54,240 --> 00:08:59,680 Yeah, I'd love to see that at least discussed. And then, you know, kind of decided, 89 00:08:59,680 --> 00:09:07,520 looking at pros and cons. I mean, I, I, I'm not sure I entirely see the pros there. 90 00:09:07,520 --> 00:09:15,040 Like, just just to give some context, just today. Incidentally, I fixed a bug that resulted from 91 00:09:15,040 --> 00:09:21,040 having to have a compiler installed to to render the package manifest as JSON, 92 00:09:21,040 --> 00:09:28,240 right, we our builder needs to run finds out some stuff about a package, in order to know which 93 00:09:28,240 --> 00:09:33,360 a build command to run. And on Linux, actually, we run that in a Docker container that didn't 94 00:09:33,360 --> 00:09:37,200 have the Swift compiler installed. And this was new, it didn't need we didn't need this before, 95 00:09:37,200 --> 00:09:43,440 but now we did. And I, I was completely blind to the fact I had forgotten that our Docker image 96 00:09:43,440 --> 00:09:48,560 doesn't have the Swift compiler. So I, I called right Swift, I saw that yeah, describe package, 97 00:09:48,560 --> 00:09:54,720 and it failed. And then because of the way it was done, it sort of failed silently. And, 98 00:09:54,720 --> 00:09:59,360 or at least it printed something that wasn't immediately obvious why that happened. And I 99 00:09:59,360 --> 00:10:03,920 think that's kind of, it's kind of a heavy requirement that you need a compiler to 100 00:10:03,920 --> 00:10:08,480 understand about your package. And then also, it's, it's important, you know, what platform 101 00:10:08,480 --> 00:10:12,320 do you run it on, as you said, and what compiler version you're using to do that. 102 00:10:13,200 --> 00:10:19,760 That sort of feels like, is that is that that's a bit, that's a bit weird. And then 103 00:10:19,760 --> 00:10:27,360 we probably see more manifests than, you know, the, the normal because of what we do, 104 00:10:27,360 --> 00:10:30,480 like we see lots of packages and people ask, well, why isn't this working? And 105 00:10:30,480 --> 00:10:37,280 there's some wild stuff going on in package manifests, because it's effectively a little 106 00:10:37,280 --> 00:10:44,000 Swift script, right, a Swift program, and it's programmed in it. And you have to effectively, 107 00:10:44,000 --> 00:10:49,280 sometimes I look at these things, and I have to pass that program, because you know, what else 108 00:10:49,280 --> 00:10:54,240 can I do? Obviously, you can run Swift package describe, and then get the output. But then that 109 00:10:54,240 --> 00:11:00,000 doesn't tell you why stuff isn't, isn't there as you expect. And then you sort of have to sift 110 00:11:00,000 --> 00:11:05,200 through and people do stuff in there. They import foundation, look at environment variables, 111 00:11:05,200 --> 00:11:14,320 imply logic, and you think, Oh, God, is this? I mean, it opens up possibilities, but 112 00:11:14,320 --> 00:11:22,400 I feel like some, you know, as the post says, you know, constraints are good, right? If 113 00:11:22,400 --> 00:11:27,920 would, how, what, what would we lose if that was was just a JSON file? 114 00:11:27,920 --> 00:11:33,040 Well, that's it. And every time I see somebody doing something like that in a package manifest, 115 00:11:33,040 --> 00:11:37,840 I think, I kind of wish you weren't doing that. Like, wouldn't it be better if this was just a 116 00:11:37,840 --> 00:11:44,640 standard file? My go to example, and I hate to call out a specific, a specific example here. 117 00:11:44,640 --> 00:11:51,920 But they're a big company. So I feel I feel less guilty about it. My go to example for this is the 118 00:11:52,720 --> 00:12:03,680 AWS SDK Swift package from AWS, which is a 627 line program in a package manifest. Now, 119 00:12:03,680 --> 00:12:12,960 to be fair to them, they have they have 300, no 422 lines of targets, which is a lot of targets. 120 00:12:12,960 --> 00:12:20,080 But, but still, there's, there's, there's code after that, which is doing all sorts of stuff. 121 00:12:20,080 --> 00:12:25,360 It's looking at paths on the file system, it's it's looking at processes and getting environment 122 00:12:25,360 --> 00:12:32,480 variables. And it's doing it's doing more than you would probably like to think it was doing if it 123 00:12:32,480 --> 00:12:37,120 was just a package manifest with some metadata in it. And that's why I'd be really curious to 124 00:12:37,120 --> 00:12:43,520 have a proper discussion and see, well, what use cases aren't possible with a, you know, static 125 00:12:44,160 --> 00:12:51,840 JSON file or whatever it is, what we lose? Or is there even, I mean, the dynamism could be just 126 00:12:51,840 --> 00:12:58,320 done upstream, right? That the output is a is a JSON file, right? If Amazon could, in that case, 127 00:12:58,320 --> 00:13:04,400 have a Swift script that assembles stuff and then, you know, outputs a JSON file instead, 128 00:13:04,400 --> 00:13:09,120 rather than, you know, keep that logic, you know, there on the fly sort of in the manifest. 129 00:13:09,920 --> 00:13:14,400 I can imagine that there's stuff that is really hard to do, then, you know, like super platform 130 00:13:14,400 --> 00:13:20,000 specific, how would that look? Like, would you have sort of logical structures within a JSON 131 00:13:20,000 --> 00:13:24,960 file that says, you know, like, this is the dependency tree, if it's on macOS and Linux, 132 00:13:24,960 --> 00:13:31,280 you know, how would that work? I mean, I can see how, yeah, that can get complex. But 133 00:13:31,280 --> 00:13:36,880 that's a theme, the complexity is there. And it's just a matter of how do you package it up? 134 00:13:36,880 --> 00:13:44,240 Because, end of the day, it has to be a has to be rendered out at some point is that how, how, 135 00:13:44,240 --> 00:13:50,320 how much do you obfuscate it up front sort of is, I think, my right, my view of it. And 136 00:13:50,320 --> 00:13:58,720 there is benefit and having these files more machine readable off the bat without having to 137 00:13:58,720 --> 00:14:04,400 transform them, right? Because we like, always have to make sure they have a Swift compiler 138 00:14:04,400 --> 00:14:09,920 and run Swift package describe or Swift package dump package in order to get the JSON out of it. 139 00:14:09,920 --> 00:14:14,640 And that's the thing, you know, the JSON that we get out is the thing that we're interested in. 140 00:14:14,640 --> 00:14:21,280 That's what we're using. And I sometimes wonder if that's not the, if that wouldn't be the better 141 00:14:21,280 --> 00:14:24,640 intermediate format to keep around. 142 00:14:24,640 --> 00:14:29,680 - Well, so just kind of make that not a generated artifact, but a stored artifact. 143 00:14:29,680 --> 00:14:34,880 - Yeah, exactly. I mean, and then, you know, discuss, should there be something that can 144 00:14:34,880 --> 00:14:41,520 generate it if you really have a very dynamic use case where you sort of need to, you know, 145 00:14:41,520 --> 00:14:46,320 you sort of need to generate them, but then also bake them into a package, you know, so you don't 146 00:14:46,320 --> 00:14:53,920 have, you can still be dynamic and then also write them out so people can actually get metadata info 147 00:14:53,920 --> 00:14:58,880 without having to run the process every time, which is something we need to do, right? We have 148 00:14:58,880 --> 00:15:04,400 a nightly that looks at packages and what we do is we fetch all the package manifests in a package. 149 00:15:04,400 --> 00:15:09,040 And by all, I mean, all the versioned ones as well. So we have to make multiple HTTP requests 150 00:15:09,040 --> 00:15:15,200 to get all the package.swift files out of a package. And fortunately, it's enough to copy 151 00:15:15,200 --> 00:15:19,920 these in an empty directory and then run Swift package describe. That actually works. It doesn't 152 00:15:19,920 --> 00:15:24,640 look at any other thing, other things in your package. It doesn't verify that you have a source 153 00:15:24,640 --> 00:15:30,640 directory and whatnot. So that's enough to actually dump the package info then. But what we do is then 154 00:15:30,640 --> 00:15:36,720 we render JSON out of it. So that process would be much easier if all we had to do is just fetch 155 00:15:36,720 --> 00:15:43,280 a JSON file to begin with or whatever format is the one that's picked. It's just a lot of 156 00:15:43,280 --> 00:15:50,640 work that needs to happen to get that data out. Yeah. Yeah. Just to flip onto the other side of 157 00:15:50,640 --> 00:15:55,360 the argument and play devil's advocate, even though I am on this side of the argument, 158 00:15:55,360 --> 00:16:04,560 there is one advantage to this that we benefit from, which is if it was a pure metadata file, 159 00:16:04,560 --> 00:16:11,520 it would be more likely that we would let badly formed packages into the system. Whereas the fact 160 00:16:11,520 --> 00:16:17,920 that we have to run package, the dump package before we accept a package into the index, 161 00:16:17,920 --> 00:16:23,440 we get that we do get that level of verification that at least the manifest compiles. 162 00:16:23,440 --> 00:16:27,920 Yeah, but I mean, there's Jason, there's Jason. 163 00:16:27,920 --> 00:16:32,800 You could validate that and make sure that all the keys. 164 00:16:32,800 --> 00:16:39,920 I'm back on this side of the fence. I attempted an escape, but it failed. 165 00:16:39,920 --> 00:16:41,200 Resistance is futile. 166 00:16:43,120 --> 00:16:50,720 Exactly. Exactly. Well, next week, we'll fix the NPM ecosystem and set that right. 167 00:16:50,720 --> 00:16:51,600 Great. 168 00:16:51,600 --> 00:16:58,160 There was another interesting post that I see 169 00:16:58,160 --> 00:17:07,040 come out last week. Thanksgiving post by Holly Baller. And it's called prospective vision, 170 00:17:07,040 --> 00:17:12,480 improving the approachability of data race safety. I'm sure you've seen that, right? 171 00:17:12,960 --> 00:17:18,560 I did. And in fact, before you before you go into it, I want to read. I want to read Holly's 172 00:17:18,560 --> 00:17:22,480 Macedon post where she where she linked to this, because it really made me laugh. 173 00:17:22,480 --> 00:17:27,920 My favorite Thanksgiving tradition is a good language design debate ahead of the holiday. 174 00:17:27,920 --> 00:17:29,360 Nice. 175 00:17:29,360 --> 00:17:32,960 This time on improving the approachability of data race safety. 176 00:17:32,960 --> 00:17:38,080 Well, Holly, I'm so glad that that is that's what was on your mind around Thanksgiving. 177 00:17:38,960 --> 00:17:44,400 I hope I hope you managed to at least have some time not thinking about data race safety over the 178 00:17:44,400 --> 00:17:45,200 holiday. 179 00:17:45,200 --> 00:17:49,280 Well, isn't the US thing that Thanksgiving you go home to argue with your family? And that's sort 180 00:17:49,280 --> 00:17:52,880 of that's probably what she's kind of doing with the other family. 181 00:17:52,880 --> 00:17:55,200 I guess. 182 00:17:55,200 --> 00:18:01,520 Anyway, let me I interrupted you. Sorry. I did see it. Yes. 183 00:18:02,400 --> 00:18:11,840 Yeah, it's I really like this. I loved seeing this. It sets out to tackle some of the problems 184 00:18:11,840 --> 00:18:18,000 that have come up when people start using Swift concurrency. And I think it bears repeating that 185 00:18:18,000 --> 00:18:23,680 we are in the early stage of that adoption. And there's been quite a bit of noise because people 186 00:18:23,680 --> 00:18:29,600 struggle with it, right? There's stuff that doesn't go as they as they planned. 187 00:18:30,560 --> 00:18:34,080 Some of it is is compiler related. There are some issues that are 188 00:18:34,080 --> 00:18:42,640 just growing pain in in Swift six language mode. So there's some some false positives and stuff. 189 00:18:42,640 --> 00:18:49,360 And, and largely it sets out a vision on how to better deal with 190 00:18:49,360 --> 00:18:55,360 with this with this adoption. Let me just see. Yes. 191 00:18:57,360 --> 00:19:06,480 If she has a yeah, so she says she opens up and I should say, I found this post super readable. 192 00:19:06,480 --> 00:19:15,680 People often think of Swift language development. Super in the weeds and you you can't follow and 193 00:19:15,680 --> 00:19:21,120 there's there's that right often there are parts of proposals that are really technical and and 194 00:19:21,120 --> 00:19:24,640 you need to know a lot upfront to actually even be able to follow but 195 00:19:25,200 --> 00:19:30,000 you need to at least be be on the same page as a compiler engineer. Yeah. 196 00:19:30,000 --> 00:19:33,680 I don't think this falls in that category. There's certainly stuff that you sort of 197 00:19:33,680 --> 00:19:41,520 need to know a little bit about at least I think it's a bit hard to judge I I'm not a 198 00:19:41,520 --> 00:19:48,400 Swift concurrency expert by by a long shot. But I also don't want to I mean, I've used it a bit. So 199 00:19:48,400 --> 00:19:53,760 I'm probably more exposed to it than someone who's, who's just starting out. 200 00:19:54,320 --> 00:19:59,360 Writing Swift or even someone who's only just starting to convert a project over. 201 00:19:59,360 --> 00:20:05,920 But I think I think I'm not too sort of in the weeds already to be blind to 202 00:20:05,920 --> 00:20:15,040 to, you know, that that threshold. I think it's quite approachable. And yeah, I think it's, 203 00:20:15,040 --> 00:20:20,000 it paints the picture of what's what the problem is and what they're trying to achieve here. 204 00:20:21,040 --> 00:20:26,320 So she opens up saying Swift's built in support for concurrency has three goals. And that's to 205 00:20:26,320 --> 00:20:32,800 extend the memory safety guarantees to low level data races, maintain progressive disclosure for 206 00:20:32,800 --> 00:20:38,480 non concurrent code, and make basic use of concurrency simple and easy, and make advanced 207 00:20:38,480 --> 00:20:42,800 uses of concurrency to improve performance natural to accomplish and reason about. 208 00:20:42,800 --> 00:20:49,520 And then she goes into, you know, sort of what are the remaining pain points where 209 00:20:50,320 --> 00:20:55,200 what this is about is mitigating false positive data rate safety errors in 210 00:20:55,200 --> 00:21:01,120 in sequential code and what the thing boils down to, I think, can be summarized in 211 00:21:01,120 --> 00:21:10,000 the default is is sort of to assume that stuff is going to be running concurrently. And then 212 00:21:10,000 --> 00:21:16,480 the compiler analyzes everything you do with that in mind. So anytime you touch, you know, 213 00:21:16,480 --> 00:21:22,480 like global variables, for instance, the compiler will immediately shout, Oh, hold on, hold on, 214 00:21:22,480 --> 00:21:27,040 what are you doing here? Remember, if you do this, there might be other concurrent access, 215 00:21:27,040 --> 00:21:32,720 and that's not safe what you're doing. And what this is proposing is to flip this around 216 00:21:32,720 --> 00:21:39,920 on a module by module basis. So to open up a mode where the default is to assume 217 00:21:39,920 --> 00:21:46,720 main actor isolated code. And that means effectively running a single threaded program 218 00:21:46,720 --> 00:21:51,280 on the main thread. And then if you mess with the global variable, that's safe by default, 219 00:21:51,280 --> 00:21:54,880 because there's only ever one thread that can deal with that, right? There's no there's no 220 00:21:54,880 --> 00:22:01,440 concurrent access because there's no concurrency. And that the vision is that should deal with a 221 00:22:01,440 --> 00:22:07,280 lot of the all of the false positives right now, that can happen. And the false positives are 222 00:22:07,280 --> 00:22:12,320 really shortcomings where the compiler can't see everything that's happening. And then, 223 00:22:12,320 --> 00:22:16,800 because it has to be safe by default, it says, Look, this, this could be problematic, 224 00:22:16,800 --> 00:22:21,440 I can't prove otherwise. So I have to warn about it, or, you know, in Swift six mode, 225 00:22:21,440 --> 00:22:26,240 raise an error about it. And it's for you to be really explicit about what you're trying to do. 226 00:22:26,240 --> 00:22:32,560 And by flipping this around, sort of the, the premise goes away, right? The, the initial 227 00:22:32,560 --> 00:22:37,360 assumption where there might be a concurrent access isn't actually a problem anymore, because 228 00:22:37,360 --> 00:22:44,960 there isn't concurrent access. So it that eliminates the need to raise an error by default, 229 00:22:44,960 --> 00:22:51,200 and then you can poke holes into that by saying, Alright, this is actually non isolated, or has 230 00:22:51,200 --> 00:22:56,080 different isolation, and then you can open up to concurrency, and then you get the richer warnings. 231 00:22:56,080 --> 00:23:01,840 But the you can put this in a mode. And this is a mode that's really interesting, for example, 232 00:23:01,840 --> 00:23:07,120 for scripts, or like in general is proposed to use in executable targets where, where you're going to 233 00:23:07,120 --> 00:23:11,120 be starting with on the main thread, you know, like, if you write a script, you're probably going 234 00:23:11,120 --> 00:23:16,800 to be on the main thread the whole time, right? And then why even deal with all this? And that's 235 00:23:16,800 --> 00:23:23,120 the proposal is sort of to flip this around, I can, I hope I didn't mess this up describing what's 236 00:23:23,120 --> 00:23:28,800 what this is about. Again, read it, because I think it's really readable. The discussion around 237 00:23:28,800 --> 00:23:34,480 it is that's more in depth, because people raise, you know, concerns, how would this affect this and 238 00:23:34,480 --> 00:23:39,200 that. And there are certainly aspects that are more complicated when it comes to classes and 239 00:23:39,200 --> 00:23:43,680 inheritance and protocols, and then it gets a bit in the weed. But I think the basic premise 240 00:23:43,680 --> 00:23:51,360 is quite graspable. It's quite obvious what this is proposing. And I think it's really well laid 241 00:23:51,360 --> 00:23:57,040 out. And hopefully that will be accepted, implemented, and then could could be one of 242 00:23:57,040 --> 00:24:03,520 those things. Remember, when we discussed this last time, we said, this is early days, just don't 243 00:24:03,520 --> 00:24:09,760 rush into adopting Swift 6 by next year, things might be very different and might be much easier. 244 00:24:09,760 --> 00:24:15,200 And that actually might be one of those things where you have a much easier time adopting this 245 00:24:15,200 --> 00:24:24,160 in Swift 6.2.3, whenever this comes out, or is implemented. This might be one of those things 246 00:24:24,160 --> 00:24:30,400 where you won't have to sprinkle main actor all through your code base, because main actor is the 247 00:24:30,400 --> 00:24:36,880 thing that's going to be assumed, you know, wholesale, and you don't need to annotate stuff, 248 00:24:36,880 --> 00:24:45,840 because it's sort of baked in into the module by module assumptions. There's one other thing I 249 00:24:45,840 --> 00:24:51,840 wanted to highlight. And that's from the comments in this thread. Because that's also something 250 00:24:52,560 --> 00:25:00,240 I at least said before, and I was really glad to see this echoed. And this is Tim Condon's reply 251 00:25:00,240 --> 00:25:05,920 to a common complaint that data race safety annotations are a chore. And this is what we 252 00:25:05,920 --> 00:25:12,240 talked about. I'm not sure if it was last episode or the one before. Tim says, to provide an 253 00:25:12,240 --> 00:25:17,440 alternative point of view of this, I've lost count of the number of issues and data race issues 254 00:25:17,440 --> 00:25:23,360 that have been caught and fixed by adopting Sendable across Vapors code bases. Lots of GitHub 255 00:25:23,360 --> 00:25:29,040 issues that were impossible to reproduce, subtle data race issues, and downright stupid coding from 256 00:25:29,040 --> 00:25:35,920 myself. Once we adopted Sendable, and yes, it wasn't an easy process, especially doing it as 257 00:25:35,920 --> 00:25:42,240 an early adopter, all of those issues went away. We've not had a single issue reporting a crash as 258 00:25:42,240 --> 00:25:49,680 a result of data race issues. And I was really glad to see that because I hadn't heard many people 259 00:25:49,680 --> 00:25:56,240 say that thing that I've said before about our concurrency crashes that we've seen and that 260 00:25:56,240 --> 00:26:04,640 disappeared once we switched to Swift 6. I think it really bears looking at these examples and 261 00:26:04,640 --> 00:26:10,160 highlighting those so it's clear what you're getting. That it's not just a chore that you 262 00:26:10,160 --> 00:26:16,880 have to deal with errors, there's something that it buys you. But, and this is also important, 263 00:26:16,880 --> 00:26:26,480 we touched on this as well, to some degree, iOS doesn't have this at the same level, right? It 264 00:26:26,480 --> 00:26:32,880 hasn't doesn't have the same level of impact on iOS. And I vividly remember when I was managing 265 00:26:32,880 --> 00:26:38,640 an iOS team, when we were triaging iOS crashes, one of the things I looked at specifically was the 266 00:26:39,360 --> 00:26:43,840 number of crashes per device. So the most important thing to fix was, we didn't want to have crash 267 00:26:43,840 --> 00:26:48,560 loops on a device. If someone has a crash every once in a while, that was all right. If someone 268 00:26:48,560 --> 00:26:54,320 crashed, obviously looking at the logs, the crash reports repeatedly, that was a problem. Now, 269 00:26:54,320 --> 00:26:59,760 server code is different because you essentially run all the devices, right? You aggregate all 270 00:26:59,760 --> 00:27:06,720 the crashes across the whole install base at once. So you have much more incentive to fix that. 271 00:27:08,800 --> 00:27:15,440 But, and Tim says that Swift is just more than an iOS programming language at this point, right? 272 00:27:15,440 --> 00:27:23,360 Yes. And you're right that it is really nice to see Tim's comment there. I hadn't seen that until, 273 00:27:23,360 --> 00:27:28,800 I just looked at it while you were talking about it. And it is great to see a story like that. But 274 00:27:28,800 --> 00:27:38,160 you're absolutely right that this is a language that has many different uses now. And still the 275 00:27:38,160 --> 00:27:46,800 main use is from iOS and MacOS applications. So I'm so happy to see this document from Holly. 276 00:27:46,800 --> 00:27:52,240 First of all, and we knew that they were still thinking about this, but this is 277 00:27:52,240 --> 00:27:56,160 proof that they're still thinking about it. And it's nice to see, like, if you just look through 278 00:27:56,160 --> 00:28:04,560 some of the headings in this document, some of the headings are really, they really spoke to me 279 00:28:04,560 --> 00:28:11,200 actually, easing incremental migration to data race safety. I mean, the fact that that is a title 280 00:28:11,200 --> 00:28:18,160 in this document is, it lifts my heart. It's great that that's the kind of thing that they're 281 00:28:18,160 --> 00:28:25,680 talking about here. And obviously there is that the idea that you could switch an application to be 282 00:28:25,680 --> 00:28:31,120 single threaded because some applications don't need concurrency. It's fairly rare these days, 283 00:28:31,120 --> 00:28:37,120 even an iOS application, a simple iOS application will probably make some kind of network call. 284 00:28:37,120 --> 00:28:41,680 And as soon as you do that, you need to consider concurrency in there. But there are certainly apps 285 00:28:41,680 --> 00:28:48,400 that don't need it. And especially as people are learning the language. And I think that's one 286 00:28:48,400 --> 00:29:00,640 thing. I wrote a few weeks ago about optimism in iOS Dev Weekly. And I use the example of how easy 287 00:29:00,640 --> 00:29:06,480 it is to get up and running with Swift on a new Mac, a brand new Mac, a friend of mine bought a 288 00:29:06,480 --> 00:29:13,600 new Mac. And I wanted him to run some benchmarks on package index, but compiling it with the M4 289 00:29:13,600 --> 00:29:22,160 chip to see how it compared to my very expensive M1 Macs that I bought a few years ago. And I was 290 00:29:22,160 --> 00:29:28,480 struck by how incredibly easy it was for him as somebody who is not a developer to get that, 291 00:29:29,760 --> 00:29:38,480 get Swift installed and have what is quite a complex project compile. It was trivial. And 292 00:29:38,480 --> 00:29:47,840 in response to that, my optimism and kind of choosing to see the good things about the 293 00:29:47,840 --> 00:29:57,680 language, I got some real colorful feedback saying that even people who are trying to learn Swift are 294 00:29:57,680 --> 00:30:04,320 hitting these concurrency issues immediately. And so I'm so glad that they're really putting 295 00:30:04,320 --> 00:30:11,040 this into something that will hopefully be implemented. Yeah, it sounds like it's really 296 00:30:11,040 --> 00:30:16,720 going to take the edge off some of this, the early stuff and Holly highlights that in an 297 00:30:16,720 --> 00:30:21,440 explicit example. I think that it's unfortunate that in some areas you immediately get hit with 298 00:30:21,440 --> 00:30:28,000 these warnings when you're doing something like obvious, you know, in a script, you know, 299 00:30:28,000 --> 00:30:32,320 like a global variable, stuff like that. And if this is the way of dealing with that, that's 300 00:30:32,320 --> 00:30:37,920 fantastic because it'll open up these use cases to be much smoother. I mean, we run a script to 301 00:30:37,920 --> 00:30:46,480 validate our packages and that's sort of one thing where we haven't transitioned over yet. And that's 302 00:30:46,480 --> 00:30:51,360 going to be a bit painful. And that might actually be a reason to wait and wait until we have that 303 00:30:51,360 --> 00:30:56,560 mode and then just do it do it there. Well, almost certainly that doesn't need concurrency. 304 00:30:56,560 --> 00:31:03,920 Well, it does network requests, and we might pass some stuff. So it's, it's kind of 305 00:31:03,920 --> 00:31:08,800 but in that script, it could it could absolutely wait for that. 306 00:31:08,800 --> 00:31:14,320 In the single package validation. Yeah, for sure. I'm thinking about the validator that crawls, 307 00:31:14,320 --> 00:31:21,760 you know, does all the packages. Yeah, that's that's another one. Yeah. Yeah. I mean, 308 00:31:21,760 --> 00:31:29,120 all of this. It's just great. But we've talked far too long about, about this stuff. So we should get 309 00:31:29,120 --> 00:31:36,080 to some packages before people just stop listening. Yes, let's do some packages. Do you want to start 310 00:31:36,080 --> 00:31:43,440 us this week? I'll kick us off. My first package recommendation isn't a package recommendation, 311 00:31:43,440 --> 00:31:51,680 per se. It's a it's a package search recommendation. I came across a social media post 312 00:31:51,680 --> 00:31:59,760 a couple of weeks ago, about a project called LMDB, which I'd never heard of. So this is sort of a 313 00:31:59,760 --> 00:32:06,000 key value store database, which has fast transactional asset transactions, support, 314 00:32:06,800 --> 00:32:13,760 thread safe, crash proof, broad platform support. And the person wasn't posting about Swift, 315 00:32:13,760 --> 00:32:22,320 this was just a general recommendation to look at LMDB. When you might be looking at SQLite as 316 00:32:22,320 --> 00:32:26,640 sort of a similar project, but you know, SQLite is very relational. And this is a key value store 317 00:32:26,640 --> 00:32:32,080 thing. So this might be if you have key values, that might be more fitting. And then I thought, 318 00:32:32,080 --> 00:32:37,920 oh, it's interesting that I never heard of this. I wonder if we have wrappers, because it's a C 319 00:32:37,920 --> 00:32:43,840 based project, I believe. I thought, well, maybe we do have wrappers. And I ran a search, and I was 320 00:32:43,840 --> 00:32:51,040 really delighted to find quite a number of packages related like this, I'll name four. 321 00:32:51,040 --> 00:32:57,840 There's a couple more even, and obviously just the plain C wrapper as well. So we got quick LMDB, 322 00:32:57,840 --> 00:33:06,640 rapid LMDB, Swift LMDB, kind of a theme here in the names. And then Empire is a quite differently 323 00:33:06,640 --> 00:33:14,000 named one. And these all, you know, wrap this and have various different APIs. I didn't try any of 324 00:33:14,000 --> 00:33:20,560 them. But they looked well maintained and had different, you know, different ways of dealing 325 00:33:20,560 --> 00:33:26,080 or adding an API on top of it. I thought that was really nice to see that this is represented. And I 326 00:33:26,080 --> 00:33:32,240 think the database itself seemed quite interesting. So if you have a need for a key value store, 327 00:33:32,240 --> 00:33:38,480 give this a try. When you normally perhaps would have chosen SQLite, I think that's a 328 00:33:38,480 --> 00:33:41,760 nice alternative, if you need something like that. 329 00:33:41,760 --> 00:33:47,440 And does it have any, you may not know this, but does it have any, any dependencies on other, 330 00:33:47,440 --> 00:33:53,920 like, is it built on top of another SQL? Sorry, another key value store? Or is it 331 00:33:53,920 --> 00:33:56,080 purely implemented inside this package? 332 00:33:56,080 --> 00:34:02,480 I, well, the packages themselves probably pull in the C sources, but the LMDB itself, I think is a... 333 00:34:02,480 --> 00:34:05,280 Ah, so LMDB is the underlying. Okay. 334 00:34:05,280 --> 00:34:12,480 Yes. Yeah, that's a, that's a, it's sort of think of it as this is SQLite, an alternative to SQLite, 335 00:34:12,480 --> 00:34:20,240 which has the same thing, right? You typically use, have SQLite interfaces by pulling in the 336 00:34:20,240 --> 00:34:25,840 SQLite C sources and then building those and then adding richer APIs on top of it. And that's what 337 00:34:25,840 --> 00:34:30,640 these packages are, I think, are generally doing. I haven't looked at all of them in detail, 338 00:34:30,640 --> 00:34:34,240 but I've seen a couple, you know, explicitly call out that they're wrapping the 339 00:34:34,240 --> 00:34:41,840 C sources or the, I think it's C under the hood. They're pulling, well, it must be C or C++, 340 00:34:41,840 --> 00:34:44,800 I suppose. So yeah, there you go. 341 00:34:44,800 --> 00:34:57,840 Great. My first package is called Fuzzi, F-U-Z-I, and the developer name is DimensionDev. 342 00:34:57,840 --> 00:35:05,200 I'm not quite sure who's behind it, but it is actually a port or at least a, 343 00:35:05,200 --> 00:35:13,040 it's based on a port of Matt Thompson's Ono library, which was, I think, an Objective-C 344 00:35:13,920 --> 00:35:20,080 library back in the, well, yeah, I've just looked at it. It's more than 10 years old, 345 00:35:20,080 --> 00:35:28,160 the Ono library, and the last commit was five years ago. So an abandoned library for parsing XML. 346 00:35:28,160 --> 00:35:39,920 So obviously Swift can parse XML, but unlike JSON, XML has kind of died as an interchange 347 00:35:39,920 --> 00:35:46,320 format these days, often for good reason. You know, JSON is very much more efficient in terms 348 00:35:46,320 --> 00:35:54,400 of size and all the rest of it. So there are huge and significant reasons why JSON won that battle, 349 00:35:54,400 --> 00:36:01,840 but certainly people still need to parse XML from time to time. And the APIs built into 350 00:36:01,840 --> 00:36:09,360 Foundation for parsing XML are okay, but they're a little outdated compared to how we interact with 351 00:36:09,360 --> 00:36:21,760 JSON. And what Ono and more recent Fousey library do is try to bring a more Swift-friendly syntax to 352 00:36:21,760 --> 00:36:36,160 parsing and reading data from XML files. So it's still parsed, powered by libxml2 underneath the 353 00:36:36,160 --> 00:36:41,600 covers. So very, very fast parsing from that, supports XPath and CSS queries, 354 00:36:41,600 --> 00:36:51,040 auto conversion of dates and numbers. It can load HTML and XML documents from strings or 355 00:36:51,040 --> 00:36:56,640 NSData. So it's got all the kind of basics, but then there are some things in Fousey that have 356 00:36:56,640 --> 00:37:04,480 been improved as well. Mostly the Swift-style API, no more return types like in any object, 357 00:37:05,120 --> 00:37:12,560 with so you're much more type safe with this new framework. Some customizable dates, 358 00:37:12,560 --> 00:37:16,960 number four matters. So there's a few other things as well, but effectively it's a modernized 359 00:37:16,960 --> 00:37:24,320 and easier way to access and parse XML, which if you still have to do that, you might be interested 360 00:37:24,320 --> 00:37:29,680 in checking this out. - Nice. That looks great. And, you know, such a rich history, 361 00:37:29,680 --> 00:37:37,840 nine years in development. That's amazing. And you see the sedimental layers. If you look through 362 00:37:37,840 --> 00:37:43,040 the readme, there's pod install, there's Carthage update. It has all the different... 363 00:37:43,040 --> 00:37:49,360 - Actually, I've... So I may have been slightly tricked by this. I've only just realized this, 364 00:37:49,360 --> 00:37:54,400 the one that the dimension dev one that I've recommended here, and this is not the first 365 00:37:54,400 --> 00:38:02,320 time I've done this. It's actually a fork. So Fousey itself, the original packet is by C. Zeng. 366 00:38:02,320 --> 00:38:12,000 And what we'll do is we'll pop a link to both of these in the show notes, because what I didn't 367 00:38:12,000 --> 00:38:16,720 realize is that this is a fork. So I'm not sure, I'm only just learning this now. I'm not sure how 368 00:38:16,720 --> 00:38:24,240 different the version I saw in the new packages list is from that fork, but certainly either of 369 00:38:24,240 --> 00:38:31,840 them are an enhancement over the standard XML document and XML parser classes. 370 00:38:31,840 --> 00:38:39,920 - Great. Very nice. Right. My second pick is called Orb by Siddharth Mehta. 371 00:38:39,920 --> 00:38:49,920 This is a lovely package. It creates Siri-like orbs. And by Siri-like orb, I mean that 372 00:38:49,920 --> 00:38:56,240 that swirling, you know, like circle animation when you bring up Siri on your phone or on the 373 00:38:56,240 --> 00:39:02,240 Mac, I think it's sort of universal thing. And it has many other variations as well. And the readme 374 00:39:02,240 --> 00:39:07,440 is really nice in showing those off. So, you know, there's a number of this mystic nature, 375 00:39:07,440 --> 00:39:11,760 sunset, minimal, different color themes, and I suppose different animations as well. 376 00:39:11,760 --> 00:39:18,080 I don't think there's anything... No, it's not actually showing a video because I imagine the 377 00:39:18,080 --> 00:39:24,960 animations might be slightly different depending on which one you pick, but you can, you get an 378 00:39:24,960 --> 00:39:31,840 idea for what color they look like. So if you need an orb, and who doesn't, this is a package for you, 379 00:39:31,840 --> 00:39:41,200 I suppose. - Well, who doesn't need an orb in these times? - Yes. - All right. My last package for 380 00:39:41,200 --> 00:39:53,600 this week is called SolverCore, S-O-U-L-V-E-R, by Solver, the company who produced the Mac app, 381 00:39:53,600 --> 00:39:59,520 Solver, which is a calculator app, which I've used for many, many years now. And I dearly, 382 00:39:59,520 --> 00:40:08,560 dearly love it. And the unique thing about the app is that you... It's kind of like a cross between 383 00:40:08,560 --> 00:40:17,440 a spreadsheet and a calculator. So you can type in lines of text which get evaluated. So you can 384 00:40:17,440 --> 00:40:23,520 type in a mathematical kind of equation or something like that, and it will give you the 385 00:40:23,520 --> 00:40:30,160 answer to that. Sorry, not equation, type in just, you know, three plus four, and it will give you 386 00:40:30,160 --> 00:40:36,160 the answer to that. But then you can refer back to previous lines. So you can say, take the output 387 00:40:36,160 --> 00:40:42,240 of line one and multiply it by 20, and then carry on like that. And over the years, it's become more 388 00:40:42,240 --> 00:40:50,560 and more capable. You can bring currency conversions in there. It makes requests out to 389 00:40:50,560 --> 00:40:58,480 get up-to-date currency conversion data. And the reason I noticed that in the package feed this 390 00:40:58,480 --> 00:41:07,440 week is that they've just released a version three of this library, which I guess tracks a feature 391 00:41:07,440 --> 00:41:14,160 they've just added in the application itself, which is that you can have place data inside 392 00:41:14,160 --> 00:41:20,560 calculations now. So you can say, for example, what is the time in Ubud, Bali, and it will tell 393 00:41:20,560 --> 00:41:27,120 you that. And it knows where places are. So you can say, what's the distance between London and, 394 00:41:27,840 --> 00:41:32,640 you know, Anchorage or something like that. And it knows about places. 395 00:41:32,640 --> 00:41:40,160 But what I really want to talk about with this is how this has been split out into, so mostly what 396 00:41:40,160 --> 00:41:44,960 I've been talking about so far is the app called Solver, which you should absolutely check out if 397 00:41:44,960 --> 00:41:55,360 you haven't used it already. But what Solver is built on top of is this Solver core package, 398 00:41:55,360 --> 00:42:00,720 which gives you that calculation engine in a format that you can use, including all these 399 00:42:00,720 --> 00:42:09,120 fancy features like places and currencies and all the rest of it, that you can embed into your apps. 400 00:42:09,120 --> 00:42:17,840 And I've seen many apps now implement this. So for example, if you're in like a design application 401 00:42:18,720 --> 00:42:25,760 and you wanted to say, well, this box that I'm editing is, you know, 10 pixels wide, 402 00:42:25,760 --> 00:42:30,960 and I wanted to actually make it 10 plus eight pixels wide, because I'm adding eight to everything, 403 00:42:30,960 --> 00:42:38,480 let's say, or a whole load of boxes. If you put Solver core behind those text boxes, they become 404 00:42:38,480 --> 00:42:45,440 little calculators where you can just on the fly do calculations. And that's such a powerful feature. 405 00:42:46,240 --> 00:42:56,640 Now, the one thing I should mention here is that this is not a completely free or open source 406 00:42:56,640 --> 00:43:01,680 license. This is, I'll actually read you the bit from the bottom of the readme file, 407 00:43:01,680 --> 00:43:06,560 because it's important to note this before you kind of go off and start using this project. 408 00:43:06,560 --> 00:43:12,640 You may use Solver core in personal or private projects, but please email us if you wish to 409 00:43:12,640 --> 00:43:18,720 use it in a publicly available or commercial project. So it's fine to play around with it. 410 00:43:18,720 --> 00:43:22,240 It's fine to implement something, but before you actually ship anything with it, 411 00:43:22,240 --> 00:43:30,480 you need to contact the company. And it is actually a binary, there is a binary target in there. So 412 00:43:30,480 --> 00:43:34,880 it's also, you don't get the full source code for this calculation engine, but I still think it's 413 00:43:34,880 --> 00:43:40,640 worth checking out because it's such a powerful concept, I think. I love it. Yeah. I mean, 414 00:43:40,640 --> 00:43:45,280 Solver is just such a great app. If there's a library that allows you to do similar things in 415 00:43:45,280 --> 00:43:49,920 your own code, and even if it's just a personal project, that's just great. I think that's a 416 00:43:49,920 --> 00:43:58,080 fantastic tool. Well, I've spoken to, the developer is Zach Cohen, and I've spoken to him 417 00:43:58,080 --> 00:44:06,800 on several occasions, actually. And as I understand it, Solver itself is built on this library. So 418 00:44:06,800 --> 00:44:13,120 this is the real thing. This is not some pale imitation. This is it. Yeah. Very nice. 419 00:44:13,120 --> 00:44:21,840 All right. My third and final pick is called Q by Matt Mazzicotte. And I think this time I actually 420 00:44:21,840 --> 00:44:26,560 pronounced Matt's last name correctly. I've messed that up a couple of times in the past. Apologies, 421 00:44:26,560 --> 00:44:35,680 Matt. Yeah, I saw a podcast with him. I think it was the Dev Diaries that we were on. 422 00:44:36,480 --> 00:44:40,640 Yes. Yeah, exactly. And it was at that point that I realized that we've been 423 00:44:40,640 --> 00:44:46,880 pronouncing his name wrong. Sorry, Matt. So we spoke about Swift 6 and concurrency earlier, 424 00:44:46,880 --> 00:44:53,760 and this is a really nice package to give you an async queue. So, you know, one of the problems 425 00:44:53,760 --> 00:44:59,120 with structured concurrency when you do task groups is you have no control over the execution 426 00:44:59,120 --> 00:45:06,480 order of stuff. If you have async blocks and you enqueue them in these task groups, they can come 427 00:45:06,480 --> 00:45:13,200 out in, you know, like not entirely random, I suppose. But, you know, you can't rely on the 428 00:45:13,200 --> 00:45:18,800 order, really. And this fixes that. So it's effectively like a serial or concurrency, 429 00:45:18,800 --> 00:45:25,680 concurrent queue, just like dispatch queue that you can enqueue async blocks on. And if you run 430 00:45:25,680 --> 00:45:32,480 it serially, like you would in a serial dispatch queue, you really have execution order guarantees 431 00:45:32,480 --> 00:45:37,440 what you get out of it. So that's really nice. It has a couple of other API extensions, 432 00:45:37,440 --> 00:45:42,080 like something like a barrier. Have a look at the README. It gives examples. I think it's really 433 00:45:42,080 --> 00:45:46,800 obvious what it does and how to use it. And it might be a really good tool, especially when 434 00:45:46,800 --> 00:45:52,960 you look at transitioning over and you might have a serial queue and might not know how to 435 00:45:52,960 --> 00:45:59,360 transition that over into Swift 6 concurrency. This might be the thing you need in that case. 436 00:45:59,360 --> 00:46:06,400 So that's Queue by Matt Massicotte. And I think that brings us to the end of another episode 437 00:46:06,400 --> 00:46:12,080 of the podcast. It does. So I think this will be the last podcast for this year, 438 00:46:12,080 --> 00:46:20,960 because we're heading, we're absolutely careering towards the holidays. And I have a feeling this 439 00:46:20,960 --> 00:46:27,600 will be the last one for 2024. So thank you so much for listening, even whether you just listened 440 00:46:27,600 --> 00:46:32,000 to this, if this is your first episode you've listened to, or whether you've been with us 441 00:46:32,000 --> 00:46:39,440 since the beginning. I really thank you for sticking with us. And we look forward to giving 442 00:46:39,440 --> 00:46:47,280 you more of the same and even better in 2025. Yeah, exactly. Thank you. And yeah, see you next 443 00:46:47,280 --> 00:46:52,360 time. Bye bye. All right see you next time. Bye bye.