1
00:00:00,000 --> 00:00:03,680
In our previous episode, we had the cutting title,

2
00:00:03,680 --> 00:00:07,520
"Now I'm Worried If Our Metrics Are Correct."

3
00:00:07,520 --> 00:00:10,400
Yes, we did. That was when we were talking to Holly, right?

4
00:00:10,400 --> 00:00:13,120
Yeah. Narrator, they weren't.

5
00:00:13,120 --> 00:00:19,440
They weren't as bad as we feared, though.

6
00:00:19,440 --> 00:00:25,840
So we did indeed have a misconfiguration, but the effect wasn't catastrophic.

7
00:00:27,280 --> 00:00:31,360
And we should say, in our defense, we did test this with a few packages before

8
00:00:31,360 --> 00:00:37,680
making these runs, obviously. But you inevitably miss edge cases when you go from,

9
00:00:37,680 --> 00:00:40,400
you know, like a handful of packages to 7k packages.

10
00:00:40,400 --> 00:00:46,640
But I found it really interesting how that was triggered by our conversation with Holly

11
00:00:46,640 --> 00:00:53,600
when I did a little quiz, right? And Holly went really low in how many packages she thought might

12
00:00:53,600 --> 00:00:59,520
have zero reporting, zero errors. And I think you were pretty close.

13
00:00:59,520 --> 00:01:03,360
Yeah, I think I was within a thousand or something like that.

14
00:01:03,360 --> 00:01:11,920
Yeah. So the percentage I quoted was 53.2% of packages reporting zero errors. After our last

15
00:01:11,920 --> 00:01:20,000
run, it's lower. It's 40.8 packages. So it is a large correction, but it's also not like,

16
00:01:20,720 --> 00:01:30,240
you know, like 10% only. You know, it's like a significant drop, but it is within the ballpark.

17
00:01:30,240 --> 00:01:38,800
There's still issues that we see, right? The latest one had packages that are known to be

18
00:01:38,800 --> 00:01:46,240
Swift 5 compatible, well-known packages that don't build in the Swift toolchain. So they aren't

19
00:01:48,080 --> 00:01:53,680
reporting zero errors because the build fails. So this number is also, there's never going to

20
00:01:53,680 --> 00:01:58,560
be a correct number. We're just going to try and do our best to approach a number that

21
00:01:58,560 --> 00:02:06,000
has a good reflection of what the ecosystem looks like. And that's a matter of both the toolchains

22
00:02:06,000 --> 00:02:10,000
improving over time, because we have to bear in mind, these are preview toolchains.

23
00:02:10,000 --> 00:02:17,840
So they will have issues of their own. And we've actually seen some of them pre-runs in our testing.

24
00:02:17,840 --> 00:02:23,520
And we found some workarounds for those. And there's also, you know, the aspect of packages

25
00:02:23,520 --> 00:02:28,640
working on fixes and having just things that break because of the nature of Swift 6 being

26
00:02:28,640 --> 00:02:34,880
in preview right now. So yeah, that was a little follow up on the episode title.

27
00:02:34,880 --> 00:02:40,640
Well, the most important part is that it didn't change the outcome of the quiz,

28
00:02:40,640 --> 00:02:43,040
and I retain my quiz champion title.

29
00:02:43,040 --> 00:02:45,840
Oh, there we go. Points awarded.

30
00:02:46,400 --> 00:02:52,960
We should actually talk about two other data points on that chart that we're going to,

31
00:02:52,960 --> 00:02:57,280
if you've been following along through pull requests, because it's not live on the site

32
00:02:57,280 --> 00:03:03,680
yet, you may have noticed that there are two data points at the beginning of the current chart,

33
00:03:03,680 --> 00:03:08,800
which are very out of sync with the rest of the data points that we have there.

34
00:03:08,800 --> 00:03:12,640
And we're going to remove those two data points because

35
00:03:13,760 --> 00:03:19,360
there's always a question when you put a chart like this, is it going to mislead people? And

36
00:03:19,360 --> 00:03:22,560
that's what we do not want to mislead people. That's not our intention.

37
00:03:22,560 --> 00:03:30,320
The first two runs of the compatibility testing that we did, we were only able to get working

38
00:03:30,320 --> 00:03:38,640
Swift build commands rather than Xcode build commands. So that took us down from our current

39
00:03:39,840 --> 00:03:47,040
list of platforms, including iOS and watchOS and tvOS and iOS and MacOS using Xcode.

40
00:03:47,040 --> 00:03:56,880
And it took us down to Linux and MacOS using Swift build. And that was interesting data to

41
00:03:56,880 --> 00:04:03,520
have at the time because it gave us, well, it gave us a sense of some numbers, but also it

42
00:04:03,520 --> 00:04:09,680
lets us test this process of running all of the builds past the Swift 6 tool chain. So it was

43
00:04:09,680 --> 00:04:15,920
important that we did those, but actually it's those two data points that are misleading. And so

44
00:04:15,920 --> 00:04:21,360
we're going to knock them off the beginning of the chart so that the chart doesn't mislead.

45
00:04:21,360 --> 00:04:26,400
It looks like everything got a lot worse on the third one, but actually in reality,

46
00:04:26,400 --> 00:04:30,000
we just didn't test all the platforms until the third one.

47
00:04:30,000 --> 00:04:36,880
Yeah, exactly. We had like a snapshot slice of the full picture really only in the first two runs.

48
00:04:36,880 --> 00:04:42,240
And as you say, it was really useful to get us set up and running. I think it's always great to

49
00:04:42,240 --> 00:04:48,320
just get the process going right in that case, especially because it's quite involved. Just the

50
00:04:48,320 --> 00:04:56,000
fact of the act of running it was really helpful, but the data isn't. I mean, the option obviously

51
00:04:56,000 --> 00:05:00,960
would be to just keep doing that only, right? Then it would be comparable, but that's also not

52
00:05:00,960 --> 00:05:06,560
a good result, right? To only look at Swift PM builds across those two platforms. So since we

53
00:05:06,560 --> 00:05:11,680
can't go back and run Xcode builds for the old ones, that's really the only option is to just

54
00:05:11,680 --> 00:05:16,720
discard those and just start from what we've got.

