1
00:00:00,240 --> 00:00:02,000
Well, Happy New Year Sven.

2
00:00:02,000 --> 00:00:02,720
Happy New Year.

3
00:00:02,720 --> 00:00:05,200
Did you have a good break?

4
00:00:05,200 --> 00:00:11,840
Oh, absolutely. Yeah, good break. Very relaxed. Not quite as cold as in Germany or in other

5
00:00:11,840 --> 00:00:15,520
places. I've seen it's been really cold in Sweden. There's someone I'm following on

6
00:00:15,520 --> 00:00:20,640
Mastodon and he's been subjected to minus 40 degrees Celsius.

7
00:00:20,640 --> 00:00:24,880
Okay, that's a lot colder than it is here too.

8
00:00:25,600 --> 00:00:30,560
Yeah, no, I can't stand the cold and just reading that gave me the shivers.

9
00:00:30,560 --> 00:00:40,640
It's not very warm here. It's going to hit two degrees above zero on Friday this week,

10
00:00:40,640 --> 00:00:43,040
but it's certainly not minus 40.

11
00:00:43,040 --> 00:00:44,880
Yeah, no, that's just way too cold.

12
00:00:44,880 --> 00:00:46,960
Did you have a good break as well?

13
00:00:46,960 --> 00:00:50,160
Yes, I did. Thank you. Nice to see family, friends,

14
00:00:50,800 --> 00:00:57,600
spend some time away from a computer a little bit, which was always nice to do, but ready

15
00:00:57,600 --> 00:01:01,120
to get back to it and raring to go for 2024.

16
00:01:01,120 --> 00:01:02,000
Excellent.

17
00:01:02,000 --> 00:01:06,080
And maybe we should start there actually. So we should maybe talk about

18
00:01:06,080 --> 00:01:12,800
some of the things that we hope to get to in 2024 with the package index.

19
00:01:12,800 --> 00:01:16,000
Yeah, that sounds like a plan. We used to post

20
00:01:17,600 --> 00:01:27,600
like things way back and we held that up for a couple of quarters, but then due to the way we

21
00:01:27,600 --> 00:01:32,480
organise stuff that sort of didn't, it wasn't really feasible anymore. It didn't make much

22
00:01:32,480 --> 00:01:37,200
sense anymore, but I think on a yearly basis, it's a nice thing to maybe look forward what

23
00:01:37,200 --> 00:01:38,080
we're planning to do.

24
00:01:38,080 --> 00:01:41,760
Yes. And of course, all of the things we're about to talk to today can change.

25
00:01:41,760 --> 00:01:42,880
And will.

26
00:01:42,880 --> 00:01:45,920
And will. Exactly. Yeah, exactly.

27
00:01:46,800 --> 00:01:54,000
So, yeah, I think just in terms of I briefly thought about what's the rough plan. And I think

28
00:01:54,000 --> 00:01:58,320
one of the things that I'd like to continue working on, and we started doing that a bit is

29
00:01:58,320 --> 00:02:06,240
dependencies. We'll also talk a bit about that later on in the news section. We've started

30
00:02:06,240 --> 00:02:12,000
tracking dependencies quite early on by just capturing the resolve dependencies,

31
00:02:12,000 --> 00:02:17,280
which is the full dependency tree you get in a Swift package after package resolution. So that's

32
00:02:17,280 --> 00:02:23,120
the transient dependencies included and the test target dependencies. That's literally everything

33
00:02:23,120 --> 00:02:26,960
your package touches. And that's been in our database for quite a while,

34
00:02:26,960 --> 00:02:35,600
but that's also not the best thing to report really for people who are inspecting a package.

35
00:02:35,600 --> 00:02:39,360
You don't necessarily are interested in test dependencies or all the dependencies. You sort

36
00:02:39,360 --> 00:02:45,680
of maybe want the first and direct dependencies and that sort of thing. We're starting to pick up

37
00:02:45,680 --> 00:02:52,880
and we have those in the database as well now, the direct dependencies. So we can report in a bit

38
00:02:52,880 --> 00:02:58,240
more detail what we've got, but there's a lot more work to do here to also prune up the test

39
00:02:58,240 --> 00:03:01,760
dependencies and all that. And I think that's going to be really exciting because it's one of

40
00:03:01,760 --> 00:03:09,760
the things that will give us a bigger ecosystem wide overview, just to the things you can do then

41
00:03:09,760 --> 00:03:17,200
by looking at what packages are sort of central. They have lots of dependencies, packages that

42
00:03:17,200 --> 00:03:21,840
depend on them. Is that dependency? Yeah, that's dependence. Now that's dependence or whatever,

43
00:03:21,840 --> 00:03:30,560
dependence. That's the one. I'm kind of imagining we'd be able to maybe draw some graphs or

44
00:03:30,560 --> 00:03:38,080
something around like these webs and see packages that are very cool. And we've talked in the past

45
00:03:38,080 --> 00:03:46,480
about when we talked about the NPM ecosystem and the crates, the Rust ecosystem. There's some

46
00:03:46,480 --> 00:03:52,320
statistic and analysis that they've done in their ecosystems that would be interesting to do in

47
00:03:52,320 --> 00:03:57,760
Swift, in the Swift ecosystem. I'd really love to do that, try and replicate that, see if we see

48
00:03:57,760 --> 00:04:06,640
some of the same problems there with the circular dependency graphs, which were kind of weird.

49
00:04:06,640 --> 00:04:10,720
I wonder if there's something like that in Swift as well. All that sort of stuff falls

50
00:04:10,720 --> 00:04:15,280
under that umbrella that I'd really love to focus on in the coming year.

51
00:04:15,280 --> 00:04:20,960
And I know you've started doing a little bit of this already, not so much on the dependencies

52
00:04:20,960 --> 00:04:27,120
display in the package index, but so building on some of the work that we already have in the

53
00:04:27,120 --> 00:04:33,040
project for getting that list of complete, that total list of every type of dependency that we

54
00:04:33,040 --> 00:04:39,520
currently have. There was a nightly process, or there still is a nightly process that runs

55
00:04:39,520 --> 00:04:48,000
through GitHub actions, which goes and tries to find any dependencies that are dependent of,

56
00:04:49,200 --> 00:04:58,880
sorry, that depend, no. I got it wrong. It finds any packages that are not in the package index,

57
00:04:58,880 --> 00:05:08,240
which are depended on by other packages. And that process used to take about eight or nine

58
00:05:08,240 --> 00:05:13,120
hours to run something like that every night. Yeah, yeah, exactly. It had increased to,

59
00:05:13,120 --> 00:05:18,880
I think, nine and a half hours now, even because we've grown since we started doing this.

60
00:05:19,840 --> 00:05:28,560
And yeah, this is a long one. And I know that we've, well, you just put some work into,

61
00:05:28,560 --> 00:05:35,600
and we've just put into production a version of that script that now uses the dependency work

62
00:05:35,600 --> 00:05:43,520
that we do in the main package index to shortcut all of those searching for dependency steps and

63
00:05:43,520 --> 00:05:50,000
just read the dependencies out of our application. And that took the job from nine and a half hours

