50: It has a learning curve like a brick wall

1
00:00:00,001 --> 00:00:02,000
It's also the 50th episode.

2
00:00:02,000 --> 00:00:07,400
It is, it is actually. Yeah, I've seen this coming out and completely forgot about it again.

3
00:00:07,400 --> 00:00:10,400
It is. Happy, happy anniversary.

4
00:00:10,400 --> 00:00:12,000
The podcast will...

5
00:00:12,000 --> 00:00:13,400
Happy 50th anniversary, yeah.

6
00:00:13,400 --> 00:00:15,400
I think I made this joke before, right?

7
00:00:15,400 --> 00:00:20,400
This podcast will soon eclipse our age in terms of episodes.

8
00:00:20,400 --> 00:00:23,800
Well, I am actually 50 right now.

9
00:00:23,800 --> 00:00:24,600
Yeah, exactly.

10
00:00:24,600 --> 00:00:28,800
So it is... as of next month, it will be older than me.

11
00:00:29,000 --> 00:00:31,000
[laughs]

12
00:00:31,000 --> 00:00:36,000
But no, it's been a bit of a journey.

13
00:00:36,000 --> 00:00:38,400
I don't know whether we actually set out to...

14
00:00:38,400 --> 00:00:41,000
In fact, I know we didn't set out to make a podcast.

15
00:00:41,000 --> 00:00:45,000
It just kind of morphed into one over time.

16
00:00:45,000 --> 00:00:49,400
It started as a little kind of chat about what we were doing.

17
00:00:49,400 --> 00:00:54,000
We even had guests on the first few, which I do miss having guests, actually.

18
00:00:54,000 --> 00:00:58,200
I think we should consider bringing people on occasionally

19
00:00:58,200 --> 00:01:03,000
because I think it's good to get other people involved.

20
00:01:03,000 --> 00:01:09,400
But yeah, it's changed a lot since the very first days back on Twitter Spaces,

21
00:01:09,400 --> 00:01:11,000
which is where we started it.

22
00:01:11,000 --> 00:01:16,400
And then, of course, we kind of transitioned into being...

23
00:01:16,400 --> 00:01:20,000
I hesitate to say a proper podcast because I'm not sure I'd give it that,

24
00:01:20,000 --> 00:01:23,200
but certainly I'll take it a little bit more seriously.

25
00:01:23,200 --> 00:01:27,400
Well, it is listed on Apple Podcasts, right?

26
00:01:27,400 --> 00:01:30,200
So that absolutely makes it a proper podcast.

27
00:01:30,200 --> 00:01:31,000
Yeah.

28
00:01:31,000 --> 00:01:37,000
The requirements for being listed as a podcast there, though, are very, very minimal.

29
00:01:37,000 --> 00:01:41,200
Yeah, you're saying that the validation isn't as tight as it is

30
00:01:41,200 --> 00:01:43,600
to get a package on this with Package Index.

31
00:01:43,600 --> 00:01:47,600
Tim Kirk doesn't go and listen to your podcast if you want to be on that list.

32
00:01:47,600 --> 00:01:49,600
[laughs]

33
00:01:49,600 --> 00:01:54,600
He'd have a lot on his hands to listen to all of them.

34
00:01:56,000 --> 00:01:57,200
[laughs]

35
00:01:57,200 --> 00:01:58,000
I remember.

36
00:01:58,000 --> 00:02:02,200
In fact, it was at the last Swift Server Conference,

37
00:02:02,200 --> 00:02:06,600
which I think was actually 2022, the last one I was at.

38
00:02:06,600 --> 00:02:11,600
We'd just switched across to using...

39
00:02:11,600 --> 00:02:17,200
doing the podcast as a kind of actual podcast rather than Twitter Space,

40
00:02:17,200 --> 00:02:23,400
but we were still recording on the microphones we were just using for those early ones.

41
00:02:23,400 --> 00:02:27,000
And somebody came up to me at the Swift Server Conference and they said,

42
00:02:27,000 --> 00:02:31,200
"I really like the podcast, but please fix your audio."

43
00:02:31,200 --> 00:02:33,200
[laughs]

44
00:02:33,200 --> 00:02:35,200
Ooh, harsh.

45
00:02:35,200 --> 00:02:37,200
[laughs]

46
00:02:37,200 --> 00:02:39,600
I like "but" never ends well, does it?

47
00:02:39,600 --> 00:02:41,000
[laughs]

48
00:02:41,000 --> 00:02:42,600
I was well aware of the...

49
00:02:42,600 --> 00:02:43,600
And I'm not sure who it was.

50
00:02:43,600 --> 00:02:45,200
I didn't get their name.

51
00:02:45,200 --> 00:02:46,600
It was a very brief interaction.

52
00:02:46,600 --> 00:02:51,600
So if that was you and you're still listening, I did try and fix their audio.

53
00:02:51,600 --> 00:02:56,000
In fact, I've put many, many, many hours into fixing our audio.

54
00:02:56,000 --> 00:02:57,200
[laughs]

55
00:02:57,200 --> 00:03:01,800
If that was you, I'd love to see if you think it's fixed.

56
00:03:01,800 --> 00:03:03,000
So please get in touch.

57
00:03:03,000 --> 00:03:04,000
[laughs]

58
00:03:04,000 --> 00:03:05,000
Nice.

59
00:03:05,000 --> 00:03:07,200
So yeah, 50 episodes.

60
00:03:07,200 --> 00:03:09,400
It's a milestone of sorts.

61
00:03:09,400 --> 00:03:12,000
Well, speaking of the Server Side Swift Conference,

62
00:03:12,000 --> 00:03:13,200
actually, there was...

63
00:03:13,200 --> 00:03:17,800
Just after we recorded the last one,

64
00:03:17,800 --> 00:03:22,400
I went to the last episode of our podcast.

65
00:03:22,400 --> 00:03:26,600
I went to the Server Side Swift Conference in London.

66
00:03:26,600 --> 00:03:29,400
It was great.

67
00:03:29,400 --> 00:03:30,600
It was great to see folks.

68
00:03:30,600 --> 00:03:32,400
Great talks.

69
00:03:32,400 --> 00:03:34,400
It was a two-day conference this time.

70
00:03:34,400 --> 00:03:37,600
I think it was one day only in '22,

71
00:03:37,600 --> 00:03:38,600
which was the previous one.

72
00:03:38,600 --> 00:03:40,600
There wasn't one in '23.

73
00:03:40,600 --> 00:03:46,800
Yeah, great lineup, great news.

74
00:03:46,800 --> 00:03:50,000
So we actually got an Apple announcement of sorts again.

75
00:03:50,000 --> 00:03:54,000
There was a talk by Tony Parker and Ben Cohen.

76
00:03:54,000 --> 00:03:59,000
It was called "Swift and Interoperability".

77
00:03:59,000 --> 00:04:01,000
"Interoperability".

78
00:04:01,000 --> 00:04:02,000
God.

79
00:04:02,000 --> 00:04:03,400
See, that's easier for you to say.

80
00:04:03,400 --> 00:04:05,400
[laughs]

81
00:04:05,400 --> 00:04:08,400
And they announced Swift Java integration,

82
00:04:08,400 --> 00:04:11,200
which I found fascinating and great to see.

83
00:04:13,000 --> 00:04:17,800
So what this is about is about calling into Java from Swift

