Swift Package Indexing

I could start us by asking how many times the Package Index has crashed this week.

Oh, it's never crashed though. That's the problem.

Well, this is your answer. This is the show.

Well, here we are. It didn't actually crash. It did not crash. The problem was it should

have crashed. That would have been actually easier. The problem is it hung.

So yeah, we've been having an extremely long-standing problem with the Package Index that

Sven has been incredibly diligent in constantly restarting the servers every time they go down.

But as you say, it's a hang, not a crash.

Yes, and that wasn't even clear. So initially, I thought it was perhaps related to a crash,

because there were some stack traces, well, not stack traces, but dumps, segfaults, or signal

11s in the logs. And it was really unclear what the cause for the hang was. So the only symptom

we had, like the service wasn't working anymore, and this wasn't the website, this was one of our

batch jobs. So it's not terrible for the site. It just means that our updates sort of start

lagging because one part isn't running anymore. And it wasn't really, so the only symptom was in

the logs, there was just a final message, you know, this is sort of, that's the last thing the

thing did, and then nothing else. And it was unclear what's going on. There was CPU being

used, so something was churning, but nothing happening. And this started happening when we

converted over from Event Loop Futures to async/await. So I think we started this almost two years

ago, I think in winter 21, 22, is when we first started this, right? That's when async/await came

out in 5.7, right? 5.6? I think it was 5.6. Might have been 5.6. Yeah, it's two versions per year.

I may be wrong there. Yeah. And initially it was fairly infrequent. And I think,

if, you know, in hindsight, I think it happened more and more frequently because we

converted more and more stuff to async/await. But that's really a guess because we don't

really know yet. We just have a fix now, finally. And like huge thanks in particular to Gwynn Raskind

here because she was really, really helpful in tracking this down. And effectively, essentially,

the fix was to remove one of our task groups, async/await task groups that we'll be using to

kick off our processing. Part of the processing we were doing there was running shell jobs that

do Git operations. And very early on, she suspected that's the problem, but we sort of,

we always wanted to actually find out what the problem was. So we delayed making that change

also because we were sort of hesitant to make it because, you know, when you, because the fix was

actually take out that task group and make those batches not run concurrently anymore. So there was

a bit of a concern that we lose performance. You know, we were running things in parallel.

That gave us some advantage because often things were waiting on network while others were running

Git jobs and doing database updates. So there was sort of a good use for concurrency because

different parts of the system are used separately. And you know, do you want to use, utilize all of

it as much as you can and making that just single threaded was sort of a concern. But in the end,

we probably lost way more time when this job was down and waiting for me to notice or, you know,

respond to the alerts that we had and restarted. And, you know, it's one of those things also,

it didn't happen immediately. So any change we made, we sort of thought, well, is that it? And

then we waited for hours, sometimes days, because you could never know, you know, typically what

happened a couple of times a week. In the end, it happened multiple times a day. That was actually

an improvement in the sense that we had a faster turnaround in trying to debug it.

Because initially, any change we'd made would effectively, you know, let's meet again next

week and see how we did. These bugs that don't occur regularly are a real pain because you do,

you just you try something, you don't really know whether it's going to work or not. And then

you have to wait 24 to 48 hours for it to get the news. And for the first, you know, for the first

12 hours, you might be filled with hope. Yeah, exactly. You think, all right, we've done a couple

of times where it takes us a little bit. It's looking good. It's looking good. And then on now.

But it really was it towards the end, it was happening multiple times a day, which, which is

not a great situation, because it did, like you say, it didn't affect the uptime of the website,

but it did affect our processing of new package versions and that kind of stuff. So it was,

it was, it was not critical in that people could still, people could still access the website. But

it was, it was an important bug. And it's just been, I mean, it must be, well, it's like you say,

it's since the introduction of async/await, which is a couple of years, isn't it? So yeah,

yeah, it's been, it's been really long. And again, I mean, if this had been like this multiple times