64
00:05:50,000 --> 00:05:55,920
down to certainly less than half an hour, right? Yeah, it's like five minutes or something like

65
00:05:55,920 --> 00:06:02,160
that, because it's effectively, we were previously crawling every package, downloading the package

66
00:06:02,160 --> 00:06:08,800
manifest and doing a package resolution to get the package resolved out of it, which is something we

67
00:06:08,800 --> 00:06:13,680
already do continuously in the Swift package index. So we have those things in a database,

68
00:06:13,680 --> 00:06:19,360
and this was effectively just ripping that out, asking the database for everything in one go.

69
00:06:19,360 --> 00:06:26,240
And that query is even faster. I mean, that query literally runs in 50, 100 milliseconds,

70
00:06:26,240 --> 00:06:32,720
and it's the downloading of the data that maybe takes maybe half a second. And the remaining time

71
00:06:32,720 --> 00:06:39,040
is then to validate these packages. But we have a very fast way now to find out which packages

72
00:06:39,040 --> 00:06:45,760
are being referenced but aren't in the index yet. And that was really, really helpful to get that

73
00:06:45,760 --> 00:06:51,040
nightly process under control. It also helped us find packages that we didn't actually find with

74
00:06:51,040 --> 00:06:57,520
the other process in the past, because the way the other process worked was to download the

75
00:06:57,520 --> 00:07:03,840
manifest of the main branch, of the latest version of the main branch. But what happens then is that

76
00:07:03,840 --> 00:07:08,960
we have packages in the index that are old, that don't have new revisions, and they never moved

77
00:07:08,960 --> 00:07:13,760
forward. And they were actually referencing, they had all the manifests that were referencing

78
00:07:13,760 --> 00:07:18,080
package versions that weren't, that were only live at the time, but aren't live anymore.

79
00:07:18,080 --> 00:07:23,440
This sounds probably way more complicated, and it's hard to follow. But the thing is,

80
00:07:23,440 --> 00:07:28,400
we're now unearthing packages that are being referenced that we didn't actually see before.

81
00:07:28,400 --> 00:07:36,640
So if you are following our Swift package updates, Mastodon account, you will see loads

82
00:07:36,640 --> 00:07:40,720
of new packages appearing. And those are the packages we're now finding and adding to the

83
00:07:40,720 --> 00:07:48,960
index because we've made that change. And we've also changed, we're now accepting forks as that

84
00:07:48,960 --> 00:07:54,640
people are depending on, and adding them to the index, because they are packages like any other

85
00:07:54,640 --> 00:08:00,480
package, and they're being used. So they should actually be in the index, so we can properly

86
00:08:00,480 --> 00:08:05,360
account for all the dependencies we've got and have them in the index.

87
00:08:05,360 --> 00:08:14,960
And this is the point I was going to make, and it's the influx of these additional dependency

88
00:08:14,960 --> 00:08:22,480
packages has really tripped me up this week and made... So when I'm preparing for this podcast,

89
00:08:22,480 --> 00:08:26,800
I go through the list of new packages to see what's interesting and what's been added.

90
00:08:26,800 --> 00:08:32,720
And with all these, quite a significant number of packages, more than 100 packages being added

91
00:08:32,720 --> 00:08:37,680
by this script, I made that job much more difficult than usual, because it's a whole

92
00:08:37,680 --> 00:08:43,920
load of forks and packages that I just depended on that have maybe been around for years and years

93
00:08:43,920 --> 00:08:50,640
and years that we might not feature on a podcast like this, but as you say, should be in the index.

94
00:08:50,640 --> 00:08:56,320
And one thing that, in the context of what are we going to work on this year,

95
00:08:56,320 --> 00:09:01,920
one thing that this has really highlighted for me is that we quite desperately need a feature

96
00:09:01,920 --> 00:09:08,880
which shows which packages are forks of other packages. And if we have the other package in

97
00:09:08,880 --> 00:09:15,600
the index, then we should also refer to that package because it's quite... In fact, I was

98
00:09:15,600 --> 00:09:24,720
tripped up myself by a fork of plot, John Sundell's plot library, which is an HTML generation library,

99
00:09:24,720 --> 00:09:30,800
which we use in the package index. And I was going through the list of packages and I saw plot go up

100
00:09:30,800 --> 00:09:34,800
and I thought, "That's strange. We've definitely got plot." And I opened it in my browser and

101
00:09:34,800 --> 00:09:38,800
looked at it and it took me a second to realize that it was my fork of plot that...

102
00:09:38,800 --> 00:09:43,680
Was it your own fork? Yeah. I saw that flow come through.

103
00:09:43,680 --> 00:09:50,240
And that deserves to be in the index, but it's also... It should be really obvious. Yeah,

104
00:09:50,240 --> 00:09:54,960
it should be really obvious that that is a fork and not a brand new project.

105
00:09:54,960 --> 00:09:58,800
Well, if any fork deserves to be in it, it's your own, right?

106
00:10:01,120 --> 00:10:05,600
Well, it takes my total number of packages in the index up to two. We've got left pad,

107
00:10:05,600 --> 00:10:12,080
which is the test package that we have. And now a fork of somebody else's work.

108
00:10:12,080 --> 00:10:18,960
Nice. So yeah, that feature, we just need to

109
00:10:18,960 --> 00:10:26,560
add a little bit of extra metadata to those fork packages. So just be careful if you see

110
00:10:26,560 --> 00:10:30,720
new packages that you think should already be in the index, it may be a fork right now,

111
00:10:30,720 --> 00:10:35,840
because we're not very clearly displaying that. There's a couple of things that I'm

112
00:10:35,840 --> 00:10:40,720
interested in working on in terms of broad kind of themes for this year.

113
00:10:40,720 --> 00:10:48,800
One is I'd love to do some more work on the package score feature. So we've talked about

114
00:10:48,800 --> 00:10:54,880
this in previous episodes of the podcast and in blog posts recently as well. We have a

115
00:10:55,680 --> 00:11:02,480
internal, in fact, not just internal anymore, it's now publicly available package score. And

116
00:11:02,480 --> 00:11:10,720
you can see the score for any package that's in the index. But the list of kind of factors that we

117
00:11:10,720 --> 00:11:16,880
use to score each package could be improved. And there's a thread open in the discussions

118
00:11:16,880 --> 00:11:23,440
forum on the package index GitHub project, which we'll put a link to in the show notes.

119
00:11:24,880 --> 00:11:28,240
If you have opinions on that, there's already a discussion going there.

120
00:11:28,240 --> 00:11:37,040
I would like to do some more work on that this year, and kind of bulk up the significance of,

121
00:11:37,040 --> 00:11:40,480
not the significance, because it won't be any more significant than it is at the moment,

122
00:11:40,480 --> 00:11:51,920
but bulk up the kind of the evaluation of packages to promote better packages in the

123
00:11:51,920 --> 00:11:59,200
index. So that's one thing I want to work on this year. And I think the other is something we've

124
00:11:59,200 --> 00:12:06,640
been kind of discussing a little bit is over time, I don't know whether you remember, actually,