84
00:04:17,800 --> 00:04:20,600
and vice versa, calling into Swift from Java.

85
00:04:20,600 --> 00:04:22,600
And this is early days for the project.

86
00:04:22,600 --> 00:04:25,600
We'll drop a link in the show notes.

87
00:04:25,600 --> 00:04:26,800
Also open source again,

88
00:04:26,800 --> 00:04:29,400
so you can follow along as stuff is being developed.

89
00:04:29,400 --> 00:04:34,800
And it feels like Swift is really gaining

90
00:04:34,800 --> 00:04:37,000
more and more superpowers when it comes to

91
00:04:37,000 --> 00:04:39,800
interoperating with other languages.

92
00:04:39,800 --> 00:04:41,200
And there was quite a bit of excitement

93
00:04:41,200 --> 00:04:42,400
around the conference as well,

94
00:04:42,400 --> 00:04:44,800
when people were talking about it afterwards,

95
00:04:44,800 --> 00:04:47,800
because I can imagine there must be lots of

96
00:04:47,800 --> 00:04:54,200
big Java deployments that are perhaps sort of eyeing,

97
00:04:54,200 --> 00:04:57,000
you know, a future replacement.

98
00:04:57,000 --> 00:04:59,800
Like Swift is supposed to be one of the successor languages

99
00:04:59,800 --> 00:05:00,600
for C++.

100
00:05:00,600 --> 00:05:03,200
I wonder if there's the same sentiment for Java,

101
00:05:03,200 --> 00:05:07,400
because there are lots of nice things about Swift

102
00:05:07,400 --> 00:05:08,800
compared to Java.

103
00:05:08,800 --> 00:05:11,000
And I've just thinking in terms of memory,

104
00:05:11,000 --> 00:05:15,800
just today I looked at the memory consumption

105
00:05:15,800 --> 00:05:18,200
of our web application,

106
00:05:18,200 --> 00:05:21,800
which is a Swift on server project with 270 megabytes.

107
00:05:21,800 --> 00:05:26,000
And I don't think even that's particularly small.

108
00:05:26,000 --> 00:05:28,600
I think we have a couple of caching things happening

109
00:05:28,600 --> 00:05:32,600
that makes this a bit bigger than it would necessarily need to be.

110
00:05:32,600 --> 00:05:34,000
But I think in the Java world,

111
00:05:34,000 --> 00:05:39,400
that's a dream, you know, to have that as your memory size.

112
00:05:39,400 --> 00:05:41,800
And I think that might be really interesting

113
00:05:41,800 --> 00:05:44,800
for lots of projects as a way to transition.

114
00:05:44,800 --> 00:05:49,000
And in particular, because it really allows you to go bit by bit.

115
00:05:49,000 --> 00:05:50,800
So we can do this function by function,

116
00:05:50,800 --> 00:05:52,600
because you can call out into new code,

117
00:05:52,600 --> 00:05:54,800
and it really transitions slowly.

118
00:05:54,800 --> 00:05:57,600
And I think that's one of the greatest things

119
00:05:57,600 --> 00:06:00,400
with all these transitions that Apple always do,

120
00:06:00,400 --> 00:06:04,600
is making sure that you can do this byte size.

121
00:06:04,600 --> 00:06:07,200
And memory efficiency, especially on the server,

122
00:06:07,200 --> 00:06:08,600
is really, really important,

123
00:06:08,600 --> 00:06:11,600
because it's one of the things

124
00:06:11,600 --> 00:06:13,800
that hasn't really come down in price very much

125
00:06:13,800 --> 00:06:16,400
in the last few years.

126
00:06:16,400 --> 00:06:21,200
Large servers with lots of memory are still very expensive.

127
00:06:21,200 --> 00:06:24,600
And memory seems to be the thing that you actually pay.

128
00:06:24,600 --> 00:06:27,000
That's what bumps the price up.

129
00:06:27,000 --> 00:06:28,200
Yeah, absolutely.

130
00:06:28,200 --> 00:06:33,400
Our Linux builders are actually quite big in terms of memory,

131
00:06:33,400 --> 00:06:35,200
because builds often use a lot of memory.

132
00:06:35,200 --> 00:06:38,600
And CPU-wise, we wouldn't need the...

133
00:06:38,600 --> 00:06:40,600
I think it has an eight-core machine,

134
00:06:40,600 --> 00:06:42,600
which we wouldn't necessarily need.

135
00:06:42,600 --> 00:06:48,600
But the memory really drives up the price in that instance.

136
00:06:48,600 --> 00:06:50,000
Same with our Mac build machines.

137
00:06:50,000 --> 00:06:52,400
They've got an enormous amount of memory.

138
00:06:52,400 --> 00:06:57,400
And yeah, it's an expensive thing to do.

139
00:06:57,400 --> 00:06:59,400
Yeah.

140
00:06:59,400 --> 00:07:05,000
I think it's great to see Apple and the Swift team

141
00:07:05,000 --> 00:07:09,200
making these announcements at these community events.

142
00:07:09,200 --> 00:07:15,000
And especially, I don't know, I presume it was Tim

143
00:07:15,000 --> 00:07:17,200
and his team that were responsible for doing this,

144
00:07:17,200 --> 00:07:21,800
but they were incredibly quick getting the video out

145
00:07:21,800 --> 00:07:24,000
so that the announcement could actually be public,

146
00:07:24,000 --> 00:07:27,400
because that was the only downside to it a little bit.

147
00:07:27,400 --> 00:07:30,400
I heard about the announcement,

148
00:07:30,400 --> 00:07:32,400
but not being at the conference,

149
00:07:32,400 --> 00:07:34,000
I wanted to write about it,

150
00:07:34,000 --> 00:07:37,600
but I had almost nothing to go on to actually write about it.

151
00:07:37,600 --> 00:07:39,400
I could see the repository, of course,

152
00:07:39,400 --> 00:07:42,400
and the repository readme is useful,

153
00:07:42,400 --> 00:07:43,600
but it's not really the announcement.

154
00:07:43,600 --> 00:07:45,800
It doesn't give you any of the context or anything like that.

155
00:07:45,800 --> 00:07:48,800
Now, luckily, the Swift Server Conference

156
00:07:48,800 --> 00:07:51,400
did publish their videos within a week.

157
00:07:51,400 --> 00:07:53,400
So by the next week,

158
00:07:53,400 --> 00:07:55,800
I was able to link to the video as well.

159
00:07:55,800 --> 00:07:59,800
But I did have to kind of write about it a little bit blind.

160
00:07:59,800 --> 00:08:06,600
But I love that they're picking these venues to,

161
00:08:06,600 --> 00:08:09,800
like last year or in 2022,

162
00:08:09,800 --> 00:08:12,400
the announcement of the foundation

163
00:08:12,400 --> 00:08:16,400
and this year with the Java interop.

164
00:08:16,400 --> 00:08:19,400
Great. I applaud it.

165
00:08:19,400 --> 00:08:22,000
But if I could applaud it

166
00:08:22,000 --> 00:08:24,200
with also a blog post published at the same time,

167
00:08:24,200 --> 00:08:25,600
that would be even better.

168
00:08:25,600 --> 00:08:28,800
[laughs]

169
00:08:28,800 --> 00:08:31,600
Yeah. And speaking of the Swift Foundation announcement,