a day, I mean, we'd probably fix it sooner or found out ways to address it sooner. The fact

that it was just initially a couple of times a month is something you just effectively ignore,

right? If a service hangs twice a month, you just restart it, right? It's not great,

but it's also not terrible. You know, especially in hindsight, how much time we sunk into fixing

this up. If I had to make that choice again, twice a month or trying to figure this out,

I mean, twice a month, I'll take that. That was easier.

That's the blessing of async/await being adoptable slowly in that we could, you know,

we did start to introduce it and replace it, first of all, in new code, and then started to replace

bits as we touched a bit of code, you might convert it from event loops to async/await.

But of course, the more we did that, the more it seemed to get, this problem got worse, right?

Yes. Yeah. And I wouldn't change, I wouldn't make that trade either. I mean,

I'm happy we made that change to async/await. It just makes maintaining the code much nicer.

We should be very clear here and say that we're not saying that task groups are bad.

I think this is, I know we haven't logged a bug for this yet, because I think getting a reproducible

case for this is going to be, I don't know, tricky.

Yes. So I was going to get to that. We haven't reported that really, because it's effectively

I wouldn't even know how to report that. You know, a task group on Linux in certain situations

can cause hangs. I mean, if I got that bug report, I say, well, tell me more. And then I say, well,

I can't really. So one of the things we tried to debug this was when the process hangs to send it

a kill signal to get the stack trace. But the problem is with 5.9.0 right now, on Linux, you

don't get symbolicated stack traces. There's a change that fixes that. That's going to go live

with 5.9.1, I believe. And once that is live, I guess what we'll do is revert back to the task

group, at least on dev, because it happened on both environments, and then just run it and see

if we can get a stack trace out of it then to get more info on, you know, have at least something

better to report than this nebulous. Yes. Hangs sometimes sort of report because no one can do

anything with that, really. Because Gwyn is super experienced with this sort of stuff and

was actually trying to read the stack trace that we got, the raw one, and sort of had some ideas.

But I think we need more information for anyone else to be able to do more here.

So even though it's fixed, it's not over.

It's not over, no. But well, at least in terms of operationally, it's over. That's great. The

performance hit wasn't actually as bad as I thought it'd be. I think it's 50 or 60%, something

like that, which is okay. We have a little headroom there. We're not running the process

back to back all the time. We have a little pause there because analysis is running fast enough for

our purposes. So if we were uncomfortable with sort of this running a bit slow, we could reduce

the delay and have the same throughput effectively. So that's not terrible either.

Yeah, so I think we're all right there overall. It's also worth probably mentioning that the only

thing this would delay is how quickly packages update after a new version is published. So

we're currently running at like a couple of hours, something like that. So if,

depending on how far through the cycle we are, you might get lucky and it might update

almost immediately if your package was next in the update queue. But in worst case scenario,

you're looking at a couple of hours of delay from pushing a new release to GitHub and

the package page updating. So even if that doubled, I wouldn't be fretting too much.

I would love it if every package immediately updated. Of course I would, that would be the

best situation. But this is not something that really is going to affect most people. And this

is only versions. The packages are all still there. So people searching for packages,

using the package index, it's relatively minor in the grand scheme of things.

Yes. And we do prioritize new packages for immediate analysis. So if you add a package,

it'll be going to the front of the queue. So this only affects if you have releases

and effectively means that going through all packages once now takes probably around six

hours. I haven't actually measured it. It used to take four. We also have more packages these days.

Oh my, my numbers are out of date then.

Yeah. I haven't actually checked, but early on we had 3,000, I think it's 6,000 now. So

we have double the packages and 50% slower processing. I would bet we've gone from

three to four to maybe six hours or something like that, but it shouldn't be a huge problem.

Sure. Yeah. Well, I'm glad it's fixed.

Oh yeah, so am I. And pretty much in parallel to this, there was another problem that we