55
00:05:16,720 --> 00:05:23,040
I mean, we kind of could because we could install the old. Oh no, we can't because those old,

56
00:05:23,040 --> 00:05:26,240
it was, yeah, we couldn't. Yeah, there was a couple of changes with those tool changes. Yeah,

57
00:05:26,240 --> 00:05:32,880
yeah. It's just not possible to do it yet. So, and I think that page is going to go live

58
00:05:32,880 --> 00:05:42,800
fairly shortly. I think maybe this week even we might put that page live to start publicly

59
00:05:42,800 --> 00:05:47,040
tracking the Swift 6 status of all our packages.

60
00:05:47,840 --> 00:05:54,400
Yeah, that's great. And we'll probably have another data point in two weeks. So I looked

61
00:05:54,400 --> 00:06:01,360
a bit at the calendar to plan these a bit. And I think every two week cadence is realistic and

62
00:06:01,360 --> 00:06:07,760
doable and interesting as well to space out the points a bit and give us a view of trends and

63
00:06:07,760 --> 00:06:09,040
stuff.

64
00:06:09,040 --> 00:06:14,800
And part of what is making that two weeks cadence feasible is some other news that we're not going

65
00:06:14,800 --> 00:06:21,520
to talk about in depth today because we will talk about it in depth on a future episode. But I think

66
00:06:21,520 --> 00:06:28,880
it's worth a little tease now. We have a new macOS build environment for all of our compatibility

67
00:06:28,880 --> 00:06:38,400
builds. So one of the ironies of our build system is that the Linux builds were more isolated and

68
00:06:38,400 --> 00:06:46,160
more independent of their environment than our macOS builds because our Linux builds use Docker.

69
00:06:46,160 --> 00:06:51,600
And so every time we do a Linux build, it spins up a new Docker container and does the build and

70
00:06:51,600 --> 00:06:57,120
then drops the container and everything's back to as it was before. But with our macOS build

71
00:06:57,120 --> 00:07:07,120
system, we were running bare metal Macs. And of course, we then run lots of builds past the same

72
00:07:08,000 --> 00:07:12,160
versions of Xcode on the same machines, but they don't have isolation. They don't have

73
00:07:12,160 --> 00:07:19,680
the kind of the... Well, it is isolation. That's what they don't have. They don't have isolation.

74
00:07:19,680 --> 00:07:30,240
And we've been working with Mac Stadium for the last couple of months to fix that problem,

75
00:07:30,240 --> 00:07:38,800
basically. So we're moving to an Orca-based build system, which is their Kubernetes

76
00:07:38,800 --> 00:07:47,120
orchestration system over, but for macOS host machines. And so we will talk about this more

77
00:07:47,120 --> 00:07:53,600
and the whole setup because it's actually quite a fascinating process. And we've ended up with this

78
00:07:54,320 --> 00:08:00,080
quite robust build system out of it. But one thing that is... These Swift 6 builds that we've

79
00:08:00,080 --> 00:08:06,240
been doing have been an amazing test of that system because the last two runs of the Swift 6

80
00:08:06,240 --> 00:08:12,080
compatibility builds have all been through our Orca cluster now. And it does give us complete

81
00:08:12,080 --> 00:08:20,400
isolation. So for every single Swift build or Xcode build that we do, we spin up a new virtual

82
00:08:20,400 --> 00:08:27,520
machine, a full VM, not a Docker container because we need the full VMs. And we do the build, and

83
00:08:27,520 --> 00:08:32,160
then the VM gets destroyed and goes back to the base image. And then the next build starts and

84
00:08:32,160 --> 00:08:40,160
starts a whole new VM. And we can have VMs configured for different operating systems like

85
00:08:40,160 --> 00:08:50,080
Xcode 14s need Sonoma... No, I'm getting that wrong. Some operating systems need some

86
00:08:50,080 --> 00:08:56,320
specific versions of Xcode. And we can have that. So we can have like a Swift 5.9 image that has

87
00:08:56,320 --> 00:09:01,280
the right operating system and the right version of Xcode. What's even more funny about what I

88
00:09:01,280 --> 00:09:06,640
just said is that I was the one set those up. So there's no excuse for me not to know the pairings,

89
00:09:06,640 --> 00:09:12,960
but they're hard to remember. So yeah, we've been running this as a kind of test

90
00:09:12,960 --> 00:09:18,560
for the last couple of runs. Our current production builds are still on our existing

91
00:09:19,120 --> 00:09:23,600
system. But I think we're at the point where we could switch over to that new system

92
00:09:23,600 --> 00:09:30,640
eminently. Yeah, absolutely. Because we are effectively we ran from the same

93
00:09:30,640 --> 00:09:37,280
queue, we triggered builds on both systems in parallel. So all we did in our preview runs is

94
00:09:37,280 --> 00:09:43,440
that Swift 6 builds we sent to Orca, while all the other builds went to the old build system.

95
00:09:43,440 --> 00:09:49,520
And changing the targeting is just a matter of changing some labels in the

96
00:09:49,520 --> 00:09:56,400
runner setup to send the other builds to Orca as well, or just through them wherever.

97
00:09:56,400 --> 00:10:04,160
Again, we shouldn't talk too much about this, but this enables us not only to get more

98
00:10:04,160 --> 00:10:10,320
reproducible results and more stable results because of the isolation and the security,

99
00:10:10,320 --> 00:10:16,000
it means that those builds can't do anything to our systems, which would have theoretically been

100
00:10:16,000 --> 00:10:21,840
possible in our current system. We were lucky never to have that problem, but we were a little

101
00:10:21,840 --> 00:10:26,400
open to it, even though they ran on non-privileged accounts and all, there was other things like

102
00:10:26,400 --> 00:10:34,160
that that we'd done to lessen the impact of that. But it also allows us to plan more features for

103
00:10:34,160 --> 00:10:42,160
the future. Like for example, we could potentially include more dependency setup inside the virtual

104
00:10:42,160 --> 00:10:48,480
machines because it wouldn't be necessary for every build to run in that environment. So we're

105
00:10:48,480 --> 00:10:54,080
not announcing anything there yet, we're not even committing to that feature, but it does enable