125
00:12:06,640 --> 00:12:10,560
I know you will Sven, but I don't know whether anyone else remembers that when

126
00:12:10,560 --> 00:12:22,960
the package index first started, it was entirely a metadata, metadata only information on the

127
00:12:22,960 --> 00:12:29,840
package page. So we didn't actually display the readme file until quite a while after we launched.

128
00:12:29,840 --> 00:12:36,160
And instead, it was it was purely metadata, it was it was a lot of the metadata that you see today,

129
00:12:36,880 --> 00:12:42,160
even build compatibility and those results on the package page, and then a link to

130
00:12:42,160 --> 00:12:48,400
the GitHub repository. And of course, over time, we and in fact, it was never our intention not

131
00:12:48,400 --> 00:12:52,400
to have the readme file on there, it was just a matter of, you know, getting things done.

132
00:12:52,400 --> 00:12:59,200
And obviously, we did add the readme file. And here we are today. But over time, that metadata

133
00:12:59,200 --> 00:13:06,080
section has grown and grown and the compatibility matrix takes up quite a lot of space. And it

134
00:13:06,080 --> 00:13:11,840
pushes that readme too far down the page. So one of the things that we've been chatting about this

135
00:13:11,840 --> 00:13:23,680
morning, actually, is whether we can look at that page design again, and maybe think about trying to

136
00:13:23,680 --> 00:13:28,240
pull that readme file back up the page a little bit, we're not going to get rid of the metadata,

137
00:13:28,240 --> 00:13:32,320
there's definitely going to be metadata at the top, because that metadata is really important.

138
00:13:33,920 --> 00:13:39,120
But it would also be good to have at least the first few lines of the readme visible

139
00:13:39,120 --> 00:13:42,720
on a reasonably sized screen, which is currently not the case.

140
00:13:42,720 --> 00:13:48,000
Yeah, definitely. I think the there's ways to condense that down a bit, I think,

141
00:13:48,000 --> 00:13:54,800
especially going forward, we might see fewer Swift versions that we need to display,

142
00:13:54,800 --> 00:13:59,600
you know, that sort of stuff. And the compatibility matrix, as you mentioned,

143
00:13:59,600 --> 00:14:05,040
might be might need to shrink down a bit anyway. It's we got all these Apple platforms, maybe

144
00:14:05,040 --> 00:14:09,840
there's something we can do there. It's it's, it would be nice to pull up the readme a bit more.

145
00:14:09,840 --> 00:14:10,960
Yeah, agreed.

146
00:14:10,960 --> 00:14:14,240
But of course, I'm sure we'll do a whole load of other things as well.

147
00:14:14,240 --> 00:14:17,840
Yeah. Just to mention, there's there's no year without new Swift versions. So that's

148
00:14:17,840 --> 00:14:21,360
certainly something we'll be looking at trying to add those as early as possible.

149
00:14:21,360 --> 00:14:29,040
Who knows when Swift 6 will come out if it's this year. Rest assured, we'll be looking at

150
00:14:29,040 --> 00:14:35,040
compatibility info there because we we know that Swift 6 will have will be potentially

151
00:14:35,040 --> 00:14:42,560
have sourcing compatibility. So it's it is possible to have syntax changes there.

152
00:14:42,560 --> 00:14:48,160
That's allowed. So that's allowed. That's something that is that is in the cards,

153
00:14:48,160 --> 00:14:52,800
I should say. And we'll definitely make sure that we test this early so people can

154
00:14:53,520 --> 00:15:01,760
can maybe use us there as the if they haven't set their own CI up or or just want to rely

155
00:15:01,760 --> 00:15:05,360
on another service to have a look there and give an overview. So we're definitely trying to be

156
00:15:05,360 --> 00:15:10,480
prompt with testing for Swift 6 as much as possible.

157
00:15:10,480 --> 00:15:17,360
So when we've been doing a little bit of planning already with this and talking about Swift 6 and

158
00:15:17,360 --> 00:15:23,280
you know, there's a Swift 6 strict compatibility mode, which is the concurrency checking that's

159
00:15:23,280 --> 00:15:28,560
coming in that's potentially source breaking in terms of like there were things that with Swift 5

160
00:15:28,560 --> 00:15:34,640
it would let you do and in Swift 6 it will it will strictly stop you doing some of those things.

161
00:15:34,640 --> 00:15:42,000
And there's two modes you can run the Swift 6 compiler in, which is with strict compatibility

162
00:15:42,000 --> 00:15:47,520
testing for concurrency issues on, which I believe is going to be the default for Swift 6.

163
00:15:47,520 --> 00:15:53,680
And then Swift 6 in Swift 5 mode, which is if you want to use the Swift 6 compiler,

164
00:15:53,680 --> 00:16:01,520
but you still need Swift 5 concurrency checking, then you can switch the Swift 6 compiler into

165
00:16:01,520 --> 00:16:07,200
that mode, which we're not going to test for explicitly. But what we will be doing

166
00:16:07,200 --> 00:16:13,280
is testing the latest version of Swift 5 at that point as well. So you'll have Swift 6

167
00:16:13,280 --> 00:16:19,120
compatibility with strict mode on and then 5.9, 5.10, whatever it is at the point that

168
00:16:19,120 --> 00:16:26,080
Swift 6 comes out, we'll be testing the Swift 5 mode. Have I got that right?

169
00:16:26,080 --> 00:16:33,200
Yeah, exactly. I think there's, we don't expect there to be a significant difference or any

170
00:16:33,200 --> 00:16:39,040
difference at all between Swift in 5 mode versus the latest 5 version at that time. So that's why

171
00:16:39,040 --> 00:16:45,840
we're not really going to, we're not planning to spend effort on running those two modes in parallel.

172
00:16:45,840 --> 00:16:54,080
Exactly. So, but of course we don't know, I don't know whether the public, the schedule

173
00:16:54,080 --> 00:17:00,480
for that has been announced yet, but I'm not aware of it. So it's something that we will do

174
00:17:00,480 --> 00:17:06,240
as and when those versions come out. Yeah. And well, I think there's no new

175
00:17:06,240 --> 00:17:10,640
Apple platforms to plan for this year, right? Vision OS just came out and is...

176
00:17:10,640 --> 00:17:16,400
Well, the good news is we already support it. Yeah, we already do. And I'm not aware of any

177
00:17:16,400 --> 00:17:24,000
rumors about new Apple hardware or OS releases that we might be planning for. So I think on

178
00:17:24,000 --> 00:17:29,680
that front, we're well covered at least. There is no new Apple hardware until the

179
00:17:29,680 --> 00:17:35,760
day that Tim Cook announces it, right? It doesn't exist until he steps on stage.

180
00:17:35,760 --> 00:17:39,360
That's how that works. Yeah, exactly. Yeah. I think you're right.

181
00:17:39,360 --> 00:17:44,720
I think Vision Pro and obviously the Vision OS SDK, which did get announced, I think yesterday,

182
00:17:44,720 --> 00:17:53,520
the release date for that, which I think is February 2nd, maybe, that we already support

183
00:17:53,520 --> 00:18:00,080
in our compatibility matrix. What we will do is we'll update the version of Xcode that we use to