started having recently, which interestingly was also a hang, but unrelated to this one,

that was affecting our build system. Also there, it's unclear why that happened.

It only affected Xcode builds like with the Xcode build command builds. So on Apple platforms,

we have two ways of running builds. One is Swift PM and the other one is Xcode build,

especially for the iOS, tvOS, watchOS, visionOS platforms.

And I'm not sure if it was all packages, but many packages, when they had a build failure,

they would hang. And to the best of our understanding, this is a OS update potentially

that caused that because we had no related build changes that would cause that to happen.

And yeah, that's also something we fixed, sort of inherited another fix that helped out in this

case as well. So it was a big week or two weeks since we last recorded.

Yeah. And this was actually causing us capacity issues with the build system because the builds

that were hanging were then holding up other builds in the queue. And we got into a situation

where our build system was unable to keep up with the influx of new releases and versions,

which is the first time that's happened really. And of course, with our current hardware, that

was going to happen at some point because the number of packages and the number of releases

keeps increasing. But yes, it was a little bit of a panic stations where when the queue of pending

builds was only going up and not really coming down very much. And I should mention that Max

Stadium helped us out with, before we figured out the bug, just to help us keep that backlog under

control. They very, very kindly, temporarily gave us an extra machine so that we could keep on top

of the backlog. Yeah, that was great. That helped so much because if you sort of have to fix

something and at the same time, keep an eye on a queue that's filling up, it's just not great.

So having that sort of relief, at least it's working again, because also now the build system

is doing the documentation building. So it's kind of getting additional responsibility. And also

people are relying on that more if we look at our stats and documentation page views,

that's going up. So people are relying on the docs more and more and having issues in the

build system that also affect the documentation generation just isn't great. So I'm really glad

that those two issues are fixed and sort of freeze us up again. And again, just to be super,

super clear, none of this affects the hosting of that documentation. It's all only about how

quickly that documentation and the package pages get updated after a new release. Yeah, exactly.

So yeah, a couple of weeks of bugs. Yeah. Talking of the build system, I noticed a package get added

to the index this week, which I think we've talked about Windows compatibility before, but the

package is Swift WinRT by Salim Abdul Rasool. And this is a package that allows you to hook into the

Windows runtime APIs on Windows, of course, from Swift. And the reason that I bring this up with

the build system is this is obviously a very interesting package. It enables native Windows

development with Swift, which is quite a thing. That is a major step forward in terms of cross

platform Swift. And that is not to say that it's allowing Apple technologies like Swift UI and UI

kit to run on Windows. That's not what this is. This is if you want to build a native Windows

application with Swift, this package will help you do that. But the downside is if you look at

the compatibility matrix for that package, it is full of gray crosses, which means that there's

nothing compatible. And the reason for that is that we don't have Windows compatibility testing

yet. And the more that happens on Windows, the more urgent this problem of do we tackle

compatibility testing for Windows, the more important that becomes.

Koen Smeets Yeah, it's I mean, it's going to happen at

some point, right? I'm just peeking through the gap between my two screens here and I see my old

Intel MacBook. And I think it's going to see a new life as perhaps a Windows test machine.

Jason Vale Well, we could run the test machines.

Koen Smeets No, just to try it, right? I've never run

or done anything with Swift on Windows. I mean, it's just Mac OS and Linux.

Jason Vale Neither have I.

Koen Smeets I don't have a whole lot of

Windows experience either. I stopped using Windows in 1991 in earnest. So I shy away a bit from it,

to be honest, even installing it and getting into it. I know we're going to have to at some point,

but it's so out of my comfort zone that I'm currently trying to find other things to do.

Jason Vale Yeah, I mean, we could run the

servers, no problem. The rest of our infrastructure, the build machines that do not run on

Mac Stadium, they run on Microsoft Azure. So if there's one place you can run Windows machines