170
00:08:31,600 --> 00:08:33,000
Tony spoke to that a bit

171
00:08:33,000 --> 00:08:35,200
and gave a bit of a summary of what happened there

172
00:08:35,200 --> 00:08:38,400
and that the transition effectively is complete,

173
00:08:38,400 --> 00:08:43,000
like Swift Foundation is now shipping the open source one.

174
00:08:43,000 --> 00:08:46,000
That just happened during the Swift 6 beta phase

175
00:08:46,000 --> 00:08:49,800
that they switched over to the open source version

176
00:08:49,800 --> 00:08:52,000
of Swift Foundation, which is really nice

177
00:08:52,000 --> 00:08:56,800
because it aligns the APIs with the Linux world.

178
00:08:56,800 --> 00:08:59,400
This is a place where we've seen a couple of times

179
00:08:59,400 --> 00:09:01,800
when stuff wasn't quite there yet.

180
00:09:01,800 --> 00:09:05,400
So that's great to see.

181
00:09:05,400 --> 00:09:09,400
A few other talks I wanted to give a quick shout out.

182
00:09:09,400 --> 00:09:11,400
And this was a server-side Swift conference,

183
00:09:11,400 --> 00:09:13,800
but the reason I'm mentioning a few here

184
00:09:13,800 --> 00:09:16,200
is because they're more general.

185
00:09:16,200 --> 00:09:18,200
They're not server-specific really.

186
00:09:18,200 --> 00:09:20,800
Daniel Steinberg had a nice talk

187
00:09:20,800 --> 00:09:22,800
about when to make a macro.

188
00:09:22,800 --> 00:09:27,200
Really great talk going a bit into the details there.

189
00:09:27,200 --> 00:09:29,200
Franz Busch talked about leveraging

190
00:09:29,200 --> 00:09:31,400
structured concurrency in your applications.

191
00:09:31,400 --> 00:09:36,000
Again, giving a nice summary how to transition over,

192
00:09:36,000 --> 00:09:40,200
adopt concurrency, Swift 6 concurrency.

193
00:09:40,200 --> 00:09:44,200
Babit Vege, a bachelor student,

194
00:09:44,200 --> 00:09:46,600
gave a talk about stop worrying about roots

195
00:09:46,600 --> 00:09:48,800
with open API generator.

196
00:09:48,800 --> 00:09:52,800
I found that nice because while open API generator

197
00:09:52,800 --> 00:09:55,800
is obviously server-specific,

198
00:09:55,800 --> 00:09:57,800
you might have need for that.

199
00:09:57,800 --> 00:10:00,800
For instance, if you stand up a mock API,

200
00:10:00,800 --> 00:10:03,800
you're developing an app, and these days,

201
00:10:03,800 --> 00:10:07,400
I don't think, hardly any app gets developed

202
00:10:07,400 --> 00:10:09,200
right without talking to an API.

203
00:10:09,200 --> 00:10:12,400
And you might actually want to stand up something

204
00:10:12,400 --> 00:10:14,000
that you can connect your app to

205
00:10:14,000 --> 00:10:16,400
while maybe production doesn't exist yet

206
00:10:16,400 --> 00:10:19,400
or you want to inject some data,

207
00:10:19,400 --> 00:10:21,800
have some example data for testing

208
00:10:21,800 --> 00:10:24,800
or for generating screenshots, stuff like that.

209
00:10:24,800 --> 00:10:26,400
Depending on how you want to do that,

210
00:10:26,400 --> 00:10:29,400
it might be really nice to just take these

211
00:10:29,400 --> 00:10:31,200
open API specification,

212
00:10:31,200 --> 00:10:33,200
just run it through that generator

213
00:10:33,200 --> 00:10:35,200
and bring up a server that you connect to.

214
00:10:35,200 --> 00:10:38,200
So she gave a talk about that,

215
00:10:38,200 --> 00:10:41,600
how to use the open API generator.

216
00:10:41,600 --> 00:10:45,000
And then finally, Nick Lockwood with a really great talk.

217
00:10:45,000 --> 00:10:47,000
"So you think you know Swift?"

218
00:10:47,000 --> 00:10:50,000
And that was one of these where, you know,

219
00:10:50,000 --> 00:10:53,000
there's lots of things in Swift that seem weird

220
00:10:53,000 --> 00:10:55,000
and you sort of struggle with,

221
00:10:55,000 --> 00:10:58,000
especially around strings is like the classic example.

222
00:10:58,000 --> 00:11:03,000
Why can't you index into a Swift string?

223
00:11:03,000 --> 00:11:06,000
And he explains why there are these,

224
00:11:06,000 --> 00:11:08,000
why it is the way it is,

225
00:11:08,000 --> 00:11:10,000
and also brings up a couple of things

226
00:11:10,000 --> 00:11:13,000
that maybe people don't even know,

227
00:11:13,000 --> 00:11:15,000
because Swift is a big language,

228
00:11:15,000 --> 00:11:18,000
there's stuff that you don't typically come across.

229
00:11:18,000 --> 00:11:20,000
So that was a set of talks

230
00:11:20,000 --> 00:11:22,000
I wanted to mention from the conference.

231
00:11:22,000 --> 00:11:25,000
There were quite a few others, more service specific,

232
00:11:25,000 --> 00:11:28,000
but they're all great, they're all worth checking out.

233
00:11:28,000 --> 00:11:31,000
- That's great. - And we'll add links to the show notes.

234
00:11:31,000 --> 00:11:34,000
Sure, yeah.

235
00:11:34,000 --> 00:11:38,000
I also had a note from...

236
00:11:38,000 --> 00:11:41,000
Well, so in the previous episode,

237
00:11:41,000 --> 00:11:43,000
one of my packages that I talked about

238
00:11:43,000 --> 00:11:46,000
was called Chip8Kit, I think,

239
00:11:46,000 --> 00:11:49,000
or Chip8 something.

240
00:11:49,000 --> 00:11:51,000
And it was about an emulation

241
00:11:51,000 --> 00:11:56,000
of an old computer system called a Chip8.

242
00:11:56,000 --> 00:11:58,000
And I had a message from Mirza,

243
00:11:58,000 --> 00:12:00,000
who also got mentioned last episode

244
00:12:00,000 --> 00:12:03,000
as the person who contributed to the Swift package index,

245
00:12:03,000 --> 00:12:08,000
the forked from functionality that's now live on the site.

246
00:12:08,000 --> 00:12:11,000
And he dropped me a message on Discord

247
00:12:11,000 --> 00:12:15,000
and told me that a couple of years ago,

248
00:12:15,000 --> 00:12:19,000
he had built a Chip8 emulator,

249
00:12:19,000 --> 00:12:23,000
not as a Swift package, but as an iOS application.

250
00:12:23,000 --> 00:12:26,000
So if you were curious about the Chip8 system

251
00:12:26,000 --> 00:12:28,000
that we talked about last time,

252
00:12:28,000 --> 00:12:30,000
and wanted to play...

253
00:12:30,000 --> 00:12:32,000
Well, the screenshot on the Git repository

254
00:12:32,000 --> 00:12:40,000
is playing Pong on the Chip8 system.

255
00:12:40,000 --> 00:12:42,000
Or Tic-Tac-Toe, I think, as well,

256
00:12:42,000 --> 00:12:44,000
or maybe Snake as well.