106
00:10:54,080 --> 00:11:02,400
interesting future directions. Yeah, and that's actually another point where Linux is in the

107
00:11:02,400 --> 00:11:06,400
advantage currently, because that's what we actually support there. We have a couple of

108
00:11:06,400 --> 00:11:12,960
repositories that need specific Linux packages to be system OS level packages to be installed in

109
00:11:12,960 --> 00:11:20,160
order for them to build successfully. And the way we allow that is we allow them to specify

110
00:11:20,160 --> 00:11:26,400
pre-built underlying images that are used instead of this Swift 6 image to run the builds,

111
00:11:26,400 --> 00:11:32,720
so that they have their environment set up as they expect. And these are just used for those

112
00:11:32,720 --> 00:11:38,160
packages, so they don't influence other packages. And that's a great feature and great flexibility

113
00:11:38,160 --> 00:11:46,000
that we might potentially gain on the macOS side as well. I think one of the problems that's always

114
00:11:46,000 --> 00:11:52,240
going to plague the macOS side a bit is that these images are just huge versus, I mean, the Linux

115
00:11:52,240 --> 00:11:58,720
ones aren't tiny either, but Mac takes that to a whole new level in sheer image size.

116
00:11:58,720 --> 00:12:02,080
I believe the images are currently 90 gigabytes.

117
00:12:02,080 --> 00:12:08,480
Yeah, that's almost two orders of magnitude more than, well, it might even be more than two orders

118
00:12:08,480 --> 00:12:11,520
of magnitude than the Linux images. So that's significant.

119
00:12:11,520 --> 00:12:17,760
Which makes it even more remarkable that these VMs spin up in about three seconds.

120
00:12:19,120 --> 00:12:24,080
Yeah, or even the cold start, you know, when the image needs to be fetched isn't that terrible

121
00:12:24,080 --> 00:12:24,580
either.

122
00:12:24,580 --> 00:12:31,440
Yeah, cold start is about three minutes, isn't it? Yeah. Anyway, we'll spoil talking about this

123
00:12:31,440 --> 00:12:35,040
on a full episode if we talk more about it. So let's move on.

124
00:12:35,040 --> 00:12:42,320
Let's do it. There's another bit of news that is sort of related to our last episode,

125
00:12:42,320 --> 00:12:49,920
and that's an accepted proposal, SE0435, which allows setting Swift language version per target.

126
00:12:49,920 --> 00:12:54,080
Now, if you recall, we talked about this in our episode with Holly.

127
00:12:54,080 --> 00:13:00,880
We mentioned there that you need to opt into Swift 6 language mode in order to fully adopt

128
00:13:00,880 --> 00:13:05,600
concurrency checking or set the flags, but opting into the language mode is the easiest way to do

129
00:13:05,600 --> 00:13:12,080
that. Now, previously, this was only possible on the full package level. So you could, this

130
00:13:12,080 --> 00:13:17,200
was an option in the package manifest. You could set the language version, but it would apply to

131
00:13:17,200 --> 00:13:22,320
all the targets in your package. And with this proposal, you can actually do this on a target

132
00:13:22,320 --> 00:13:27,440
by target basis, which is great if you want to transition slowly. You know, you might have lots

133
00:13:27,440 --> 00:13:33,360
of targets, some of which are harder to transition over, and then you can just pick your battles,

134
00:13:33,360 --> 00:13:39,280
switch the ones that you can, you know, want to start with early and then leave out the ones that

135
00:13:39,280 --> 00:13:46,720
might be more complicated to do. So that's a great thing to see in place. So that's accepted.

136
00:13:46,720 --> 00:13:54,000
And I think that automatically comes with a implementation and should be in tool chains soon.

137
00:13:54,000 --> 00:13:55,280
- Fantastic.

138
00:13:55,280 --> 00:14:00,640
- Right. In other news, do you know what a flipper zero is?

139
00:14:00,640 --> 00:14:06,080
- It's what a dolphin does when it wants to get your attention.

140
00:14:06,080 --> 00:14:14,000
- Right. I'm not sure how that relates to Swift, but this flipper zero I'm talking about is a

141
00:14:14,000 --> 00:14:17,760
portable multi-tool for pen testers and geeks in a toy-like body.

142
00:14:17,760 --> 00:14:21,520
- Oh, that kind of flipper zero. Of course I knew what that one was.

143
00:14:21,520 --> 00:14:22,320
- Yeah, there you go.

144
00:14:22,320 --> 00:14:24,400
- I thought that one was too obvious. Yeah.

145
00:14:24,400 --> 00:14:32,240
- Right. So it's a little microcontroller device with a screen and a D-pad, and it has a C API,

146
00:14:32,240 --> 00:14:36,400
and they can probably see where this is going. This is another one for the section,

147
00:14:36,400 --> 00:14:44,560
Swift in unusual places. Samar Sunkaria posted on the Swift forums about this, a proof of concept

148
00:14:44,560 --> 00:14:51,920
to target this device and, you know, add a Swift API layer on top of that C API to be able to build

149
00:14:51,920 --> 00:14:57,520
apps for this, or, you know, ship binaries to this microcontroller thing. It has a display

150
00:14:57,520 --> 00:15:03,200
and a D-pad, so I'm not sure actually what you could, you could probably ship Doom on it,

151
00:15:03,200 --> 00:15:08,000
but this might be interesting in terms of getting more stuff on it to do, you know,

152
00:15:08,000 --> 00:15:12,720
what this is actually intended for, like pen testing and that sort of thing. I found that

153
00:15:12,720 --> 00:15:20,480
interesting. I found it especially interesting that this, we've seen this embedded Swift popped

154
00:15:20,480 --> 00:15:27,200
up, was it like three, four months ago? And since then, there've been like three, at least three

155
00:15:27,200 --> 00:15:35,440
proposals or implementations I can think of where people added APIs using Swift over C APIs and

156
00:15:35,440 --> 00:15:40,480
shipping this to these microcontrollers. So that's really interesting. And I hope that trend continues

157
00:15:40,480 --> 00:15:47,600
and becomes more mainstream. I found that really nice to see that this is really being picked up.