reliably, it's Azure. So that's not a problem. The issue is building that, you know, taking

advantage of Windows or not even taking advantage, just getting it working with Windows is going to

be the issue. But we have to tackle it. We have to.

Koen Smeets Yeah, yeah. Yeah, it's going to be

interesting. Also integrating it into our build system, which is even between Mac and Linux,

there are huge differences in how we operate those and Windows will have yet another way,

potentially, of how to do that, I suppose. I mean, it kind of depends on how that works. I guess,

you know, it's only SwiftPM build. So I guess, and probably not Dockerize. Well, I'm pretty sure

it's not Dockerize. So it'll probably mirror how we do the macOS builds. But it's going to take

some figuring out how to do that, how to run the machinery, we need to schedule the builds and all

that stuff on Windows and all that. So it's, it's, yeah, it's going to take some typing.

Jason Vale It's also, and this is, this is clearly

the biggest issue of all, is it's also going to need a redesign of that compatibility matrix,

because we're absolutely squished right to the very edge of what fits on that matrix right now.

So clearly, that's the biggest issue of them all, the design of it.

Richard Pinchot We should probably start there. And I'll wait.

Jason Vale

Yes, but it certainly, it would be lovely to see a green tick there.

Richard Pinchot Definitely. Yeah, definitely.

In terms of that wasn't a real package pick now, was it? That was that was still?

Jason Vale It wasn't. That was just,

that was just talking about packages. Yeah, exactly. Yeah.

Richard Pinchot I have, I'm sort of in a similar situation,

because I have a package pick that came out of a, a, another thing that I saw on Mastodon. And that

is perhaps something we could briefly talk about. And it's a dev tool, breadcrumbs by

Marin Todorov. He, he's doing these great little experiments with dev tools. I mean,

he's also released some dev tools in the past, but currently, he's sort of using SwiftUI to

prototype stuff. And it's really great to follow along what he's doing. And that kind of made me

think, Dave, when's the last time you came across a new Mac OS dev tool that really embraced the

platform? Can you can you recall something really new?

Dave Bates Yeah, I, you asked me this question before,

there's a bit of a bit of background to this, you asked me this question before the, the show, and

the only one I could come up with was Reveal, which is definitely not new, but it has just had

a new release. Yeah. And that is, you know, for all intents and purposes, as far as we know,

a successful developer tool. It shouldn't be a difficult market, because the people who Marin

already knows should be his target audience for these tools. And there should be an audience,

a ready made market for developers to make developer tools that that make viable or,

you know, doesn't have to be a complete viable business, but you know, certainly

support the development of the tool. And I don't really know why that's not possible,

but I agree, it's not really happening. The the other one that I, that springs to mind is

Kaleidoscope, which is, again, not new, but has recently changed hands again, and is receiving

significant kind of development updates regularly, you know, almost every, every few weeks, they put

out a new version with some new feature, which, honestly, it's a fantastic tool. It's really,

it's a really great diff tool, if you if you haven't checked it out. And, and that the,

the pricing of that is certainly, you know, subscription pricing. So it should be sustainable,

it should be enough to build a business on the back of, but it is a tough market to get into

at the moment. And that's a perfect example, because I have that in my notes, Kaleidoscope,

I use it effectively every day. I am on Kaleidoscope three, because I've looked at the

feature list of four, the one that changed to subscription pricing. And I sort of struggled

to see the value proposition a bit in my particular case, I don't even know, I don't

remember what the differences were. But when I looked at it, I thought, yeah, I think, you know,

what would make me switch is, you know, if an OS update sort of made three not work anymore,

and understand that is actually a feature that that you need to pay for, you know, maintenance

of a tool that, you know, changes across OS versions. And I'm happy to do that at some

point. It's just that right now, I didn't make a switch yet. And I think a lot of that is because

our expectations around pricing have changed so much with the effectively the pricing

development on the App Store, right? We've sort of been trained to expect lower and lower prices.