257
00:12:44,000 --> 00:12:47,000
If you wanted to have an iOS version of that,

258
00:12:47,000 --> 00:12:51,000
I think it's worth to mention that there is this repository,

259
00:12:51,000 --> 00:12:54,000
and we'll put a link in the show notes to that as well.

260
00:12:54,000 --> 00:12:57,000
So thanks for the update on that, Mirza.

261
00:12:57,000 --> 00:12:59,000
Nice.

262
00:12:59,000 --> 00:13:04,000
Another thing worth mentioning is a new repository.

263
00:13:04,000 --> 00:13:06,000
I think it's--yeah, it's fairly new.

264
00:13:06,000 --> 00:13:11,000
It's GitHub Actions Workflows repository on Swift Lang.

265
00:13:11,000 --> 00:13:15,000
And what this does, it collects typical things

266
00:13:15,000 --> 00:13:17,000
you might want to run in your CI system.

267
00:13:17,000 --> 00:13:21,000
And I find that really nice because I tend to,

268
00:13:21,000 --> 00:13:23,000
you know, sort of copy bits around

269
00:13:23,000 --> 00:13:28,000
from my previous repositories when I need something

270
00:13:28,000 --> 00:13:31,000
or from, like, well-known repositories

271
00:13:31,000 --> 00:13:33,000
where I know they have solid setup,

272
00:13:33,000 --> 00:13:36,000
and I just steal bits and pieces here and there.

273
00:13:36,000 --> 00:13:39,000
But what this does is sort of--I think the idea is there

274
00:13:39,000 --> 00:13:42,000
for this to be the way to get started

275
00:13:42,000 --> 00:13:46,000
with a CI setup for a Swift package on GitHub

276
00:13:46,000 --> 00:13:47,000
with GitHub Actions.

277
00:13:47,000 --> 00:13:49,000
It has the typical thing you'd expect,

278
00:13:49,000 --> 00:13:51,000
like running tests.

279
00:13:51,000 --> 00:13:55,000
And it also has something which they call soundness checks,

280
00:13:55,000 --> 00:13:58,000
and that's stuff like formatting checks, linting,

281
00:13:58,000 --> 00:14:01,000
license checks, you know, that your files have

282
00:14:01,000 --> 00:14:04,000
license headers and that stuff.

283
00:14:04,000 --> 00:14:06,000
And you can configure this.

284
00:14:06,000 --> 00:14:08,000
You know, you can use these.

285
00:14:08,000 --> 00:14:10,000
You can--I think there's a YAML file you can use

286
00:14:10,000 --> 00:14:12,000
to specify which parts you want to run,

287
00:14:12,000 --> 00:14:13,000
that sort of stuff.

288
00:14:13,000 --> 00:14:16,000
It's great to see that appearing.

289
00:14:16,000 --> 00:14:19,000
The only problem right now, as far as I could tell,

290
00:14:19,000 --> 00:14:21,000
this is currently only supporting Linux,

291
00:14:21,000 --> 00:14:25,000
so if you need to run this on macOS,

292
00:14:25,000 --> 00:14:29,000
you'll have to wait a bit longer for that support to appear

293
00:14:29,000 --> 00:14:31,000
or make a contribution to add it.

294
00:14:31,000 --> 00:14:32,000
Of course, yeah.

295
00:14:32,000 --> 00:14:35,000
It's also probably worth mentioning at this point,

296
00:14:35,000 --> 00:14:37,000
have you heard of a tool called Danger?

297
00:14:37,000 --> 00:14:38,000
Yes, I have, yeah.

298
00:14:38,000 --> 00:14:41,000
Yeah, so Danger does some similar things to that,

299
00:14:41,000 --> 00:14:44,000
like checking license terms and other things

300
00:14:44,000 --> 00:14:46,000
that you can configure that it will check

301
00:14:46,000 --> 00:14:50,000
as a kind of sanity check before your code goes in.

302
00:14:50,000 --> 00:14:53,000
And I think that--I believe that does support Mac as well.

303
00:14:53,000 --> 00:14:55,000
It has been around for quite a while,

304
00:14:55,000 --> 00:14:57,000
so it's probably just worth mentioning that as well

305
00:14:57,000 --> 00:14:58,000
at this point.

306
00:14:58,000 --> 00:14:59,000
Yeah.

307
00:14:59,000 --> 00:15:02,000
So that's kind of action workflows,

308
00:15:02,000 --> 00:15:05,000
and we'll add the link to the show notes.

309
00:15:05,000 --> 00:15:09,000
So are we planning to implement some of those checks?

310
00:15:09,000 --> 00:15:12,000
Well, yeah, I think it might be worth looking

311
00:15:12,000 --> 00:15:15,000
at which parts we could use.

312
00:15:15,000 --> 00:15:19,000
I actually added an issue to our issue tracker

313
00:15:19,000 --> 00:15:21,000
to at least explore what the options are.

314
00:15:21,000 --> 00:15:23,000
I had a quick scan.

315
00:15:23,000 --> 00:15:27,000
There's quite a lot in there already,

316
00:15:27,000 --> 00:15:29,000
and I think some of it would certainly be useful,

317
00:15:29,000 --> 00:15:31,000
like the soundness checks license.

318
00:15:31,000 --> 00:15:35,000
I mean, I think we're pretty--we don't add new files

319
00:15:35,000 --> 00:15:38,000
that often these days, and I don't think we miss

320
00:15:38,000 --> 00:15:41,000
adding the header, but just having that check in there

321
00:15:41,000 --> 00:15:43,000
would be nice.

322
00:15:43,000 --> 00:15:44,000
Formatting, certainly.

323
00:15:44,000 --> 00:15:46,000
I think you wrote about formatting as well

324
00:15:46,000 --> 00:15:49,000
on "Iris Dev Weekly" last week, didn't you?

325
00:15:49,000 --> 00:15:51,000
I did, yeah.

326
00:15:51,000 --> 00:15:56,000
A rather opinionated piece, which I got lots of feedback

327
00:15:56,000 --> 00:15:57,000
in both directions on.

328
00:15:57,000 --> 00:15:58,000
Oh, do say.

329
00:15:58,000 --> 00:15:59,000
There was more--

330
00:15:59,000 --> 00:16:00,000
About formatting.

331
00:16:00,000 --> 00:16:02,000
[laughter]

332
00:16:02,000 --> 00:16:05,000
There were more--there was more people in agreement

333
00:16:05,000 --> 00:16:09,000
with me than against me, but it was about 70/30,

334
00:16:09,000 --> 00:16:10,000
I would say.

335
00:16:10,000 --> 00:16:17,000
Yeah, I'd love seeing something like that be around,

336
00:16:17,000 --> 00:16:19,000
like integrated and running by default.

337
00:16:19,000 --> 00:16:22,000
I was nodding along as I read your comment

338
00:16:22,000 --> 00:16:24,000
about formatting on save.

339
00:16:24,000 --> 00:16:26,000
I'm glad at least we're in agreement,

340
00:16:26,000 --> 00:16:29,000
because that's a good start.

341
00:16:29,000 --> 00:16:33,000
Somebody did actually drop me a note saying

342
00:16:33,000 --> 00:16:40,000
that they had published an Xcode plugin

343
00:16:40,000 --> 00:16:45,000
using the new single-file Xcode extension architecture