158
00:15:47,600 --> 00:15:51,360
- It's always nice to see it arrive on a new platform. Yeah.

159
00:15:51,360 --> 00:15:56,720
- Yeah. And I think it goes to show that this is really powerful to be able to

160
00:15:56,720 --> 00:16:04,640
sort of insulate people from the C API. I mean, I get why these ship with C APIs, because that's

161
00:16:04,640 --> 00:16:12,000
the most platform agnostic thing to do, right? Or I guess one of the most platform agnostic things

162
00:16:12,000 --> 00:16:18,320
to do as a vendor for this thing, but then the ease with which apparently, you know,

163
00:16:18,320 --> 00:16:25,840
people can layer on top richer, you know, or different language adaptations that make it

164
00:16:25,840 --> 00:16:34,080
easier to work with. I think that's a superpower. And I hope that gets used a lot and becomes more

165
00:16:34,080 --> 00:16:40,000
popular. - And you mentioned running Doom on it.

166
00:16:40,560 --> 00:16:47,840
That reminded me of a story I saw recently that somebody got Doom running on gut bacteria.

167
00:16:47,840 --> 00:16:53,360
- On what? - Which was a story, gut bacteria.

168
00:16:53,360 --> 00:17:00,960
- Like in a simulation or actual? - No, in actual gut bacteria

169
00:17:00,960 --> 00:17:10,400
at a resolution of 32 by 48 pixels. Unfortunately, the cells take 70 minutes to illuminate and

170
00:17:10,400 --> 00:17:18,480
8 hours and 20 minutes to return to dark. But through manipulation of gut bacteria,

171
00:17:18,480 --> 00:17:21,360
you could, they did get Doom running on the gut bacteria.

172
00:17:21,360 --> 00:17:25,120
- So in terms of frame rate, that's not gonna be great, is it?

173
00:17:25,120 --> 00:17:32,560
- It does say here, it says, given that the original game runs at 35 frames per second,

174
00:17:32,560 --> 00:17:36,720
the cell display would take 599 years to play Doom from start to finish.

175
00:17:36,720 --> 00:17:40,240
- Oh God, that still sounds quicker than I would have thought.

176
00:17:40,240 --> 00:17:47,440
- We'll include, as a completely relevant link, we'll include a link to that in the show notes.

177
00:17:47,440 --> 00:17:53,520
- Fantastic. - But you really can play Doom on anything, yeah.

178
00:17:53,520 --> 00:18:00,240
- That's amazing. You've probably seen the one where they ran, I think it's Doom,

179
00:18:00,240 --> 00:18:07,680
where they run it on the CPU load widget on a supercomputer.

180
00:18:07,680 --> 00:18:11,600
- Right, yes. - So someone has a panel up with however

181
00:18:11,600 --> 00:18:18,800
many CPUs that thing has, arrange them in a grid, and then just by creation of load on the system,

182
00:18:18,800 --> 00:18:25,680
they light up the pixels. It's kind of nuts. - Yeah, I love that it has become a thing.

183
00:18:25,680 --> 00:18:33,600
- Yeah, great. We got another one for our different segment, which is Swift on non-Apple platforms.

184
00:18:33,600 --> 00:18:39,360
And this is a post by Jeremy Dave from the Browser Company about Swift tooling on Windows.

185
00:18:39,360 --> 00:18:43,680
You may have seen this one, Dave. - This was a few weeks back, right?

186
00:18:43,680 --> 00:18:53,200
- I've seen this last week. This might be a different post than you're thinking.

187
00:18:53,200 --> 00:18:56,080
- Yeah. - So this is specifically about Swift tooling.

188
00:18:56,080 --> 00:19:02,800
It's not about how they implemented Arc, which is their browser and the Browser's Company

189
00:19:02,800 --> 00:19:08,560
main product, which is known for. It's implemented in Swift on Windows. So they ship this whole

190
00:19:08,560 --> 00:19:14,320
thing. This is about the state of tooling on Windows. And it sounds like things are going

191
00:19:14,320 --> 00:19:19,600
really well over there. And I've been actually using Arc on Windows for a bit recently,

192
00:19:19,600 --> 00:19:27,760
and it's really a great app. It works great. And I'm no expert on what makes Windows app feel

193
00:19:27,760 --> 00:19:32,880
truly native, but it certainly looks absolutely fine to me. I wouldn't be able to tell the

194
00:19:32,880 --> 00:19:39,600
difference. - Well, they are using the native APIs.

195
00:19:39,600 --> 00:19:46,000
They're using Swift bindings into WinRT, which is the native Windows API.

196
00:19:46,000 --> 00:19:49,200
- Yeah, exactly. - So it should feel native.

197
00:19:49,200 --> 00:19:53,920
- Yeah, it should. Absolutely. I just wonder, sometimes it might not cover everything. So

198
00:19:53,920 --> 00:19:59,760
you might see some oddities because certain OS level things that are typical aren't available,

199
00:19:59,760 --> 00:20:03,600
and there might be workarounds. That's the sort of thing I was thinking about.

200
00:20:03,600 --> 00:20:07,040
- Yes. - But there's none of that. But then again,

201
00:20:07,040 --> 00:20:12,880
I probably wouldn't be a good judge of it anyway. But the post isn't really about Arc.

202
00:20:13,920 --> 00:20:19,040
I don't think it even mentions Arc. It talks about what tools they use to develop Arc,

203
00:20:19,040 --> 00:20:27,920
which is obviously VS Code as the editor, as the IDE. They go on to talk about the debugging,

204
00:20:27,920 --> 00:20:35,280
what they use, LLDB, but also that you can use Windows native debugging tools that aren't

205
00:20:35,280 --> 00:20:43,040
specific to Swift, and they can be made to work with this. And they also go a bit into

206
00:20:43,040 --> 00:20:49,760
how you can use obviously Swift PM, and that's what they use mainly to build the binaries. But

207
00:20:49,760 --> 00:20:54,160
you can also use CMake if you have special requirements that aren't covered by Swift PM,

208
00:20:54,160 --> 00:21:01,280
that sort of thing. And that might be related to Windows APIs that you need to integrate with,