184
00:18:00,080 --> 00:18:05,760
do that compatibility checking to 15.2, which again, I believe was released yesterday,

185
00:18:05,760 --> 00:18:11,200
but really no changes that we need to do there. Yeah, exactly. And my understanding is the

186
00:18:11,200 --> 00:18:21,520
515.2 beta one, I believe that we were using already had the... My understanding is how the

187
00:18:21,520 --> 00:18:28,320
Vision OS SDK version that is actually shipping. So there won't be like the compatibility right now

188
00:18:28,320 --> 00:18:36,560
should be up to date already, even when we change to the newest 515.2 version, that should all

189
00:18:36,560 --> 00:18:39,680
remain the same, fingers crossed. That's great.

190
00:18:39,680 --> 00:18:44,960
There is another bit of news we may want to briefly talk about. And that's a really interesting

191
00:18:44,960 --> 00:18:51,600
post I saw coming through this week on Mastodon. And that's a blog post about

192
00:18:52,400 --> 00:18:59,200
when everything becomes too much by Frost Abukadi. Did you see that, Dave? Did you have

193
00:18:59,200 --> 00:19:03,280
a chance to look through that post? I did. You sent me a link to this earlier

194
00:19:03,280 --> 00:19:07,920
today. And I did. I did give it a read. Yeah. So this is really fascinating. And

195
00:19:07,920 --> 00:19:14,480
what a mess. What a mess. Yeah. And this is not about pointing fingers or just, you know,

196
00:19:14,480 --> 00:19:21,360
laughing about what's going on in NPM. This is just general ecosystem stuff. And NPM

197
00:19:22,320 --> 00:19:28,880
is pretty much, you know, it's a huge ecosystem, like orders of magnitude bigger. And it's sort of

198
00:19:28,880 --> 00:19:35,520
the things they hit, they are going down paths that the Swift ecosystem hasn't even begun walking

199
00:19:35,520 --> 00:19:41,440
down yet. So there's interesting stuff there. You could say they're stress testing dependency

200
00:19:41,440 --> 00:19:49,040
management. Pretty much, yes. Yes, they definitely are. And some of this is inherent in how

201
00:19:49,600 --> 00:19:58,400
the ecosystem works. I think it is fair to say that node packages are smaller. You know,

202
00:19:58,400 --> 00:20:05,280
they bundle up smaller chunks of functionality into smaller packages. And that by nature then

203
00:20:05,280 --> 00:20:11,120
have way more dependencies and all that. And that has a knock-on effect to how that works. But

204
00:20:11,120 --> 00:20:18,160
that is just one aspect of it. And the other is just more exposure to more people that try

205
00:20:18,160 --> 00:20:24,000
things. And what this is about is that someone created an NPM package called everything,

206
00:20:24,000 --> 00:20:31,200
which, well, depends on everything. They have effectively made this package depend on every

207
00:20:31,200 --> 00:20:39,120
package in the NPM registry. And just think about what that means. If someone went on to do NPM

208
00:20:39,120 --> 00:20:46,720
install of that package, they would effectively DDoS themselves because it would start downloading

209
00:20:46,720 --> 00:20:55,920
every package. And this just sort of spiraled out of control because it compounded with another

210
00:20:55,920 --> 00:21:01,200
problem that happened in 2016. And that was the LeftPad incident.

211
00:21:01,200 --> 00:21:04,880
Ah, LeftPad gets a second mention of the episode.

212
00:21:04,880 --> 00:21:13,440
Yeah, second mention. There you go. So in 2016, the NPM world broke because the author of this

213
00:21:13,440 --> 00:21:18,720
LeftPad package removed it at the time. And this was actually a package that was used in lots and

214
00:21:18,720 --> 00:21:25,120
lots and lots of other packages. And that led to problems because then they wouldn't build anymore.

215
00:21:25,120 --> 00:21:30,160
Lots of CI systems, is my understanding, started breaking and failing because they couldn't resolve

216
00:21:30,160 --> 00:21:37,120
that package at build time and all that. And as a consequence of that mess at the time,

217
00:21:37,760 --> 00:21:44,320
they established a rule that you can't unpublish a package once another package depends on it.

218
00:21:44,320 --> 00:21:50,000
And now you can imagine what happened once everything started depending on every package

219
00:21:50,000 --> 00:21:55,600
in NPM. That meant that no package could actually be unpublished anymore. So it was

220
00:21:55,600 --> 00:22:01,840
effectively blocking everyone from unpublishing their packages after this. And just imagining

221
00:22:01,840 --> 00:22:07,680
about how, you know, one thing that was made or one rule that was implemented to fix one thing

222
00:22:07,680 --> 00:22:14,080
can then completely backfire if another thing goes horribly wrong or, you know, another,

223
00:22:14,080 --> 00:22:22,640
you could call it an abuse case happens and sort of messes everything up. I don't want to be in

224
00:22:22,640 --> 00:22:28,800
the shoes of people trying to manage this whole mess, but it must have been really horrific.

225
00:22:29,440 --> 00:22:35,360
I think they found a solution in the end by just pulling the whole org down of the people who

226
00:22:35,360 --> 00:22:39,360
published this. The people themselves actually were apologetic when they realized what they've

227
00:22:39,360 --> 00:22:42,960
done. They want to do the right thing and unpublish the package, but they couldn't

228
00:22:42,960 --> 00:22:48,480
themselves anymore because they'd been blocked out of unpublishing by, I guess, someone using

229
00:22:48,480 --> 00:22:54,400
their package or something like that. I don't remember what the actual effect there was,

230
00:22:54,400 --> 00:23:00,800
but it was just a big mess, but quite interesting as a look ahead.

231
00:23:00,800 --> 00:23:09,040
I think it said in the post that the solution was to make the repositories, the everything

232
00:23:09,040 --> 00:23:16,880
repositories private. And I think that's the workaround that they got to, because you can't

233
00:23:16,880 --> 00:23:21,200
stop somebody taking a repository private. So they must have had to deal with that situation.

234
00:23:21,200 --> 00:23:25,680
And I think that's what let them unwind this, if I read the post correctly.

235
00:23:25,680 --> 00:23:34,160
But I mean, I do feel for the person who did this, because I genuinely believe that it was

236
00:23:34,160 --> 00:23:42,240
done as a little bit of a lighthearted joke, or certainly its intent was a lighthearted joke.

237
00:23:43,440 --> 00:23:52,640
But what a mess. Yeah, I mean, it's, can you imagine sitting there and suddenly realizing,

238
00:23:52,640 --> 00:23:58,640
you know, it's like when that production incident happens and you suddenly realize you are connected

239
00:23:58,640 --> 00:24:03,760
to the wrong database when you drop the tables. That's the sort of feeling that must go through

240
00:24:03,760 --> 00:24:09,280
you. I mean, unless you really do it with the intention of breaking stuff. But if you didn't,

241
00:24:09,280 --> 00:24:16,000
and I don't think they really did, then that is rough.

242
00:24:16,000 --> 00:24:17,680
And it's the kind of thing, I mean, certainly,