344
00:16:45,000 --> 00:16:51,000
that you combine Command-S to, and effectively what it does

345
00:16:51,000 --> 00:16:54,000
is it runs Swift format instead of saving,

346
00:16:54,000 --> 00:16:56,000
but of course the Swift format then does the save.

347
00:16:56,000 --> 00:16:59,000
So effectively, you can do what I was asking for.

348
00:16:59,000 --> 00:17:02,000
And if anyone's clueless about what we're talking about here,

349
00:17:02,000 --> 00:17:06,000
just go and read the latest issue of iOS Dev Weekly,

350
00:17:06,000 --> 00:17:13,000
which is issue 682, and I talked about Swift format

351
00:17:13,000 --> 00:17:16,000
and code formatting.

352
00:17:16,000 --> 00:17:19,000
But I think my point was--and that's--

353
00:17:19,000 --> 00:17:23,000
an extension like that is fine, but my point was a bit bigger

354
00:17:23,000 --> 00:17:27,000
than that in that I'd love to see--first of all,

355
00:17:27,000 --> 00:17:29,000
I'd love to see a standard, and I don't--

356
00:17:29,000 --> 00:17:32,000
nobody's going to agree on the standard,

357
00:17:32,000 --> 00:17:34,000
but I'd love for Apple to just say,

358
00:17:34,000 --> 00:17:36,000
"This is how we format Swift code,"

359
00:17:36,000 --> 00:17:38,000
just like Go did, just like JavaScript did.

360
00:17:38,000 --> 00:17:42,000
And this problem just goes away after somebody does that,

361
00:17:42,000 --> 00:17:45,000
but it needs to be somebody who's with authority.

362
00:17:45,000 --> 00:17:49,000
It needs to effectively be Apple who'd do it.

363
00:17:49,000 --> 00:17:51,000
And then, of course, I would also love to see

364
00:17:51,000 --> 00:17:54,000
auto-format on save, which is the key thing,

365
00:17:54,000 --> 00:17:57,000
because at that point, you can just forget about formatting.

366
00:17:57,000 --> 00:18:01,000
And I say this with experience, because I've had this switched

367
00:18:01,000 --> 00:18:04,000
on in JavaScript and CSS for a very long time now,

368
00:18:04,000 --> 00:18:09,000
and I don't even bother trying to get the indentation right.

369
00:18:09,000 --> 00:18:13,000
I just type whatever I want and hit save, and it's done.

370
00:18:13,000 --> 00:18:15,000
- Yeah, yeah. - It's so freeing.

371
00:18:15,000 --> 00:18:19,000
It's great.

372
00:18:19,000 --> 00:18:22,000
It's just a thing you don't have to worry about anymore.

373
00:18:22,000 --> 00:18:23,000
It's great.

374
00:18:23,000 --> 00:18:28,000
Anyway, so before you set me off on my rant again, let me stop.

375
00:18:28,000 --> 00:18:32,000
All right.

376
00:18:32,000 --> 00:18:35,000
And finally, I wanted to mention something really neat

377
00:18:35,000 --> 00:18:37,000
that I saw on the Swift forums.

378
00:18:37,000 --> 00:18:41,000
I think it was just yesterday at time of recording,

379
00:18:41,000 --> 00:18:44,000
and there's a pitch up for the vector type,

380
00:18:44,000 --> 00:18:47,000
which is a fixed-size arrays type,

381
00:18:47,000 --> 00:18:51,000
and there was Caroy Llorente.

382
00:18:51,000 --> 00:18:54,000
I think he certainly works at Apple,

383
00:18:54,000 --> 00:18:57,000
and I think he's also one of the authors of the proposal

384
00:18:57,000 --> 00:18:59,000
and the implementation.

385
00:18:59,000 --> 00:19:02,000
He talked about--as you might imagine,

386
00:19:02,000 --> 00:19:05,000
there's a discussion about naming on the Swift forums,

387
00:19:05,000 --> 00:19:06,000
and he talks--

388
00:19:06,000 --> 00:19:08,000
I just can't remember naming.

389
00:19:08,000 --> 00:19:10,000
That should be quick and simple.

390
00:19:10,000 --> 00:19:13,000
Inconceivable.

391
00:19:13,000 --> 00:19:16,000
And he comes out in favor of the name vector

392
00:19:16,000 --> 00:19:21,000
and tells a little story how they arrived at the name.

393
00:19:21,000 --> 00:19:23,000
It wasn't actually named that initially.

394
00:19:23,000 --> 00:19:25,000
And he says, "That very same day,

395
00:19:25,000 --> 00:19:28,000
two separate groups of people independently realized

396
00:19:28,000 --> 00:19:33,000
that copyability has now turned this type into a true vector,

397
00:19:33,000 --> 00:19:37,000
and that vector is the obviously right name for this construct.

398
00:19:37,000 --> 00:19:40,000
This made for a comical scene when members of the two groups

399
00:19:40,000 --> 00:19:42,000
met later in the day,

400
00:19:42,000 --> 00:19:45,000
fully expecting that they need to convince the other."

401
00:19:45,000 --> 00:19:47,000
I thought that was really neat

402
00:19:47,000 --> 00:19:51,000
when people actually independently arrive at the same conclusion

403
00:19:51,000 --> 00:19:55,000
and then feel like, "Oh, God, I've got to convince someone

404
00:19:55,000 --> 00:19:58,000
of a different name," which I can imagine.

405
00:19:58,000 --> 00:20:02,000
We see these discussions happen all the time, right?

406
00:20:02,000 --> 00:20:04,000
When people have settled on a name,

407
00:20:04,000 --> 00:20:09,000
it can be really hard to convince them of a different name.

408
00:20:09,000 --> 00:20:11,000
So, yeah, I found that really neat.

409
00:20:11,000 --> 00:20:13,000
Yes, yeah.

410
00:20:13,000 --> 00:20:15,000
Shall we do some packages?

411
00:20:15,000 --> 00:20:17,000
Let's do some packages.

412
00:20:17,000 --> 00:20:20,000
I've only got two, so I'm going to let you kick us off.

413
00:20:20,000 --> 00:20:21,000
Sure thing.

414
00:20:21,000 --> 00:20:25,000
I can kick us off with a package from Christian Selig

415
00:20:25,000 --> 00:20:27,000
called TinyStorage.

416
00:20:27,000 --> 00:20:31,000
And it's a simple, lightweight replacement for user defaults

417
00:20:31,000 --> 00:20:34,000
that makes access a little more straightforward,

418
00:20:34,000 --> 00:20:36,000
plus some niceties.

419
00:20:36,000 --> 00:20:42,000
So the readme of this starts with a link to a blog post,

420
00:20:42,000 --> 00:20:46,000
actually, where Christian was having some issues

421
00:20:46,000 --> 00:20:49,000
with user defaults.

422
00:20:49,000 --> 00:20:54,000
And I think it was largely around needing to access user defaults

423
00:20:54,000 --> 00:20:57,000
kind of immediately at the app startup,

424
00:20:57,000 --> 00:21:01,000
and there were some kind of inconsistencies there

425
00:21:01,000 --> 00:21:07,000
with things not quite being ready when he needed them.

426
00:21:07,000 --> 00:21:14,000
So I think he looked at building an alternative,