If I told my past self, you know, like, 10, 20 years ago, there's a dev tool that costs 100 euros

per year. Yeah, that's, that's normal business. And but it's not anymore. It's like,

it really stands out as a as a price. And it shouldn't but we and it's really hard, even if

if you are thinking about this, you are affected by these low prices, because that's what you

compare it to. And it's really bizarre. And at the same time, you know, we lament this decline

in tools. I can't last thing I could think of that I bought was Nova,

which also isn't new, right? They're on version for something, I believe, but I only just started

using it recently. It's we lament the absence of these tools. At the same time, we are all

sort of affected by the low prices and sort of don't then chip in when there are tools that are

certainly worth it. It's, it's, it's a really bizarre situation. And clearly, I mean, I think

if, if the market was better, some of these experiments, you know, that Marin is, is making

would probably turn into proper products. But I mean, I don't know. But I think the main reason

he isn't wrapping them up and publishing them because and I know he tried it with a couple

of things in the past is that they don't tend to be sustainable in the end. I mean, I know from my

little app that I have, which isn't effectively a dev tool, but a window management tool that is,

that's nowhere near something that would sustain any sort of indie career. It's

just doesn't happen. And I have a dev tool as well on the App Store, an Xcode plugin. It's nothing,

there's just nothing happening. And I don't do any marketing. So there's no surprise, but it's

also not, this isn't happening on its own. So there's clearly something off.

Toby I think this also comes into the whole

subscription pricing thing. Like you just said it then, that if somebody said to you,

this tool that you use and rely on is going to be a hundred pounds per year. And you say, well,

that's a decision I can make yes or no on that. And the old way of doing it would be that you

pay the money and then a year later or something like that, you pay some more money for an upgrade

to the latest version of it or whatever like that. That worked for many, many years. And there's

actually very little difference between that model and the subscription model apart from that you

lose access to the running piece of software that you currently have with the subscription model.

And in reality, that I don't think is a huge issue, but mentally that is an enormous blocker

because you feel like, well, I'm paying for this thing and therefore, and I'm not saying this is

the correct, you know, there's no such thing as a correct opinion here, but there is something

fundamental in us that says, well, I'm paying for this thing, therefore I should own this thing.

And that switch to subscriptions is in reality is a very trivial switch for the actual amounts

of money that change hands. But that there's something in our brains that doesn't like that

switch.

Yes. And there's actually, I mean, if I just think about it, there's a great argument for

subscription pricing is I don't really love it when software sort of comes up with point releases

to charge money and features that really don't do anything right. There's that happening as well as

just feature creep for the purpose of being able to charge someone. I'd actually rather pay for

just plain maintenance and picking features that make sense rather than give it all sorts of bells

and whistles that have no business of being there other than, all right, I need to charge you

something. So I need to ship something. And that's also a weird business model, right?

But we are, it's this subscription fatigue is real. If you have this feeling, right,

I've signed up for this and then everything hits me. I often sign up for stuff and then

immediately cancel it. So I don't, I hate it when stuff renews and I forgot about it. So, yeah.

Yes. I do the same. I also set reminders in my calendar to say, cancel this a year. Let's say

I pay for a year or something and I put a reminder in saying like, it's not necessarily cancel it,

but just like make that decision. Did this pan out or not? So my calendar, my reminders folder

is full of those. Before we move on from this topic, I should just mention for disclosure,

I do, I did receive a copy of Kaleidoscope for free. I reviewed it for iOS Dev Weekly. So

just to disclose that that is the case that I did receive a free copy of that.

Cool. Is it package time then?

I think it is. We've, I think we were chatting before the show saying we've not got much to

talk about and here we are 32 minutes in already. So let's, let's maybe keep it a short set of

packages this week.

Let's do that. Do you want to kick us off?

Sure thing. I will kick us off with a package called Grape by Zhen Li. I actually linked to this

