Subscribe
Share
Share
Embed
Join us for talk of bugs and how we've either fixed or worked around them, why creating sustainable developer tools is so hard, and the story of which indie Mac app made Dave buy his first app!
News
News
Packages
- Grape by Zhen Li
- Firefly by Taylor Lineman
- Swift-ISO8601-DurationParser by Leon Hoppe
- automerge-swift by Joe Heck
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
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.