427
00:21:14,000 --> 00:21:18,000
and it must admit it looks like he's done

428
00:21:18,000 --> 00:21:21,000
a very thorough job of doing this.

429
00:21:21,000 --> 00:21:25,000
So some of the features that it has, the primary one,

430
00:21:25,000 --> 00:21:29,000
the first bullet in the list is relating to that point

431
00:21:29,000 --> 00:21:31,000
that I just mentioned there, which is reliable access,

432
00:21:31,000 --> 00:21:35,000
either on first reboot or in application pre-warming states,

433
00:21:35,000 --> 00:21:39,000
TinyStorage will read and write data properly.

434
00:21:39,000 --> 00:21:41,000
It's got a code on support, of course.

435
00:21:41,000 --> 00:21:49,000
It's got a property wrapper for an app storage-like wrapper

436
00:21:49,000 --> 00:21:52,000
that you can use in SwiftUI and things like that.

437
00:21:52,000 --> 00:21:57,000
You can subscribe to notification center,

438
00:21:57,000 --> 00:22:00,000
notifications when things change.

439
00:22:00,000 --> 00:22:03,000
It uses OS log for logging.

440
00:22:03,000 --> 00:22:08,000
So it's really -- and I think I listed like four or five

441
00:22:08,000 --> 00:22:11,000
of the 12 bullet points that are in the features list there.

442
00:22:11,000 --> 00:22:14,000
So it's quite a comprehensive package.

443
00:22:14,000 --> 00:22:18,000
It is brand new, so of course, be a little cautious

444
00:22:18,000 --> 00:22:20,000
with a package that is brand new,

445
00:22:20,000 --> 00:22:23,000
because all brand-new code has bugs in it.

446
00:22:23,000 --> 00:22:24,000
Of course it does.

447
00:22:24,000 --> 00:22:27,000
It's only been in development for six days,

448
00:22:27,000 --> 00:22:30,000
and I believe it's been out a few days ago.

449
00:22:30,000 --> 00:22:35,000
So it is -- presumably it was a clean commit just before

450
00:22:35,000 --> 00:22:39,000
the open source release, because I am sure it had development

451
00:22:39,000 --> 00:22:43,000
before six days ago.

452
00:22:43,000 --> 00:22:46,000
But, yes, it is -- oh, and it looks like it also has

453
00:22:46,000 --> 00:22:51,000
a mechanism similar to app groups for sharing data

454
00:22:51,000 --> 00:22:55,000
between your applications on the same phone,

455
00:22:55,000 --> 00:22:57,000
so from the same developer.

456
00:22:57,000 --> 00:22:59,000
I haven't looked into that in great detail,

457
00:22:59,000 --> 00:23:00,000
but I just noticed it now.

458
00:23:00,000 --> 00:23:02,000
So it looks great.

459
00:23:02,000 --> 00:23:09,000
I mean, it's effectively user defaults, but different.

460
00:23:09,000 --> 00:23:11,000
Yes, and I think it's worth calling out -- you mentioned it

461
00:23:11,000 --> 00:23:13,000
in a quote from the readme.

462
00:23:13,000 --> 00:23:17,000
I think it fixes one of these -- the problem that spawned

463
00:23:17,000 --> 00:23:18,000
this whole thing.

464
00:23:18,000 --> 00:23:22,000
I saw the blog post, and I think it's worth calling out

465
00:23:22,000 --> 00:23:26,000
what actually can happen with stock user defaults.

466
00:23:26,000 --> 00:23:30,000
When an app is launched in the pre-warming phase

467
00:23:30,000 --> 00:23:34,000
or by some other means while the device is locked,

468
00:23:34,000 --> 00:23:39,000
it can happen that user defaults isn't accessible

469
00:23:39,000 --> 00:23:43,000
and then gets reset to the app's stock defaults,

470
00:23:43,000 --> 00:23:45,000
and then you lose the data that's in it.

471
00:23:45,000 --> 00:23:49,000
And that's the investigation that -- I think this triggered him

472
00:23:49,000 --> 00:23:52,000
to write this replacement, which doesn't have that problem.

473
00:23:52,000 --> 00:23:53,000
Right.

474
00:23:53,000 --> 00:23:56,000
I believe the keychain can also get in that state as well,

475
00:23:56,000 --> 00:23:59,000
because if the phone is locked and the keychain gets locked,

476
00:23:59,000 --> 00:24:01,000
and if you're trying to access keychain in the background,

477
00:24:01,000 --> 00:24:04,000
that can also be a similar problem.

478
00:24:04,000 --> 00:24:07,000
Yes, or it might be -- I think user defaults can be --

479
00:24:07,000 --> 00:24:11,000
they can have an attribute, whether they're secured or not.

480
00:24:11,000 --> 00:24:14,000
It's worth looking into the details,

481
00:24:14,000 --> 00:24:17,000
looking at that blog post that outlines what the problem is,

482
00:24:17,000 --> 00:24:20,000
and this is apparently a real problem,

483
00:24:20,000 --> 00:24:23,000
and presumably the package doesn't have that problem,

484
00:24:23,000 --> 00:24:24,000
so that's nice.

485
00:24:24,000 --> 00:24:29,000
The blog post is linked from the top of the README file,

486
00:24:29,000 --> 00:24:32,000
so it's literally the first link in the file.

487
00:24:32,000 --> 00:24:34,000
Yes. There you go.

488
00:24:34,000 --> 00:24:37,000
So that's Tiny Storage by Christian Selig.

489
00:24:37,000 --> 00:24:38,000
Nice.

490
00:24:38,000 --> 00:24:43,000
My first pick is called Recap by Joe Fabicevic,

491
00:24:43,000 --> 00:24:49,000
and you've also linked to this package in IoStep Weekly from Friday.

492
00:24:49,000 --> 00:24:54,000
And this is a really nice "What's new" screen for your iOS app,

493
00:24:54,000 --> 00:24:55,000
and it's iOS only.

494
00:24:55,000 --> 00:24:57,000
I was actually surprised to see this.

495
00:24:57,000 --> 00:25:00,000
It doesn't even call out iPadOS,

496
00:25:00,000 --> 00:25:04,000
so I'm not sure what the state there is.

497
00:25:04,000 --> 00:25:07,000
It's worth looking into if you need this for the iPad.

498
00:25:07,000 --> 00:25:11,000
But it looks really simple to use.

499
00:25:11,000 --> 00:25:15,000
You have a YAML file where you configure what should be on that screen.

500
00:25:15,000 --> 00:25:22,000
You can give an entry, a title, a description, a SF symbol, name, and a color,

501
00:25:22,000 --> 00:25:24,000
and then it does a really nice layout.

502
00:25:24,000 --> 00:25:27,000
I mean, "What's new" screen, you know what these look like,

503
00:25:27,000 --> 00:25:31,000
and all you really need to do is add the dependency

504
00:25:31,000 --> 00:25:36,000
and write this little YAML file, and then it does it all for you.

505
00:25:36,000 --> 00:25:41,000
And I think this is one of these things that is getting more important

506
00:25:41,000 --> 00:25:47,000
because I hardly look at release notes in the App Store anymore

507
00:25:47,000 --> 00:25:51,000
because I have, like for ages now, I've had auto-update enabled, right?

508
00:25:51,000 --> 00:25:56,000
So apps just update, and I never see what's new.