in iOS Dev Weekly a couple of weeks ago. This is a visualization packages for connected nodes

of information. You might have seen this quite often runs in JavaScript. In fact, I,

I forget the name of it now, but there was a, a Swift, an application written in Swift that

inspected Swift dependencies and displayed them in this format of, of, of charts. And it's kind

of like an animated node graph where there are a whole load of dots on the canvas and then each

dot is connected. So one dependency would be connected to another dependency or whatever it

is that you're modeling. And then they have, they all have kind of a little bit of physics

applied to them. So as they settle, they, the dots kind of push each other apart a little bit,

and then you can normally, you can, you can interact with them, pull them apart,

inspect them, click in, maybe navigate through to you know, through a hierarchy of dependencies

or something like that. Anyway, that's, I'm sure if you, if you have a look at the,

the readme file, you'll recognize immediately this style of visualization.

But as I say, everything I've seen so far has been doing this in JavaScript. And in fact,

even the Swift application that I mentioned before, that, that, that booted up, as far as I

know, it booted up a web view and then visualized it within the web view. This is a Swift native

implementation of that. And it looks great. This is the kind of thing that if you need this kind

of display, then you should absolutely check this package out. Great. That sounds great.

Um, right. My first pick this week is called Firefly. And this is the package I alluded to

earlier. It's a dependency that Marin Todorov is using in his little prototype Breadcrumbs.

And so just to explain what Breadcrumbs actually does, Breadcrumbs is a little experiment,

a Mac app that looks for to do and fix, fix it or fix me markers rather in, in Xcode projects.

So you have a little viewer of those, um, and, uh, it shows the marker and some context around

it. And you can click on that and it brings up the file in Xcode. Uh, so you can, you know,

sort of traverse your project for to do's and fix it, get a view of you could effectively use them

as, as little to do items, sprinkle throughout the code without actually needing to set up

anything other than putting those markers in which you probably have anyway. Um, and that's a nice

little tool. And in his main view where he's showing this, the context around the to do like

Swift code, um, that syntax highlighted and Firefly is the syntax highlighter that Marin is using

in his project. Um, and this is nice. I think we've mentioned syntax highlighting packages

in the past, and they've all been based on, I believe, JavaScript libraries that was embedded

in, in, um, uh, what's the, what's the framework. Do you know, uh, is it JS core is the framework,

right? That's being used to absorb those. Um, but this is a pure Swift package, so there's

no fiddling with JavaScript wrappers or anything. Um, you know, that usual packaging of it, it's a

pure Swift package and you can just run the code through it and you get a view and you can display

the, um, highlighted, uh, syntax highlighted text. So that's, um, oh, I didn't actually say

the author that's Taylor Lineman is the author Firefly by Taylor Lineman.

Jason Vale – That sounds great. Yeah. And just to also talk about that, um, uh, the app that,

uh, Marin was using it. And I think that's, it's a great idea for an application. I'm not sure it

supports subscription pricing, but it's a great idea. And I know that we have a whole load of

to-dos in our, um, in our code base that it would surface.

Daniel Zeiss Well, it's the app is open source

right now. So, um, you can subscribe by, um, I'm not sure if Marvin has a sponsor button on his

GitHub, but, uh, if you are so inclined and he does, that's the way to do that.

Jason Vale – If he doesn't, he should have.

Daniel Zeiss Yeah, he definitely should. He definitely,

he might. If he does, we'll add a link to the show notes and, uh, then you can head over and support

him.

Jason Vale – I haven't yet tried his app, but I did see, um, I think I saw it actually in a Slack.

Um, he posted a screenshot of it somewhere as well.

Yeah.

My next package is pretty niche. Um, it's by Leon Hoppe and, uh, it's called Swift ISO 8601

duration parser. So for many years, um, before foundation added an 8601 date parser, uh, there

was a very popular package for parsing these 8601 dates, um, because it's a common format, um, in,