209
00:21:01,280 --> 00:21:06,560
or Windows libraries you need to integrate with, or issues that might need to work around,

210
00:21:07,200 --> 00:21:14,160
because on Windows there's a 64K limit in terms of, I think, how many symbols you can export in a

211
00:21:14,160 --> 00:21:20,240
DLL. And for that reason, you might... I think that's the reason why you need CMake to build,

212
00:21:20,240 --> 00:21:26,960
and to strip out stuff that you don't need to actually ship in a DLL. It's an interesting post,

213
00:21:26,960 --> 00:21:33,280
even if you're not developing in Windows, just to see how stuff works over there. And yeah,

214
00:21:33,280 --> 00:21:40,560
I found it a nice description of how that goes. And I'm actually particularly interested,

215
00:21:40,560 --> 00:21:47,040
because I'll start poking at this a bit with Swift on Windows in the near future.

216
00:21:47,040 --> 00:21:56,880
One interesting other thing I saw mentioned is they talk about tools, Swift tools, that are

217
00:21:56,880 --> 00:22:02,880
shipped with a compiler. And one thing in particular is Swift Inspect, which I don't think I'd heard

218
00:22:02,880 --> 00:22:08,000
about before. And there's a subdirectory inside the Swift compiler with tools, and that's where

219
00:22:08,000 --> 00:22:15,280
this lives. It's not a separate package. It is a package, but it's embedded in the Swift repository.

220
00:22:15,280 --> 00:22:20,880
And it's a tool that allows you to inspect a live running Swift process and dump some info. It's not

221
00:22:20,880 --> 00:22:27,680
like... The info is very specific. It's quite niche. So you can, you know, like array information and

222
00:22:27,680 --> 00:22:32,400
cache information, that sort of thing. But I found it interesting that there's stuff in the compiler

223
00:22:32,400 --> 00:22:38,160
that's shipped as Swift packages. And it might also be interesting for people who are poking

224
00:22:38,160 --> 00:22:42,640
around and might want to see how that sort of stuff is implemented. That's why I wanted to

225
00:22:42,640 --> 00:22:50,080
give a shout out to that particular tool. So interesting stuff there coming out on non-Apple

226
00:22:50,080 --> 00:22:51,280
platforms. Yeah, it is.

227
00:22:51,280 --> 00:23:01,280
Yeah, finally, a bit of news that is about performance benchmarking. So it was a long

228
00:23:01,280 --> 00:23:06,560
Swift forum thread about performance benchmarking. And I did all this one. Yeah,

229
00:23:06,560 --> 00:23:11,760
you saw that one. Yeah, I think it was hard to miss. I found it really interesting for a number

230
00:23:11,760 --> 00:23:21,280
of reasons. And they're probably not all obvious. It all started when Axel Rost posted a benchmark

231
00:23:21,280 --> 00:23:26,320
result and asked for help on the Swift forums. And it's about understanding the results that

232
00:23:26,320 --> 00:23:34,240
he saw, which were weird. So he used Vapor, a Swift server framework to run the performance.

233
00:23:34,240 --> 00:23:41,120
I should say what the performance benchmark is about. This is about running a web server,

234
00:23:41,120 --> 00:23:48,160
web framework, and to test its requests throughput. You know, how many requests can it handle per

235
00:23:48,160 --> 00:23:59,280
second and compare different languages and frameworks like Node, PHP, I think, and Python

236
00:23:59,280 --> 00:24:06,480
are the three other language framework combinations he looked at. And he saw interesting results in

237
00:24:06,480 --> 00:24:14,000
general, but in particular, he saw that Vapor Swift was dropping 1.5% of all requests, which

238
00:24:14,000 --> 00:24:19,520
is odd and off the start without any load. And that's the question he asked on the Swift forums.

239
00:24:19,520 --> 00:24:27,120
And if you've ever seen a nerd sniping of epiphyte portions, that was one. Because everyone sort of

240
00:24:27,120 --> 00:24:34,960
dropping across. Yeah, this was. Yeah. And then people obviously also looked at the performance,

241
00:24:34,960 --> 00:24:41,200
the benchmark itself, because that was also quite low. Swift wasn't doing great in terms of

242
00:24:42,160 --> 00:24:50,000
request throughput, which seemed odd, because there was nothing really that should make it,

243
00:24:50,000 --> 00:24:54,160
you know, it should have done better, I think. And it did in the end.

244
00:24:54,160 --> 00:25:01,680
But it was really interesting to see how there was not one single thing that was wrong,

245
00:25:01,680 --> 00:25:08,000
and obviously wrong. And it took a lot of really skilled people to poke at it to find out what was

246
00:25:08,000 --> 00:25:15,200
going on. And I think it's really hard to summarize the results here, because there were so,

247
00:25:15,200 --> 00:25:22,640
so many interesting outcomes and questions being asked and investigated and

248
00:25:22,640 --> 00:25:30,240
sort of assumptions being tested and revised. It was an interesting thread.

249
00:25:30,240 --> 00:25:36,880
I think one of the things that came out of it was your benchmark methodology is really important

250
00:25:36,880 --> 00:25:42,560
and was somewhat problematic here, because he was creating load as a benchmark and then

251
00:25:42,560 --> 00:25:47,680
testing something slightly different when he's what he thought he was testing.

252
00:25:47,680 --> 00:25:56,160
And that was partly a problem was on Swift that in order to create the load, he used a third party

253
00:25:56,160 --> 00:26:03,040
dependency in order to compute the thing that he, he will use the Fibonacci sequence to create the

254
00:26:03,040 --> 00:26:08,560
load. But the package used to do that on Swift wasn't actually well maintained. It was quite a

255
00:26:08,560 --> 00:26:13,840
lot slower than the other implementations, which use native highly optimized

256
00:26:13,840 --> 00:26:20,560
implementations of big int to do that thing. So that was sort of a not a like for like comparison.

257
00:26:20,560 --> 00:26:28,240
Then Vapor had a default config, which wasn't ideal for this sort of test scenario. And perhaps

258
00:26:28,240 --> 00:26:34,560
even in general, there were some system limits on the OS's that he tested that were too tight,