243
00:24:17,680 --> 00:24:29,120
Swift is a very different dependency environment than NPM. And we don't have this kind of situation,

244
00:24:29,120 --> 00:24:35,040
or even really the potential yet for this kind of situation. But I think it's good for us to be

245
00:24:35,760 --> 00:24:41,680
aware of what's happening in these other dependency environments. And certainly this one,

246
00:24:41,680 --> 00:24:46,400
when, as I read more and more of this post, I thought, "Oh, this is, oh yeah, this is really,

247
00:24:46,400 --> 00:24:51,040
it's really, really bad." I would encourage you to read the post. It's really good. Yeah.

248
00:24:51,040 --> 00:24:56,240
- Yeah, we'll add a link to the show notes for people to read up on this.

249
00:24:56,240 --> 00:24:59,200
Shall we do some packages or...

250
00:24:59,200 --> 00:25:04,560
- Yeah, we could do some packages. Actually, I have a bonus extra little package,

251
00:25:04,560 --> 00:25:12,000
which is not really a package recommendation this time. Well, but it's not in my normal theme of not

252
00:25:12,000 --> 00:25:16,960
recommending a package. There may be one of those coming up later though. This was something I

253
00:25:16,960 --> 00:25:24,560
spotted as I was doing a troll through the RSS feed. And I really liked the marketing approach

254
00:25:24,560 --> 00:25:31,520
that this package has, which is to have no readme file whatsoever. So there is no information about

255
00:25:31,520 --> 00:25:38,160
what this package does in the readme file at all. The name of the package is VGSL and the package

256
00:25:38,160 --> 00:25:43,600
description says everything you really need to know. It's a very good Swift library. So that's

257
00:25:43,600 --> 00:25:47,840
all you need to know. You should import this package immediately because it's a very good Swift

258
00:25:47,840 --> 00:25:59,360
library. So, but no, I do have three actual recommendations as well. And the first of them

259
00:25:59,360 --> 00:26:08,480
is by Daniel Lyons and it's called Plus Night Mode. And one thing that I... So I bought a new

260
00:26:08,480 --> 00:26:15,360
watch this year in September or October, whenever they came out. And I don't know whether it's

261
00:26:15,360 --> 00:26:21,040
something specific to the new watch. I think it may be to do with a new watch face, but when the

262
00:26:21,040 --> 00:26:27,840
ambient light in the room is dark, the face and everything on it turns red, which is a really nice

263
00:26:27,840 --> 00:26:33,920
way to not strain your eyes in the evening, or if you wake up at night or something like that and

264
00:26:33,920 --> 00:26:40,000
try and look at your watch. And it's a... So everything goes kind of monochrome, but not

265
00:26:40,000 --> 00:26:50,080
black and white, red and black. And this package by Daniel is a Swift UI view modifier, which you

266
00:26:50,080 --> 00:26:56,320
can add to the bottom of any view hierarchy. So your entire navigation stack, for example,

267
00:26:56,320 --> 00:27:01,920
could have this view modifier on it called Observing Night Mode. And you can pass a switch,

268
00:27:01,920 --> 00:27:08,480
a Boolean in there to turn night mode on or off, which is something you'd have to track yourself.

269
00:27:08,480 --> 00:27:15,280
So this would be an app specific feature. And it basically turns every view in that view hierarchy

270
00:27:15,280 --> 00:27:24,080
into a red and black monochrome view, no matter what the original appearance of it was. And I

271
00:27:24,080 --> 00:27:27,040
think that's lovely. I think, first of all, there's a couple of nice things. I think it's a

272
00:27:27,040 --> 00:27:36,000
great feature. But secondly, I love the kind of cascading nature of Swift UI view modifiers in

273
00:27:36,000 --> 00:27:40,480
that if you add them to the top level, then you can just do something like this, which would be

274
00:27:40,480 --> 00:27:46,480
very difficult to manage in UI kits. I mean, you could still do it in UI kit, but it would not be

275
00:27:46,480 --> 00:27:52,640
as easy as adding one view modifier in a UI kit. So I like that. And I thought it was worth mentioning.

276
00:27:52,640 --> 00:27:57,600
- Yeah, I love that about Swift UI as well. I think the redacted stuff works the same way,

277
00:27:57,600 --> 00:28:05,760
right? Where you can stub in, I don't know how best to describe it, redacted UI elements,

278
00:28:05,760 --> 00:28:11,120
like text is not displayed as text, but as placeholders, like rectangles and stuff. I think

279
00:28:11,120 --> 00:28:16,640
that's really nice and really powerful that you can just tack this on and everything just changes

280
00:28:16,640 --> 00:28:20,160
into a different mode. I think that's really fascinating and super useful.

281
00:28:20,160 --> 00:28:25,360
- I hope apps take advantage of this because I'd love to see this feature in apps that I use.

282
00:28:25,360 --> 00:28:31,360
- Yeah, I have the same. I love this about the watch where it turns red. It's really nice.

283
00:28:31,360 --> 00:28:41,440
Right. My first pick is called package-benchmark by Joachim Masila.

284
00:28:41,440 --> 00:28:46,880
And this is a great package when you're looking to benchmark your code.

285
00:28:47,920 --> 00:28:53,840
What it effectively does, it gives you a function or instrumentation to run a closure that gets

286
00:28:53,840 --> 00:29:00,880
benchmarked. And it supports many, many metrics like CPU time, both like actual CPU time or

287
00:29:00,880 --> 00:29:08,880
work clock time, throughput, memory allocations, threads, like how many threads you're using,

288
00:29:08,880 --> 00:29:16,560
disk stats, all sorts of things. There's an amazing range of metrics you can track.

289
00:29:17,680 --> 00:29:22,160
And I've been following this package for quite a long time, but I've always delayed talking about

290
00:29:22,160 --> 00:29:28,320
it because I wanted to really give it a try. And it was clear from looking at the readme that this

291
00:29:28,320 --> 00:29:34,720
is super comprehensive approach to benchmarking, but yet you'd also need to invest a little time

292
00:29:34,720 --> 00:29:40,720
to understand what it reports and why that is important. That sort of held me back until I

293
00:29:40,720 --> 00:29:48,960
actually sat down and tried using it. And it's not because the package itself is making this

294
00:29:48,960 --> 00:29:55,280
complicated. It's because the topic is actually complicated and more complicated than you might

295
00:29:55,280 --> 00:30:02,720
think. And that these details aren't ones that you should just gloss over and just take an average or

296
00:30:02,720 --> 00:30:08,080
minimum when you benchmark stuff, because that's the thing you sort of reach for. I certainly,

297
00:30:08,720 --> 00:30:13,200
whenever I benchmarked something in the past, you run it a few times, you look at it, well,

298
00:30:13,200 --> 00:30:20,080
there's not too much jitter. I'll take the best one. You never really know what you're doing.

299
00:30:20,080 --> 00:30:27,520
Typically when you measure, you do it a few times, you maybe calculate an error rate based on the

300
00:30:27,520 --> 00:30:33,520
standard deviation, that sort of stuff. The thing is, when you do this, there are certain assumptions