509
00:25:56,000 --> 00:25:59,000
And I do actually quite like these screens.

510
00:25:59,000 --> 00:26:03,000
I mean, maybe not every small update needs a screen like that,

511
00:26:03,000 --> 00:26:06,000
but if you have, like, bigger changes,

512
00:26:06,000 --> 00:26:09,000
I think that's a really nice way to tell the user, you know,

513
00:26:09,000 --> 00:26:12,000
"This is what's new. Have a look,"

514
00:26:12,000 --> 00:26:16,000
or explain why something might be in a different place or something like that.

515
00:26:16,000 --> 00:26:22,000
So a really nice package to deal with this aspect.

516
00:26:22,000 --> 00:26:24,000
I really like this, too. I thought it was great.

517
00:26:24,000 --> 00:26:28,000
And I think there's a couple of things worth mentioning with this.

518
00:26:28,000 --> 00:26:33,000
I think you're not alone in not reading release notes anymore.

519
00:26:33,000 --> 00:26:36,000
Nobody reads release notes because everybody--

520
00:26:36,000 --> 00:26:39,000
because updates are on by default,

521
00:26:39,000 --> 00:26:42,000
and I don't remember the last time I went into updates

522
00:26:42,000 --> 00:26:44,000
to even see what was pending.

523
00:26:44,000 --> 00:26:47,000
It just takes care of itself, and I never check it,

524
00:26:47,000 --> 00:26:49,000
which means I never see any of the update notes.

525
00:26:49,000 --> 00:26:53,000
It was never the greatest place to put really important information

526
00:26:53,000 --> 00:26:57,000
because a lot of people never checked there.

527
00:26:57,000 --> 00:27:02,000
And even if they did manually update, all they did was hit Update All.

528
00:27:02,000 --> 00:27:04,000
So, yeah, it's never been the best place.

529
00:27:04,000 --> 00:27:09,000
But one thing I liked about this is that you can actually page back

530
00:27:09,000 --> 00:27:13,000
through previous--like it's almost a release notes,

531
00:27:13,000 --> 00:27:15,000
a changelog system as well.

532
00:27:15,000 --> 00:27:19,000
So, yes, you have the one that comes up on the screen when people launch,

533
00:27:19,000 --> 00:27:23,000
but if they're interested, they can page back through previous ones

534
00:27:23,000 --> 00:27:26,000
to see what happened to the app in previous updates.

535
00:27:26,000 --> 00:27:29,000
So I thought that was a nice feature worth mentioning as well.

536
00:27:29,000 --> 00:27:31,000
That's nice. I hadn't even seen that. That's great.

537
00:27:31,000 --> 00:27:32,000
That's great.

538
00:27:32,000 --> 00:27:37,000
So that's Recap by Joe Fabicevic.

539
00:27:37,000 --> 00:27:44,000
My next pick is Location Radius Picker by Eman Basic.

540
00:27:44,000 --> 00:27:50,000
And this is a UI view controller subclass.

541
00:27:50,000 --> 00:27:56,000
So I presume you could wrap it in a UI view controller.

542
00:27:56,000 --> 00:27:59,000
What's the wrapper class that you can wrap it into SwiftUI?

543
00:27:59,000 --> 00:28:06,000
It's designed initially for UI kits rather than SwiftUI,

544
00:28:06,000 --> 00:28:11,000
but it's just a really nice implementation of a control that you don't get

545
00:28:11,000 --> 00:28:14,000
for kind of built in with UI kits,

546
00:28:14,000 --> 00:28:19,000
which is selecting a radius over the top of a map kit map.

547
00:28:19,000 --> 00:28:25,000
So you don't want to just select a single pinpoint on the map,

548
00:28:25,000 --> 00:28:27,000
which I believe it does do.

549
00:28:27,000 --> 00:28:35,000
If you want to give the application a X meter radius around a point,

550
00:28:35,000 --> 00:28:38,000
then this is a really well-designed version of that.

551
00:28:38,000 --> 00:28:40,000
And when you zoom the map in and out,

552
00:28:40,000 --> 00:28:44,000
your selected radius also scales nicely with the map.

553
00:28:44,000 --> 00:28:47,000
It also tells you how big the radius is.

554
00:28:47,000 --> 00:28:51,000
So as you drag the circle out across the map,

555
00:28:51,000 --> 00:28:53,000
you'll see that it starts as, you know,

556
00:28:53,000 --> 00:28:55,000
you drag it once and it's a 50 meter radius,

557
00:28:55,000 --> 00:28:57,000
and you zoom out a little bit and drag it again.

558
00:28:57,000 --> 00:28:59,000
Now it's a two kilometer radius.

559
00:28:59,000 --> 00:29:05,000
And again, what caught my eye with this is a fantastic demo video

560
00:29:05,000 --> 00:29:08,000
at the top of the readme file, which is always really important

561
00:29:08,000 --> 00:29:11,000
if you're building anything that has a visual component.

562
00:29:11,000 --> 00:29:15,000
The very first thing you should do is show people what it looks like.

563
00:29:15,000 --> 00:29:18,000
And it was that that caught my eye.

564
00:29:18,000 --> 00:29:22,000
And yeah, I thought this was just a useful little thing

565
00:29:22,000 --> 00:29:24,000
that you're not going to need this every day,

566
00:29:24,000 --> 00:29:27,000
but when you need it, this seemed like a well-designed one.

567
00:29:27,000 --> 00:29:30,000
Nice. That sounds great.

568
00:29:30,000 --> 00:29:36,000
Okay. My second pick is called Swift Async Operations by Matsuji.

569
00:29:36,000 --> 00:29:39,000
And I only got this GitHub handle here.

570
00:29:39,000 --> 00:29:43,000
Unfortunately, GitHub itself only lists that name as well.

571
00:29:43,000 --> 00:29:46,000
And that's a really interesting library that deals with an API

572
00:29:46,000 --> 00:29:48,000
that I kind of struggle with.

573
00:29:48,000 --> 00:29:53,000
I mean, it's fine, but it feels a bit...

574
00:29:53,000 --> 00:29:57,000
I don't know how to describe it. I'll explain what it's about.

575
00:29:57,000 --> 00:30:02,000
So Async Let is a simple way to start concurrent tasks, right,

576
00:30:02,000 --> 00:30:06,000
in Swift Async Await land.

577
00:30:06,000 --> 00:30:10,000
And you use that when you have a certain number of...

578
00:30:10,000 --> 00:30:12,000
a fixed number of tasks that you want to fire off.

579
00:30:12,000 --> 00:30:15,000
You know, for instance, you know I've got these two URLs to fetch,

580
00:30:15,000 --> 00:30:17,000
and you do Async Let for both of them,

581
00:30:17,000 --> 00:30:21,000
and then you await, and then they run concurrently.

582
00:30:21,000 --> 00:30:26,000
Now, if you have a number n of tasks,

583
00:30:26,000 --> 00:30:29,000
and you don't know an indeterminate number,

584
00:30:29,000 --> 00:30:32,000
and you want to, for instance, create them,

585
00:30:32,000 --> 00:30:34,000
spin off these tasks in a loop,

586
00:30:34,000 --> 00:30:37,000
you would use the With Task Group API.

587
00:30:37,000 --> 00:30:42,000
And that's the thing that I find really, like,