259
00:26:34,560 --> 00:26:40,160
like maximum file descriptors and maximum outstanding socket connections being allowed.

260
00:26:40,160 --> 00:26:44,560
So that was interesting. And that wasn't just Mac OS, also Linux, these were,

261
00:26:44,560 --> 00:26:52,960
these should have been tweaked in order to make this a decent, normal test, you know,

262
00:26:52,960 --> 00:26:56,960
like you would normally test this because you don't want to test the system limits, right?

263
00:26:56,960 --> 00:27:04,480
You want to test the framework limits. So that was just, I think I listed five there,

264
00:27:04,480 --> 00:27:08,640
there might have been more, but it's just a really interesting thread about performance

265
00:27:08,640 --> 00:27:15,040
benchmarking and like how predictably it'll attract lots of, lots of interesting discussion.

266
00:27:15,040 --> 00:27:21,680
And it was, I think it is notable that this was a good discussion. It was a really interesting

267
00:27:21,680 --> 00:27:26,480
discussion. Well, that's what I was going to say. Yeah. I thought it was really one thing that was

268
00:27:26,480 --> 00:27:32,320
really struck me in reading. I didn't read the nitty gritty of every post on it because it was

269
00:27:32,320 --> 00:27:39,120
an extremely long thread in the end. But what I thought was really nice was how not only the

270
00:27:39,120 --> 00:27:44,560
people from the Swift side, but the benchmark, the person who was running the benchmarks

271
00:27:44,560 --> 00:27:54,080
was willing to accept that neither side was perfect in their initial kind of testing.

272
00:27:54,080 --> 00:27:58,800
Where sometimes, and I'm not accusing this of anyone in specific here, but sometimes

273
00:27:58,800 --> 00:28:03,760
people produce a benchmark to prove their point. And once their point is proven, it's hard to,

274
00:28:03,760 --> 00:28:09,440
it's hard to move them away from that original kind of benchmark. But I thought this was a

275
00:28:09,440 --> 00:28:16,480
really great example of collaboration between people. Yeah. Yeah. And it's also, I think it's

276
00:28:16,480 --> 00:28:23,280
also the proposition of the benchmark is really important because there's different ways of going

277
00:28:23,280 --> 00:28:30,160
at it. You can test default config and make your argument. Well, that's what people are going to

278
00:28:30,160 --> 00:28:35,600
use. Right? I mean, lots of people, obviously Google, Apple, aren't going to use it like that

279
00:28:35,600 --> 00:28:42,080
because they know how to test the best possible case. So you think you always need to have almost

280
00:28:42,080 --> 00:28:49,840
like two benchmarks. One is the default, which people will use and which will be seen in production

281
00:28:49,840 --> 00:28:53,920
because that's what people start off with. And then perhaps at the other end of the spectrum,

282
00:28:53,920 --> 00:28:58,880
the one that's tuned to the guilds and everything is taken care of. And, you know, every,

283
00:28:58,880 --> 00:29:05,120
every little bit is tweaked and that's what you look at as well. But I think neither is perfect

284
00:29:05,120 --> 00:29:13,440
in assessing what will be the result for you to choose a framework because, I mean, we run a web

285
00:29:13,440 --> 00:29:22,080
service and we use vapor quite a bit and we sort of look at stuff, but we are using the defaults.

286
00:29:22,080 --> 00:29:27,920
I don't think there's a lot that we've tweaked. So if there's anything that would, you know,

287
00:29:27,920 --> 00:29:32,800
we would benefit of the defaults changing as a result of this. And I think that's why these

288
00:29:32,800 --> 00:29:38,720
default testing benchmarks are also really important because you have a huge impact if

289
00:29:38,720 --> 00:29:42,640
you make improvements there, because all the people using the defaults will see that that

290
00:29:42,640 --> 00:29:50,560
benefit trickle down. But I think the real summary should probably be only trust the benchmark where

291
00:29:50,560 --> 00:29:57,760
your favorite language framework comes out on top, isn't it? Well, that was kind of my point. Yeah.

292
00:29:57,760 --> 00:30:02,240
Once you've proven, once you've proven what you thought you were going to prove, why,

293
00:30:02,240 --> 00:30:06,080
why do anything else? Right. Stop right there. Exactly. Yeah. Yeah.

294
00:30:07,760 --> 00:30:13,840
Should we do some package recommendations? Yeah, let's do it. Do you want to kick us off?

295
00:30:13,840 --> 00:30:22,240
Because I really have only two this week. That's okay. We can do two each. I can kick us off with

296
00:30:22,240 --> 00:30:34,320
a package called Swift Chess Neo by Navan Chauhan, which is a cross-platform Swift chess library.

297
00:30:34,320 --> 00:30:39,920
Now, I'm not a big chess player. I can just about struggle through a game, but

298
00:30:39,920 --> 00:30:48,800
don't talk to me about tactics. And this is a work in progress library, which is actually

299
00:30:48,800 --> 00:30:57,760
a fork of a package called Sage by, I should have had this information ready, by Nikolai Vazquez,

300
00:30:59,440 --> 00:31:10,960
which is a no longer maintained Swift package for a cross-platform chess. And this Swift Chess Neo

301
00:31:10,960 --> 00:31:18,080
is a fork of that along with some patches from someone. And it also adds Swift UI views.

302
00:31:18,080 --> 00:31:25,120
But what does this package do? It does much more than just visualize chess, which is the Swift UI

303
00:31:25,120 --> 00:31:31,200
bit of it. It does game management. It does move execution. It has all the rules encoded, of course.

304
00:31:31,200 --> 00:31:37,680
It has move generation. So it would be possible to build from this package into a chess game. And in

305
00:31:37,680 --> 00:31:46,000
fact, the person does say, Navan does say, I'm actively developing Swift Chess Neo while writing

306
00:31:46,000 --> 00:31:54,960
iWatchChess for iOS and macOS. So this is the core logic for an app which is being produced at

307
00:31:54,960 --> 00:32:01,680
the moment. And it can also do visualizations in ASCII. So you can look at the board while you're

308
00:32:01,680 --> 00:32:07,680
debugging and it will print out an ASCII representation of the chess board. And it