301
00:30:33,520 --> 00:30:39,600
that go in when that is actually valid and when it isn't. And mostly, almost always when you're

302
00:30:39,600 --> 00:30:47,040
measuring benchmarks, these assumptions are wrong because of the way the distributions are shaped,

303
00:30:47,040 --> 00:30:52,880
you can't actually calculate a standard deviation. And it doesn't make sense. And the framework

304
00:30:52,880 --> 00:31:00,320
really leans into that. So what it does when you run a benchmark, it gives you so-called percentiles.

305
00:31:00,320 --> 00:31:05,440
So it gives you a range of percentiles and measurements for those. So what that means,

306
00:31:05,440 --> 00:31:12,400
a percentile is, let's say, percentile 50 means you're halfway through your distribution.

307
00:31:12,400 --> 00:31:21,600
Everything is at least as fast as this and not slower. And the higher percentiles, for instance,

308
00:31:21,600 --> 00:31:28,400
P100, 100th percentile means this is the slowest result you got. And the first one, which is called

309
00:31:28,400 --> 00:31:34,080
P0, is the fastest result that you've got. So effectively, what this does, it gives you

310
00:31:34,080 --> 00:31:39,840
certain points along the curve of your distribution. And it really drives home

311
00:31:39,840 --> 00:31:46,800
the point that you shouldn't be thinking of your distribution as like a normal shape,

312
00:31:46,800 --> 00:31:54,400
you know, like normal distribution. But it's really, really different. Just forget that

313
00:31:54,400 --> 00:31:58,640
this is a normal distribution, because it won't be. And that's what I really liked. It's not

314
00:31:58,640 --> 00:32:03,440
something you just drop in and then get numbers out and you walk away with the numbers, because

315
00:32:03,440 --> 00:32:06,480
it gives you many numbers. And you really need to understand what you're trying to do.

316
00:32:06,480 --> 00:32:12,160
And especially what you're trying to measure, what your requirements are for your system,

317
00:32:12,160 --> 00:32:18,320
how fast it is actually supposed to be, and how fast is the slowest result supposed to be. And,

318
00:32:18,320 --> 00:32:24,880
you know, it's making you think about the thing you're actually trying to achieve.

319
00:32:24,880 --> 00:32:29,680
And I found that really interesting. And I had a couple of questions to Joachim

320
00:32:29,680 --> 00:32:35,600
ahead of time, because I wasn't sure what this actually means and how to interpret the results.

321
00:32:35,600 --> 00:32:40,960
And he was super helpful, gave me some pointers. And we'll add these to the show notes. There's an

322
00:32:40,960 --> 00:32:46,160
interesting talk about by Jill Tenney, I think is how you pronounce his name,

323
00:32:46,160 --> 00:32:52,000
about why normal distributions, these are normal distributions, why you should be looking at

324
00:32:52,000 --> 00:32:58,480
percentiles and what you should be looking for when you do run these kinds of tests. And yeah,

325
00:32:58,480 --> 00:33:04,080
I think this is really great. This is one of these packages where you start looking at the package

326
00:33:04,080 --> 00:33:09,600
because you think it's useful. And then you end up going down a rabbit hole and learning really

327
00:33:09,600 --> 00:33:15,680
a lot about a domain that you didn't know a lot about. And that really gives me, just looking at

328
00:33:15,680 --> 00:33:21,120
the package and the documentation of it and the breadth of it, you know, like these, all these

329
00:33:21,120 --> 00:33:27,600
different metrics and the care that has been taken to give you controls and knobs and, you know,

330
00:33:27,600 --> 00:33:32,000
allowing you to set these thresholds, make it configurable, gives you really high confidence

331
00:33:32,000 --> 00:33:40,640
that this is a really worthwhile thing to invest time in and use. And I know I've seen this pop up

332
00:33:40,640 --> 00:33:46,480
in a few places, this package. It's been being used in quite a few projects to measure benchmarks.

333
00:33:46,480 --> 00:33:54,560
So I think it's really fascinating. And give this a look if you want to benchmark stuff,

334
00:33:54,560 --> 00:34:00,080
I think this is the perfect place to start. - That's great. Are we going to use it with,

335
00:34:00,080 --> 00:34:04,560
because we have query performance tests in our code base, right?

336
00:34:04,560 --> 00:34:14,000
- Yes, we do. I might try that. There's some, another place where I want to use it first,

337
00:34:14,000 --> 00:34:21,200
but it's certainly something I'd be interested in doing more because right now we're doing really

338
00:34:21,200 --> 00:34:30,160
the bare minimum of just, effectively we're not as much benchmarking, we're sort of snapshotting,

339
00:34:30,160 --> 00:34:34,640
we're baselining, you know, we're trying to establish how fast is this if I run it once,

340
00:34:34,640 --> 00:34:41,840
and then we record that time and we effectively see if we get slower. So we're not really ensuring

341
00:34:41,840 --> 00:34:50,400
that we're hitting a certain speed, we're tracking how we're getting slower over time.

342
00:34:51,360 --> 00:34:57,760
The way I like to look at it is that it's more of an indicator than an actual test. It is,

343
00:34:57,760 --> 00:35:03,440
you should be aware that things have got slower. - Yeah. I think if I was asked what's this for,

344
00:35:03,440 --> 00:35:10,160
I'd say this is to see if we suddenly have a query that runs two times slower, because that we would

345
00:35:10,160 --> 00:35:16,480
see and that would be important. And this has actually happened. And that's what this is for

346
00:35:16,480 --> 00:35:22,560
really to not accidentally, because SQL queries are really easy to just tweak a little bit and

347
00:35:22,560 --> 00:35:27,920
then have huge performance regressions that you don't notice, especially you won't notice it if

348
00:35:27,920 --> 00:35:33,760
your dataset is small. And what we're actually doing is we run it against our staging database,

349
00:35:33,760 --> 00:35:42,000
which has a comparable dataset to production. So we would see if a query is really bad all

350
00:35:42,000 --> 00:35:47,280
of a sudden, we would see that by looking at the, we're not looking at the runtime,

351
00:35:47,280 --> 00:35:53,920
we're looking at the cost, which also isn't perfect because the cost is an estimate,

352
00:35:53,920 --> 00:36:00,400
it can be wrong, but it is a, in my testing, it has been a fairly decent indicator of what's

353
00:36:00,400 --> 00:36:07,280
actually going on. So this turned into a much longer packaged recommendation than usual.

354
00:36:07,280 --> 00:36:12,640
But we haven't finished yet. Cause I was going to say the only, the only slight downside to that is,

355
00:36:12,640 --> 00:36:21,520
is that because that CI step is not a mandatory CI step. What we quite often do is something will

356
00:36:21,520 --> 00:36:27,120
slip by just a few milliseconds and it will start the test failing. And it takes us a few weeks to

357
00:36:27,120 --> 00:36:32,160
maybe get around to updating those benchmark scores. And so if anything doubled the query

358
00:36:32,160 --> 00:36:37,920
performance in those few weeks, we'd never know. Well, actually we would, we'd never know until

359
00:36:37,920 --> 00:36:43,120
we came to update the benchmark scores. And at that point we'd realize, and there we go. But,