588
00:30:42,000 --> 00:30:44,000
I don't know how to describe it.

589
00:30:44,000 --> 00:30:46,000
Suddenly you need a lot of boilerplate,

590
00:30:46,000 --> 00:30:49,000
where previously Async Let is so lean, right?

591
00:30:49,000 --> 00:30:53,000
You don't even realize, maybe that's even a problem.

592
00:30:53,000 --> 00:30:55,000
You don't realize you're spinning up a task,

593
00:30:55,000 --> 00:30:57,000
but it's a really lean API.

594
00:30:57,000 --> 00:31:02,000
And then suddenly when you need, you know, I don't have just two.

595
00:31:02,000 --> 00:31:04,000
I have n. I need to...

596
00:31:04,000 --> 00:31:07,000
I can't just write a for loop or something, or have a map,

597
00:31:07,000 --> 00:31:09,000
and this is what this package does.

598
00:31:09,000 --> 00:31:11,000
You then have to employ this whole With Task Group thing,

599
00:31:11,000 --> 00:31:14,000
and then the group thing needs to do the add task,

600
00:31:14,000 --> 00:31:16,000
and then at the end you have to await the results,

601
00:31:16,000 --> 00:31:18,000
and there you'd loop.

602
00:31:18,000 --> 00:31:20,000
It's a weird...

603
00:31:20,000 --> 00:31:23,000
You know, you have this progressive disclosure normally,

604
00:31:23,000 --> 00:31:25,000
and this feels like, oh, I'm progressively...

605
00:31:25,000 --> 00:31:28,000
Boof, there's a truck. That hits me.

606
00:31:28,000 --> 00:31:30,000
It's not really progressive.

607
00:31:30,000 --> 00:31:32,000
It's like a cliff you're hitting.

608
00:31:32,000 --> 00:31:33,000
A progressive brick wall.

609
00:31:33,000 --> 00:31:35,000
Yeah, exactly.

610
00:31:35,000 --> 00:31:40,000
So this introduces an Async Map and an Async For Each.

611
00:31:40,000 --> 00:31:43,000
And I know For Each is controversial.

612
00:31:43,000 --> 00:31:46,000
Some people argue it shouldn't even be in the language,

613
00:31:46,000 --> 00:31:51,000
but there is sort of a reason why it perhaps should exist here

614
00:31:51,000 --> 00:31:58,000
in this specific case, and the reason is that both these method calls

615
00:31:58,000 --> 00:32:02,000
have taken optional parameter number of concurrent tasks

616
00:32:02,000 --> 00:32:05,000
where you can control, like map over something,

617
00:32:05,000 --> 00:32:08,000
Async Map over a collection,

618
00:32:08,000 --> 00:32:10,000
and then you can say number of concurrent tasks,

619
00:32:10,000 --> 00:32:13,000
and it'll fan out up to that concurrency

620
00:32:13,000 --> 00:32:16,000
and do the things in concurrent tasks.

621
00:32:16,000 --> 00:32:20,000
And Async For Each is the same, just not--

622
00:32:20,000 --> 00:32:25,000
it's like a proper for loop without returning something like the map does.

623
00:32:25,000 --> 00:32:28,000
I mean, obviously you could abuse map in that same sense,

624
00:32:28,000 --> 00:32:32,000
but just API-wise, that's the distinction.

625
00:32:32,000 --> 00:32:35,000
Now, I haven't looked at the implementation.

626
00:32:35,000 --> 00:32:39,000
Take all of this with a grain of salt because there's lots of Async Awaits

627
00:32:39,000 --> 00:32:42,000
stuff happening, and people are still finding their way

628
00:32:42,000 --> 00:32:44,000
how to best do things.

629
00:32:44,000 --> 00:32:47,000
I really wanted to highlight the package, perhaps not so much

630
00:32:47,000 --> 00:32:51,000
as a thing you should jump and use immediately.

631
00:32:51,000 --> 00:32:57,000
Certainly, if you need it, have a look at the implementation,

632
00:32:57,000 --> 00:33:03,000
but also maybe in talking about whether the With Task Group API

633
00:33:03,000 --> 00:33:09,000
could perhaps have a more sugary variant.

634
00:33:09,000 --> 00:33:15,000
That is a bit nicer to use because I feel like I really--

635
00:33:15,000 --> 00:33:17,000
A, I need to look it up.

636
00:33:17,000 --> 00:33:20,000
I can't just write a With Task Group thing and then the awaiting stuff

637
00:33:20,000 --> 00:33:21,000
at the end.

638
00:33:21,000 --> 00:33:22,000
I need to look it up.

639
00:33:22,000 --> 00:33:23,000
I can't-- for loop, I can write.

640
00:33:23,000 --> 00:33:25,000
A map, I can write.

641
00:33:25,000 --> 00:33:27,000
For each, I can write.

642
00:33:27,000 --> 00:33:28,000
With Task Group, I can't.

643
00:33:28,000 --> 00:33:29,000
I need to look it up.

644
00:33:29,000 --> 00:33:33,000
And I feel like there's a-- that's telling me something.

645
00:33:33,000 --> 00:33:37,000
I think that API could perhaps be easier,

646
00:33:37,000 --> 00:33:43,000
and maybe that package has ideas what that API could look like.

647
00:33:43,000 --> 00:33:47,000
Anyway, that's why I thought it was interesting.

648
00:33:47,000 --> 00:33:50,000
Swift Async Operations by Matsuchi.

649
00:33:50,000 --> 00:33:53,000
And it's worth mentioning-- you briefly mentioned it there.

650
00:33:53,000 --> 00:33:58,000
On the topic, we quite often say when we're talking about packages here,

651
00:33:58,000 --> 00:34:02,000
we quite often term them recommendations,

652
00:34:02,000 --> 00:34:08,000
but all we're ever saying with these picks of packages is this is something

653
00:34:08,000 --> 00:34:10,000
that we've found interesting.

654
00:34:10,000 --> 00:34:13,000
This is not a, you know, we've checked through every line of code

655
00:34:13,000 --> 00:34:16,000
and made sure that this package is perfect in every way.

656
00:34:16,000 --> 00:34:19,000
Like some of the packages we've talked about today are, for example,

657
00:34:19,000 --> 00:34:24,000
six days old, and they're being mentioned more as a notable event

658
00:34:24,000 --> 00:34:29,000
rather than an outright recommendation because we can't possibly have used

659
00:34:29,000 --> 00:34:33,000
all the packages we talk about on this podcast.

660
00:34:33,000 --> 00:34:36,000
Although we try, if you look at the number of dependencies

661
00:34:36,000 --> 00:34:42,000
in the Swift Package Index Server project, we are certainly trying.

662
00:34:42,000 --> 00:34:46,000
Well, a lot of those dependencies come with vapor, right?

663
00:34:46,000 --> 00:34:50,000
Well, I still maintain we are the Swift Package Index.

664
00:34:50,000 --> 00:34:56,000
We have an obligation to just try them all.

665
00:34:56,000 --> 00:35:01,000
And with that, it brings another episode to a close.

666
00:35:01,000 --> 00:35:09,000
So I think we will call it a day there and speak to you next time.

667
00:35:09,000 --> 00:35:11,000
And for now, we will say goodbye.

668
00:35:11,000 --> 00:35:13,000
Yep. See you next time. Bye-bye.