309
00:32:07,680 --> 00:32:14,160
understands all of the chess notations so that you can input your chess moves in with a notation

310
00:32:14,160 --> 00:32:21,200
rather than having to deal with an API, which would not be as efficient to kind of code against.

311
00:32:21,200 --> 00:32:27,600
And I thought this was just a really nice example of a little package that most people won't see.

312
00:32:27,600 --> 00:32:34,960
And yeah, if you have any interest in chess whatsoever, I think you'd find something

313
00:32:34,960 --> 00:32:41,920
interesting here. So the package is called Swift Chess Neo. And Neo is...

314
00:32:41,920 --> 00:32:42,960
N-E-O, yeah.

315
00:32:42,960 --> 00:32:49,120
N-E-O, yes. Because until the world halfway through of your description, I was sitting

316
00:32:49,120 --> 00:32:52,560
here thinking, what on earth does chess have to do with Neo?

317
00:32:52,560 --> 00:32:54,320
How is the network going to get involved?

318
00:32:54,320 --> 00:33:01,040
Yes. Until you said Swift UI, then that's when it sort of started clicking. And I thought,

319
00:33:01,040 --> 00:33:05,040
oh, right, the other Neo. That's really interesting.

320
00:33:05,040 --> 00:33:10,320
In Swift 7, all network requests will have to go through a chess board representation before being

321
00:33:11,600 --> 00:33:12,160
executed.

322
00:33:12,160 --> 00:33:17,600
I'm really curious what the transcription is going to make up this segment.

323
00:33:17,600 --> 00:33:30,480
Yes. Yes, that will be a good test of Whisper's AI. But yeah, it looks great. And it's not N-I-O,

324
00:33:30,480 --> 00:33:32,000
it's Neo, N-E-O.

325
00:33:32,000 --> 00:33:33,600
Excellent. That's interesting.

326
00:33:33,600 --> 00:33:34,880
Like the man from the Matrix.

327
00:33:36,400 --> 00:33:45,920
Nice. Right. My first pick is called Swift Security by Dmitry Zarov. And it's a Swift API

328
00:33:45,920 --> 00:33:51,600
layer for Apple Security Framework. So that's keychain API, shared web credentials, API, etc.

329
00:33:51,600 --> 00:33:59,280
And so I've been using a sort of a keychain wrapper in some of my command line tools. And

330
00:33:59,280 --> 00:34:05,200
that's sort of like a wrapper. It's just a single file that abstracts over the keychain APIs,

331
00:34:05,200 --> 00:34:13,680
which are a bit awkward. They're very C-like. I'm not even sure if there's any glue in between,

332
00:34:13,680 --> 00:34:19,040
or if you're really just calling into the C directly. But you know the ones I'm talking

333
00:34:19,040 --> 00:34:28,240
about, right? The sec item stuff where it's like a really non-Swifty API. So I had this file. It's

334
00:34:28,240 --> 00:34:33,440
been a while since I wrote this. And I would probably switch to this instead, which has a

335
00:34:33,440 --> 00:34:39,680
really nice Swift API, not just for the keychain parts of it, but also all these other parts of

336
00:34:39,680 --> 00:34:47,200
security framework. So it looks like a really complete wrapper around this. And yeah, a nice

337
00:34:47,200 --> 00:34:52,720
package for this. And I know there's others. The package index might be a nice place to look

338
00:34:52,720 --> 00:34:57,280
around if you have needs for that. You might not need the full security framework, maybe just the

339
00:34:57,280 --> 00:35:03,280
keychain API. But this is one that does all of it and might be worth checking out. So that's Swift

340
00:35:03,280 --> 00:35:13,200
security by Dimitri Zarov. It's interesting that the API is where, you know, Apple could have made

341
00:35:13,200 --> 00:35:22,080
a new keychain and security API that fitted in slightly better with Swift. And in those areas

342
00:35:22,080 --> 00:35:26,640
where that hasn't yet been done, or it's maybe not been done to the community's satisfaction,

343
00:35:26,640 --> 00:35:34,000
you'll see a collection of packages. And there are so many, there are so many keychain packages.

344
00:35:34,000 --> 00:35:39,520
Actually, I wonder if Apple could use that as an indication of where they need to focus attention.

345
00:35:39,520 --> 00:35:45,520
- Absolutely. It's a blossoming of packages on the fertile ground of, obviously, APIs, isn't it?

346
00:35:45,520 --> 00:35:51,920
- Exactly. Yeah. But yes, there are lots of them, but this one sounds like a good one.

347
00:35:51,920 --> 00:35:52,720
- Yeah.

348
00:35:52,720 --> 00:36:05,040
- My next package is by David Beck and it's called Swift Glob. And it's a native implementation

349
00:36:05,040 --> 00:36:12,480
of Glob pattern matching. So the Glob pattern matching that you can do in a file system,

350
00:36:12,480 --> 00:36:18,400
where you can do like star, star, star, star, dot, Swift or whatever. It brings that into

351
00:36:20,880 --> 00:36:26,800
a Swift UI, not your search UI, but a Swift user interface, an API user interface,

352
00:36:26,800 --> 00:36:35,680
where you can very quickly include and exclude Globs from a search in a directory. So you pass

353
00:36:35,680 --> 00:36:42,720
it a directory, you pass it in a set of patterns to include and a set of patterns to exclude,

354
00:36:42,720 --> 00:36:50,080
and you would get back a list of files that match the combined set of everything that you've passed

355
00:36:50,720 --> 00:36:58,000
to it. And I think there's obviously lots of ways to filter the files you get back from the

356
00:36:58,000 --> 00:37:05,280
file system, but Globs are something that have been around for a long time and they're a really

357
00:37:05,280 --> 00:37:12,240
efficient way to represent file system searches that I don't think anything else has come close to.

358
00:37:12,240 --> 00:37:17,360
So it's nice to be able to use that inside a Swift application.

359
00:37:17,360 --> 00:37:22,640
- Yeah, it's nice, right? Because it's just familiar, right? You know immediately how to

360
00:37:22,640 --> 00:37:28,160
use that, but without understanding, you know, the regex syntax and that sort of stuff. I mean,