360
00:36:43,120 --> 00:36:50,560
but, but yeah, but I mean, who's perfect, right? Yeah. I mean, that's the thing. This is hard to,

361
00:36:50,560 --> 00:36:55,200
to automate because A, we want to, don't want to be running this all the time.

362
00:36:55,200 --> 00:37:00,880
Like auto updating, right? You need to review these new numbers, right? You need to put them

363
00:37:00,880 --> 00:37:07,200
in somewhere. We need to baseline somehow. And because Swift package manager doesn't have the

364
00:37:07,200 --> 00:37:14,000
same affordance to do these, what's it called in Xcode where you can, you can baseline tests,

365
00:37:14,000 --> 00:37:19,840
right? You can have performance tests in an Xcode and baseline them automatically because we can't

366
00:37:19,840 --> 00:37:25,840
use that due to the way we're running tests. We sort of have to do that bit manually. Otherwise

367
00:37:25,840 --> 00:37:30,320
that would be really great if we could do that and then just review the changes and approve them.

368
00:37:30,320 --> 00:37:34,720
That would be ideal. Right now we can't, I mean, the best thing we could probably do is,

369
00:37:34,720 --> 00:37:42,000
is write a, like the Pointfrico guys have done this auto snapshotting thing we could, but you

370
00:37:42,000 --> 00:37:45,920
know, I've already spent way too much time instrumenting this. I think I'm not gonna,

371
00:37:45,920 --> 00:37:50,320
I'm not gonna take it even further. This is, I do this once a week and that's, that's fine. So

372
00:37:50,320 --> 00:37:57,920
it's not too much work at the moment. So my next package recommendation is by

373
00:37:57,920 --> 00:38:05,360
Navin Chauhan. And this is something that I never expected to see in a Swift package. And I was,

374
00:38:05,360 --> 00:38:11,600
I was kind of delighted when I saw it. It's called Swift Gopher. And it is a, a less than

375
00:38:11,600 --> 00:38:20,560
one month old implementation of the Gophers, both server and client written in Swift. Now

376
00:38:20,560 --> 00:38:24,880
I'm pretty confident that there are people listening who will not remember Gopher.

377
00:38:26,400 --> 00:38:30,960
Do you remember it Sven? I do remember it. I saw it early on,

378
00:38:30,960 --> 00:38:36,000
but I actually never used it. I know it's one of these, not ethernet, internet protocols, you know,

379
00:38:36,000 --> 00:38:43,440
like FTP, HTTP, that sort of stuff. But I don't, what did Gopher actually do? It was, I don't

380
00:38:43,440 --> 00:38:49,120
remember. I also, so I did, I think I did use it like once or twice. I remember on the old

381
00:38:49,840 --> 00:38:56,640
Unix machines at university. I think there was still a couple of Gopher. I think Gopher was

382
00:38:56,640 --> 00:39:04,080
mainly over by the time I even got access to the internet. So when I was at university, which is a

383
00:39:04,080 --> 00:39:11,280
very long time ago, the internet was really only just becoming something that you could get access

384
00:39:11,280 --> 00:39:17,120
to even in academical institutions. Certainly there was no home internet access at the time.

385
00:39:18,400 --> 00:39:24,880
And Gopher was kind of dying at that point. So it was really early. But what it was,

386
00:39:24,880 --> 00:39:33,360
was it was a precursor to the web and you could Gopher into a server. And it was like a step

387
00:39:33,360 --> 00:39:39,520
up from Telnet. So Telnet, you basically got a remote console on the server. That's what Telnet

388
00:39:39,520 --> 00:39:47,520
basically did. And Gopher was a way that you could fetch information and then post information back

389
00:39:47,520 --> 00:39:56,960
to it in a text-based interface in the very early days of the web. But it's not dead apparently,

390
00:39:56,960 --> 00:40:05,120
because Navan has written both the client and the server and you can run a Swift Gopher server

391
00:40:05,120 --> 00:40:10,320
and you can connect to it with the Swift Gopher client and you can fetch information from your

392
00:40:10,320 --> 00:40:19,280
Gopher server. It's a bit like these very early BBSs. I have no idea how that actually used to

393
00:40:19,280 --> 00:40:26,960
work. So I do remember those. So that was really one of my first experiences with the internet,

394
00:40:26,960 --> 00:40:38,720
which was the Telnet BBS systems. The only one that I remember by name was a Telnet BBS called

395
00:40:38,720 --> 00:40:48,720
Skynet, which is a very original name for a BBS. And you would connect effectively using,

396
00:40:48,720 --> 00:40:54,960
you'd effectively get a kind of shell into the server and it would be this BBS system that you

397
00:40:54,960 --> 00:40:59,280
could leave messages for people, you could read messages, you could send messages, you could post

398
00:40:59,280 --> 00:41:04,320
on public forums, I think, but they were very, you know, it was a very different to anything you'd

399
00:41:04,320 --> 00:41:13,280
see today, but it was all through a kind of text, a terminal style window. And I remember the speeds

400
00:41:13,280 --> 00:41:19,840
that we were able to have at the time, you could see the terminal screens drawing character by

401
00:41:19,840 --> 00:41:26,880
character. So it was, it was early, early days of the internet. Well, Gopher, I didn't have that in

402
00:41:26,880 --> 00:41:33,040
the cards as a package. I was pretty confident that that would be all mine. Yeah. Well, this

403
00:41:33,040 --> 00:41:38,080
is one of my traditional recommendations, which is not a recommendation. Oh, is that what it is?

404
00:41:38,080 --> 00:41:45,360
Although I do think we should, we should maybe consider supporting Gopher for the package index.

405
00:41:45,360 --> 00:41:50,880
So we don't neglect those people who still want to use a Gopher client to fetch package information.

406
00:41:50,880 --> 00:42:00,000
You can fetch your package of the day. Exactly. My second pick is called WebSocket Actor System,

407
00:42:00,000 --> 00:42:06,080
and it's by Stuart A. Malone. And that's, I loved seeing this. So I've been following

408
00:42:06,080 --> 00:42:12,000
Apple's distributed actors package with interest for quite a while now. But in the past, I've,

409
00:42:12,000 --> 00:42:16,960
I've really struggled. I've tried a few times, but I've struggled with creating a proper example

410
00:42:16,960 --> 00:42:23,680
that would work across nodes. So the repository comes with, with an example, tic-tac-toe the Apple,

411
00:42:23,680 --> 00:42:29,040
Apple's distributed actors package, and I've played around with it, but I've never really

412
00:42:29,040 --> 00:42:36,160
gotten it to work properly in a, in a local setup. And, and Stuart has really done all the hard work

413
00:42:36,160 --> 00:42:42,640
here and created a package and then also shipped an example and explained how to use it. We can

414
00:42:42,640 --> 00:42:49,600
set up a distributed actor system based on WebSockets here to communicate between nodes,

415
00:42:49,600 --> 00:42:57,120
where nodes really is just another distributed actor instantiation. So it's really fascinating

416
00:42:57,120 --> 00:43:01,520
because from a dev point of view, you're effectively just calling into an actor and