in many web APIs. In fact, I would say it is the default date format in most, um, uh, web APIs.

Um, but then Apple added to foundation and ISO 8601, uh, uh, compatible formatter and

all our problems were solved. Um, until this week, I didn't realize that there was a new type or not,

it's not new at all, but, uh, a different type of ISO 8601, um, uh, date related formatting.

And that is you can format durations in 8601 as well. So you could say, for example,

uh, PT 12H is 12 hours. Uh, P3D is three days, uh, P3D T12H is three days, 12 hours. And this is

actually quite a useful format. I didn't even know this existed until I spotted this package, uh,

the last week. Um, and, uh, Leon has put together a parser for, in fact, Leon put together a parser

for it five years ago. It's been in development for a long time. Uh, I just hadn't spotted it

until now. Nice. Interesting. I did not know that was actually specified out. I mean, we've

sort of kind of, you'd kind of think like 3D, 3W and stuff like that is sort of the common way,

but you're saying, right, there's a P prefix to these that makes it sort of more, a more stable

format. Did I get that right in your description? Pretty much. Yeah. Yeah. Although also it's,

it's more than that because it's, uh, because the, the, the three days, 12 hours one is P3D,

which is the P whatever that means and the 3D, but then there's a T12 hours. So it's,

there's more to the format than just a number of the letter P and then three, 3D 12H. Um,

I'm not, I'm not sure that there is a link to Wikipedia. I haven't clicked it.

P is the duration designate of period. Okay. Place at the start of the duration representation

T is the time designator that precedes the time components in a representation. Okay.

Interesting. Nice. Thank you. Thank you. Wikipedia.

There's another subscription. I, I, I, I subscribe to Wikipedia every year.

My second pick is a package called auto merge dash Swift by Joe Heck. Um, I actually thought

we talked about this in the past that we might've mentioned it, but I didn't find it in our,

our previous show notes. Um, so if we have, the reason I'm bringing it up again is that Joe has

published a blog post announcing the latest release of the package and what's new, I think,

apart from it being, I think more sort of on the road to feature complete is that he's added a,

an example app that actually uses the library, um, a little app to manage meeting notes. Um,

and the package is a, a library for CR DTs, which are conflict free replicated data types.

So this is a, a tool for building or library for building collaborative systems where you can have

data types that you can distribute, you know, people can edit them independently and then they

can be merged. And there's, so the way that it's promised to be conflict free. So you won't,

you won't run into merge conflicts, um, due to the magic of this library. I'm not sure if it's,

if it's ruled out categorically by ways of how the algorithm works. Um, I think it is,

I'm not a hundred percent sure. I've read quite a bit about them, but it's, it's a big field.

There's lots of different ways of implementing them. Auto merge is one way of implementing them.

And what's interesting here is there is actually an underlying library, Rust library that powers

this, and this is a swift adaptation of it, or I think a wrapper around it. So it's a API layer

that uses the Rust library. I believe I need to, I didn't actually delve into it that deeply.

And the interesting part is that, um, because it's a Rust library and then also available for

other platforms, it gives you a better chance of developing a system where Apple platforms or

Swift platforms are just one part of what's using that as an exchange format. The Rust library would

work on other platforms as well. And you could then exchange, you know, the files and, and work

with it across platforms, I guess, more easily than that would normally be the case. So really

nice. And I really liked that there's an example app where you can play around with it and see how

it works. Uh, and that's auto merge by Joe Heck. I, I have Joe's blog post on this library in my,

uh, reading list for this week. So thanks for the, uh, thanks for the recap of that. I,

I will still read it, but you saved me, you saved me half the job.

There we go. Joe coming up for this Friday, I guess.

But no, I know, I know that this has been a topic that has been on Joe's mind for a long time now.

And so, uh, yeah, it's, it's great to see. And again, I, I am not, um, an expert on the