361
00:37:28,160 --> 00:37:34,000
probably if you have very specific needs in filtering, you might need more, but it's just

362
00:37:34,000 --> 00:37:39,680
such a well understood concept that it's nice to see that being available. Nice.

363
00:37:39,680 --> 00:37:48,800
- And so it's a fairly new package and it only has nine stars. So if you are interested in Globs,

364
00:37:48,800 --> 00:37:55,680
go and give it a star on GitHub. Because it's the kind of thing that this is a perfect use for

365
00:37:55,680 --> 00:38:00,000
a package. This is something that's not going to, you're not going to build your whole application

366
00:38:00,000 --> 00:38:06,000
on this dependency. So it's easy to replace if it turns out not to do what you want it to do,

367
00:38:06,000 --> 00:38:10,560
but it just, it's going to save you time if you're doing lots of file system querying.

368
00:38:10,560 --> 00:38:12,400
- Yeah, yeah, absolutely.

369
00:38:12,400 --> 00:38:22,960
Right. My second pick comes in the shape of a blog post, actually. So I'm sneaking a lot of

370
00:38:22,960 --> 00:38:25,120
sort of a blog post into the package pick section.

371
00:38:25,120 --> 00:38:28,640
- This is one of my famous non-pick picks.

372
00:38:28,640 --> 00:38:33,280
- Well, it is a pick, so you can use it as a dependency. It's just not,

373
00:38:34,000 --> 00:38:40,960
it hasn't been packaged up yet. Maybe this is an encouragement, although I think the author

374
00:38:40,960 --> 00:38:49,840
is quite busy. The author is Rob Nepeer and his blog post is about any coding key. That's what he

375
00:38:49,840 --> 00:38:56,560
calls the thing, the type that he implemented. It's a really interesting blog post. He looks at

376
00:38:56,560 --> 00:39:01,120
explores the coding key protocol and what it means to conform to it.

377
00:39:02,400 --> 00:39:07,440
And especially if you want to conform to it yourself, you know, other than like you normally

378
00:39:07,440 --> 00:39:14,240
would with a string backed enum, right? We all know this. If we have, for instance, a thing that

379
00:39:14,240 --> 00:39:22,640
we want to decode and the property name, we want to have a property name on the Swift side that's

380
00:39:22,640 --> 00:39:29,280
different from the property name in the JSON, for instance. Right. What we do is we have an enum

381
00:39:29,280 --> 00:39:34,240
that conforms to coding key. Then we spell out the cases, also the ones that we don't want to change.

382
00:39:34,240 --> 00:39:40,560
And for the ones that we do want to change, we give the case name. We assign a Swift case name

383
00:39:40,560 --> 00:39:47,520
and assign it a stringified, the string of the JSON attribute name that we want to map to it.

384
00:39:47,520 --> 00:39:52,480
So that's what you normally do. There's a bit of repetition going on there because you need to

385
00:39:52,480 --> 00:39:56,480
spell out all the other cases that you don't want to change, but that's just the way it is.

386
00:39:57,280 --> 00:40:03,920
And Rob explores what it means to implement this any coding key thing that allows you to do that

387
00:40:03,920 --> 00:40:10,000
a little bit more elegantly, more concisely. And it's a really nice thing. It's a tiny type. It

388
00:40:10,000 --> 00:40:17,280
really like my packet recommendation is effectively a code block in a blog post. So you can copy that

389
00:40:17,280 --> 00:40:23,360
out. And there's a second code block that makes it even nicer with an overload or an extension on

390
00:40:24,160 --> 00:40:34,480
JSON decoder to make that nicer. And it all lives in a repository, but the repository isn't

391
00:40:34,480 --> 00:40:39,600
the package. It's a collection of, I think there's playgrounds in it and just code snippets

392
00:40:39,600 --> 00:40:45,840
that explore more around codable. That's definitely also a thing worth looking at.

393
00:40:45,840 --> 00:40:52,880
So the whole thing is a blog post and also a protocol, not a protocol, a repository that

394
00:40:52,880 --> 00:40:59,360
Rob has prepared with lots of examples and stuff. So take a look at any coding key by Rob Napier.

395
00:40:59,360 --> 00:41:03,040
All it needs is a package.swift.

396
00:41:03,040 --> 00:41:06,160
Yeah. Get working on that, Rob.

397
00:41:06,160 --> 00:41:13,600
Or somebody else. It doesn't have to be Rob.

398
00:41:13,600 --> 00:41:16,240
Exactly. With attribution, of course.

399
00:41:16,240 --> 00:41:21,760
Although it's always interesting because if you publish code on a blog,

400
00:41:21,760 --> 00:41:26,640
what license is that code being published under? I mean, it's technically not an open source

401
00:41:26,640 --> 00:41:31,440
license unless explicitly stated. So just be careful. Be careful taking code off people's

402
00:41:31,440 --> 00:41:36,080
webpages. I'm sure this is provided in that spirit.

403
00:41:36,080 --> 00:41:38,000
You're listening to OpenAI.

404
00:41:38,000 --> 00:41:51,120
And with that, I think we'll wrap it up there. So we will be back in a few weeks with

405
00:41:51,680 --> 00:41:57,120
another episode. And maybe by that time, we will have the, in fact, I'm pretty sure by that time,

406
00:41:57,120 --> 00:42:02,960
we will have the new build system in production. So maybe we'll talk more about it then.

407
00:42:02,960 --> 00:42:07,760
And we should have the Swift 6 preview live by then as well, shouldn't we?

408
00:42:07,760 --> 00:42:11,920
We'll definitely have the Swift 6 preview live by then. Yes.

409
00:42:11,920 --> 00:42:14,400
Yeah. Well, we got ourselves two deadlines then.

410
00:42:14,400 --> 00:42:19,920
Two deadlines. Yeah. Before the next episode. But we haven't said when the next episode will be.

411
00:42:19,920 --> 00:42:22,240
Well, there we go. That's our escape hatch.

412
00:42:22,240 --> 00:42:26,240
All right. I'll speak to you in a few weeks.

413
00:42:26,240 --> 00:42:28,640
All right. See you then. Bye-bye.

414
00:42:28,640 --> 00:42:29,840
Bye-bye.