417
00:43:01,520 --> 00:43:08,880
you don't even realize or know whether it's local or in another process or on another machine

418
00:43:08,880 --> 00:43:14,800
across the network. And that's the beauty of this, of these distributed actors. It abstracts away

419
00:43:14,800 --> 00:43:20,640
all of this and, and all of this message passing and, and encoding decoding is, is handled by the

420
00:43:20,640 --> 00:43:27,920
library which is really nice. And Stuart has chosen WebSockets here as a transport and I think

421
00:43:27,920 --> 00:43:33,600
JSON under the hood as a, as a exchange format, but you actually see none of that. So you really

422
00:43:33,600 --> 00:43:40,880
just have actors and you, you know, you, you connect and then call functions with try await,

423
00:43:40,880 --> 00:43:46,240
you know, like normal async functions on the actor that you've just resolved across the network

424
00:43:46,240 --> 00:43:53,520
potentially. Now I haven't tested, I've actually used this in a little example to see how it works,

425
00:43:53,520 --> 00:43:59,040
but I haven't tested what this means in terms of efficiency, resilience, error handling,

426
00:43:59,040 --> 00:44:04,400
that sort of stuff. It does claim to automatically reconnect after failure. So it has some

427
00:44:04,400 --> 00:44:10,480
affordance for this. And the other thing that's really nice about this, as opposed to a normal,

428
00:44:10,480 --> 00:44:18,720
traditional HTTP rest API, for instance, is that you can call methods, actor methods on

429
00:44:18,720 --> 00:44:23,920
the service you connect to, but the other service, you know, can also do this. So it's actually

430
00:44:23,920 --> 00:44:29,520
really nice if you want to have a server that calls back to you as a client, you know, imagine

431
00:44:29,520 --> 00:44:34,320
it's like a push mechanism, right? Whereas normally you talk to an API, you'd have to

432
00:44:34,320 --> 00:44:38,560
pull the API to understand if something's there for you, you know, if something has something to

433
00:44:38,560 --> 00:44:43,760
respond. But in this case, these two nodes are really peers. So if there's something happening

434
00:44:43,760 --> 00:44:49,440
on the server, it can actually call into the client and say, look, this just happened, you

435
00:44:49,440 --> 00:44:56,560
know, handle it. So that's really nice. And that might open up use cases that are quite powerful.

436
00:44:56,560 --> 00:45:03,680
So, yeah, I really wanted to highlight it because I'm really interested in the distributed actors,

437
00:45:03,680 --> 00:45:09,120
and I haven't seen a lot of packages actually using it, or even like proper applications using

438
00:45:09,120 --> 00:45:17,840
it. And maybe this package WebSocket actor system can be a building block for someone who's doing

439
00:45:17,840 --> 00:45:22,080
something with it. I have sort of a couple of ideas how we might actually be using it

440
00:45:22,080 --> 00:45:28,480
in the future. That's why I'm super interested in this whole domain. And I've really loved seeing

441
00:45:28,480 --> 00:45:35,040
this package come around. Are you ready to share those ideas? Well, I mean, it's no secret we're

442
00:45:35,040 --> 00:45:38,560
running a build system, right? And right now our build system is... I figured that would be it, yeah.

443
00:45:38,560 --> 00:45:45,840
Yeah, I mean, this because we have components that talk to each other.

444
00:45:45,840 --> 00:45:57,920
And we're currently using GitLab as our queuing system. And if we ever have need to change that,

445
00:45:57,920 --> 00:46:06,800
I'm sort of toying with the idea that rather than building some sort of HTTP-based system,

446
00:46:06,800 --> 00:46:11,680
maybe this would be a good use for actors where the actors are the builders and they report back,

447
00:46:11,680 --> 00:46:16,720
that sort of thing. I have to talk to people who know more about these kinds of systems if

448
00:46:16,720 --> 00:46:22,560
that's actually a good idea, but it strikes me as something that might work really well for us here.

449
00:46:23,520 --> 00:46:30,640
I don't know. I think these things make me overly nervous because they feel... There's no judgment

450
00:46:30,640 --> 00:46:36,480
here on the actual reliability of this because I'm completely uninformed on the actual reliability.

451
00:46:36,480 --> 00:46:45,760
But my perceived reliability is... I'm suspicious. Yeah, I mean, this is why I said I haven't tested

452
00:46:45,760 --> 00:46:49,840
this in terms of efficiency, resilience, and reliability. I think that's really

453
00:46:52,000 --> 00:47:02,640
a key thing to understand. But it's also true that distributed actors is based on tried

454
00:47:02,640 --> 00:47:11,280
technology. So there are actor systems out there already. And Conrad, his last name escapes me

455
00:47:11,280 --> 00:47:15,600
right now, at Apple, who's working on these systems, he has lots of experience with this.

456
00:47:15,600 --> 00:47:25,120
And this is Apple's adaptation of actors. And this is not entirely novel, is what I'm trying to say.

457
00:47:25,120 --> 00:47:32,160
Like, this is not completely uncharted territory. This is Swift's take on a system that exists. I

458
00:47:32,160 --> 00:47:41,920
think Erlang has this in a certain sense. There is certainly a Swift spin to it. But I think we're

459
00:47:41,920 --> 00:47:48,000
not, you know, like complete greenfield here. I think there's lots of reasons to approach this

460
00:47:48,000 --> 00:47:54,480
with interest and see how it actually works and understand, especially if this is a good fit,

461
00:47:54,480 --> 00:48:01,920
right? Because I think it's also important to stress that distributed actors aren't intended

462
00:48:01,920 --> 00:48:08,480
to replace every distributed system, right? There are reasons why HTTP is really good. Because I

463
00:48:08,480 --> 00:48:13,840
think if one reason I can think of where you probably wouldn't want to replace it, if you

464
00:48:13,840 --> 00:48:18,640
need caching, that sort of thing like this or proxying, you know, like HTTP as a protocol

465
00:48:18,640 --> 00:48:22,080
allows you to do lots of things where your services don't even know that they're happening,

466
00:48:22,080 --> 00:48:28,480
because it's just a plain standard protocol. You couldn't, I think, insert anything like that into

467
00:48:28,480 --> 00:48:34,240
a distributed actor system and expect it to still work, right? They really rely on talking to the

468
00:48:34,240 --> 00:48:40,800
other end of the system that is as the same part of the system. There's no expectation of this

469
00:48:40,800 --> 00:48:48,320
being proxied or load balanced or anything like that, is my understanding. Again, I might need to

470
00:48:48,320 --> 00:48:53,040
talk to people who understand this way better than I do, to really get a feel for this.

471
00:48:53,040 --> 00:48:57,920
We just continue with our reputation as the best research podcast in the world.

472
00:49:01,040 --> 00:49:07,520
And with that, I think we should probably wrap it up for this episode. We will be back in a

473
00:49:07,520 --> 00:49:12,880
couple of weeks with some more news and some more package recommendations. But until then,

474
00:49:12,880 --> 00:49:17,920
we will say goodbye for now. Yep. Goodbye. See you in two weeks. All right. Bye-bye.