intricacies of, uh, CRDTs. I kind of don't even know the acronym. I think it's CRDTs, right?

Or is it CDRTs? That's how, that's how little CRDTs, that's how little of an expert I am on them.

Um, but I also believe that they, that they are potentially immune to those two conflicts. I mean,

that's the whole point, right? Yeah. Yeah. What I really want to happen, um, is that someone takes

the previous pick Firefly and this auto merge library and builds a Markdown collaborative

editor. And, um, I'm looking at you there, Marin, you're, you're apparently experimenting

with prototypes right now. Just Joe might help as well. You all go off.

Sub-ether edit. Do you remember sub-ether edit? Oh, yes. Yeah. Yeah. Yeah.

So sub-ether edit was part of the reason that I bought a Mac.

Yeah. Many people did. I was at a conference in, yeah, yeah, absolutely. I was, I remember

vividly, I was at a conference in San Diego. Um, it was, um, O'Reilly's e-tech conference and,

uh, this emerging technologies conference. And, um, I walked into the conference hall on

the first night. It was, it was a strange layout to the conference and a strange schedule to the

conference that the, the keynotes were on the evening of the first day. And then the conference

started properly the next morning. So, and I remember walking into this hall and seeing.

Yeah. So many people taking notes with, uh, sub-ether edit because it, it used Bonjour to

connect. And so if somebody was, was using sub-ether edit in a room, you could automatically

see the people around who were, who were also editing and everybody was editing, um, uh, the,

the, the, their kind of joint conference notes on, uh, in this application. And at the time I was a,

a Windows user, um, still. And, um, uh, I, before I left San Diego, I had, uh, gone into an Apple

store and bought a Mac. Nice. This, this is, this is really part of what we were talking about

earlier, right? These dev tools. I mean, would this happen today? I really, I wonder, right?

It's, I mean, I'm don't recall sub-ether edit. Was it always free? No, I think that was a,

I don't remember. It was paid. Yeah. Yeah. Such great tools.

Yeah. And it was a great tool. And, and the, the, the richness of that app ecosystem on the Mac was

absolutely the reason the platform was just, just flat out straight without, I say this without any

hesitation, it was better. It was absolutely better because of that native application

ecosystem. And partly, um, uh, the fact that everything moved towards the web and therefore

electron became a thing. And, you know, that's, that's part of what happened,

but I think it's more than that. Yeah. Well, text mate is the other thing,

right? That was equally powerful in attracting people to the platform. I mean, I'm, I still

have text mate up right now. It's, it's sort of my note taking scratch pad, um, or, you know,

config file editing thing. So if you want the full, if you want the full story, it was a combination

of sub-ether edit and text mate, because I was, I was also experimenting with, um, with Ruby at

the time and, and Rails was just, Rails was like 0.5 version, 0.5 or something like that at the

time. And there was an amazing, very famous video that, um, David Handmaier Hanson made at the time

where he built a blog software, built some blog software with Rails using text mate, um, in like

five minutes or something like that. And it was a great demo, really, really great demo. And, uh,

text mate was a big part of why it was a great demo because it was the first editor I'd seen

that had auto expanding snippets. And the comp, so I, I was already thinking about buying a,

it wasn't only sub-ether edit. Sub-ether edit was the, the, the, the final straw, the last straw.

Um, but text mate was, was there, text mate was, was the initial, initial kind of push towards it.

And then, uh, sub-ether edit broke, uh, broke the camel's back.

Nice. Yeah. I mean, they're great tools. Really great, great tools.

Yeah, really. Yeah. So in, in, uh, most, before we, before we get more stories of, uh, of how we

all got into this platform, let's wrap it up there, shall we? Um, we will be back in a couple of weeks

with some more, um, news, hopefully no more bugs and, uh, of course some more package recommendations.

So I will speak to you in a couple of weeks.

Yep. See you in two weeks. Bye-bye.

Alright, bye bye.