Leo Dion (host): Welcome to
another episode of Empower Apps.

I'm your host, Leo Dion.

Today, I'm joined by
Matt Massacott again.

Matt, thank you so much for
coming back on the show.

Matt Massicote (guest):
I'm happy to be here.

Thanks for having me.

Leo Dion (host): Before we get into your
upcoming presentation at Swift Toronto.

Go ahead and I'll let you
introduce yourself and chime.

Matt Massicote (guest): Sure.

Well, my name is Matt.

I'm a longtime macOS developer.

I've done a little bit of
iOS, but not that much.

I put some time in at Apple, working on
iOS actually and then ended up working

independently and so I'm like a part
time independent developer right now.

And one of the main projects
I work on is called Chime,

which is a like lightweight
minimalistic editor for the Mac.

Leo Dion (host): And we had you on,
was it last year or a year and a

half ago to talk about extension kit?

Matt Massicote (guest): yeah, yeah,
it was right about a year ago.

And it's funny.

Leo Dion (host): go ahead.

Matt Massicote (guest): It's funny
because I don't remember where I was in

my extension kit journey when we talked.

But all the stuff that's come up for
my work on concurrency started there.

Leo Dion (host): Okay before we
get into that, I do want to ask did

anything happen with Extension Kit since
DubDub, and as far as Extension Kit

is concerned, like, how's that going,
outside of what we'll talk about today?

Matt Massicote (guest): I would, I would
love to sit down with somebody who works

on extension kit at Apple and just hear
the story about what is going on there

because they just to remind people.

So it was introduced.

Last year with absolutely
no mention at all during

Leo Dion (host): talks.

Yeah,

Matt Massicote (guest): Yeah, no,
nothing, which is really unusual.

Additionally, it's a weird
thing to add to Mac OS, right?

Because almost all of it, almost all
the features that it provides were

technically possible before they
were extension kit makes it easier,

but loading code as plugins is all
things that you could do before.

So the end parts of extension kits.

Are, and to this day,
still exposed on iOS.

So it was a weird, it was a weird thing.

And it really felt to me it
was supposed to launch for iOS.

Got pulled at the last minute,
that's why we saw no video about it.

And they just kinda let
it sit, until this year.

And then so this coming up year, I
was convinced, 100% convinced, that

it was gonna be released for iOS.

And what's weird is, more of it was
added, more API was added to iOS.

But still not enough to actually use it.

And there was also no videos about it.

Leo Dion (host): How about Mac OS?

Anything different there?

Matt Massicote (guest): No,
it's basically the same.

Leo Dion (host): Okay.

Interesting.

Matt Massicote (guest): Yeah.

So something funny is going on.

Leo Dion (host): Yeah, yeah, yeah.

Is it only available on Mac OS?

So, no vision, no watch, no TV.

Matt Massicote (guest):
vision OS is the same.

No watch, but vision OS and iOS and, and
well, iPad, it's the same thing where

there's portions of it are available on
iOS, but not enough to actually use it.

Leo Dion (host): Okay.

Matt Massicote (guest): Just bizarre.

Leo Dion (host): we'll put
links to our previous episode.

I'm definitely interested in jumping
into it once I get farther with Bushel.

But, yeah, it's, it's interesting.

So it sounds like...

Your work in extension kit, you
found out a few little quirks with

async await specifically you want
to give just the big picture of

what kind of issues you've run into.

Matt Massicote (guest): Yes, absolutely.

Well, so it started with
my work on extension kit.

Part of the idea here is
you build an API that other

developers are going to use.

And it's this public API that
you publish as part of your

extension kit, SDK, however
you're going to package it up.

And so I thought, well, if I'm
going to do this, I might as well

be as forward looking as possible.

At the time, I hadn't looked at
concurrency at all, but I thought

this is a great opportunity.

I'm going to dive in here and I'm
going to see if I can make it work.

And at the beginning, that
seemed like a wonderful idea.

It was, it's felt easy.

It felt like you're just getting rid of
completion of completion handlers and

replacing them with the async keyword.

Like it felt really nice.

And I got pretty far with it.

The integration with Chime is also
probably uncharacteristically deep.

I would imagine that most people
that are going to be using extension

kit, it's going to be a small
feature that you're going to expose.

But with QIIME, it just
made a lot of sense.

So it's very deeply integrated
into the application, used all

over the place, everywhere.

And so it impacted pretty much
everything about how the app works.

And that meant that concurrency
started, it's a little bit viral.

And so it started getting it working its
way into more parts of the application.

And I think the first thing that
really hit me when I started

realizing, okay, I don't know if
I know what I'm doing is I started

seeing really terrible race conditions
where I would have like these events

happening ABC, but, but what would
be happening in the extension would

be, they would not be in that order.

Leo Dion (host): Hmm.

Okay.

Matt Massicote (guest): And at
first I was like deeply confused by

this, but after I started looking
into it, I realized that it makes

everything makes total sense.

What was happening, what was
going on here was I was just

putting these unstructured tasks.

To start running, to get,
to get an async context.

And I think this is a thing a lot
of people will do, is that apps

fundamentally, they start with one
thread, one main, one main, I mean

actor, but one main thread, and
eventually they're going to start

running stuff, and they need some
sort of async context to do that.

And so in many cases, And if you look
at, you'll see blog posts all over

the place saying concurrency is easy.

And if you don't have an async context,
you just use a task and you're done.

And that is technically true, but tasks
don't synchronize across each other.

So you can make them synchronized.

You can start task A and then wait
inside of task B for task A to be done.

That's totally allowed.

That's the way you do it.

Leo Dion (host): Mhm.

Matt Massicote (guest): But if you don't
establish these explicit dependencies

across tasks, they run in any order.

There's absolutely no dependency
enforced by the system at all.

And so this is where I first started
running into problems is because

I was introducing concurrency in
this fundamental part of my app,

but they were not really connected
inside of the app structure.

So there's one call over here
and then many, many, many, many,

many layers and APIs distant from
that place, there'd be another

async call that I needed to make.

And previously, those
were completion handlers.

They would start, run a bunch of code,
and then this one would start and they

would always start one after another.

And replacing those calls, those
completion based calls with

tasks meant that that ordering
was no longer being enforced.

And that's really the fundamental
thing that I was running into,

Leo Dion (host): That.

Okay.

I'm gonna, I'm gonna.

Don't take this the wrong way, but
that sounds like a feature, not a bug.

Matt Massicote (guest): Being ordered.

Leo Dion (host): yeah, because yeah,
that's where you're kind of like, for

me, an async task would be something
you just run whenever you want to,

and it has no dependencies per se.

But what it sounds like here is is you
need to set up some sort of it sounds

like a use case for an actor where you
have one central lane where things are

run and it can only be run on that lane.

Is that correct?

Matt Massicote (guest): actually,
no, but that's a very, that, that

makes sense what you're saying.

And you're right, it's not a
bug, it's a, what this is, is an

implication of changing from completion
based systems to async systems.

Leo Dion (host): right, right,

Matt Massicote (guest): And so the
implication, and it's like, took me

a super long time to actually even
understand, like, what is going on here.

And the reason is that a completion
based system has, you call it

synchronously, and then it will
do its work internally, it'll

do its work asynchronously.

And an async based system cannot,
it is impossible to do that

with an async based system.

The caller is the one who's
responsible for coordinating these

Leo Dion (host): right, right, right,

Matt Massicote (guest): You might have
some nice object that has a whole bunch

of completion handler based blocks, and
internally, it's got its own dispatch

queue, and when you make a call, it
synchronizes everything internally.

And that is no longer possible to do.

That pattern is not possible
to do with Swift concurrency.

Leo Dion (host): right, right.

So you're sa

Matt Massicote (guest): not supported

Leo Dion (host): so you were saying
actors are not what you want.

Can you explain that a little bit more?

Matt Massicote (guest): because you
have to use the async keyword as

soon as you use the as soon as you
introduce a wait It's up to the caller

that writes a wait to do the ordering
actors cannot internalize that stuff

and you might and at first you might
Think oh, of course they could because

you just put the queue inside of the
actor and that's true You can put

the queue inside of the actor, but
you no longer have the ability to

serialize Putting stuff in that queue.

That's up to callers.

And so this is like
this fundamental change.

I think a lot of people are very
used to, I certainly was, used

to writing code this way, and
you just can't do that anymore.

When you're going into concurrent.

Leo Dion (host): okay.

So what did you end up
doing to get around that?

Matt Massicote (guest): Well, first I
would say I swore a whole bunch, and

then figured out what the problem was.

It took me a long time to even
understand the problem, but

once I got it, what I ended up
doing was introducing a queue.

Like, fundamentally, you need a queue.

There are many problems, many,
any, pretty much any time you have

a stateful system, you have to be
able to serialize these things.

And so I had to introduce a queue.

But I had this problem because I
had a whole bunch of legacy code and

I could have like spawned task A.

Up at the top, grabbed grabbed it in
a variable and then passed it through

all these callers to the spot where I
called task B that would have worked.

But it was just so awkward.

And so it was just totally
unwieldy to do that.

So what I did was I
introduced a global queue.

So one queue for the entire application.

And I could submit, instead of just
standalone tasks, I would make a,

make a task, that task, and then
put it into this global queue.

Leo Dion (host): Okay.

Matt Massicote (guest): And that
was my, I suppose I would call

that my my stopgap solution.

That enabled me to remove
all the race conditions.

It's gross, but it was possible to do.

Leo Dion (host): What if, like, what
other people, what, what if other

people, what if you found other
people are doing online for what

you're particularly running into here?

Matt Massicote (guest): I have not
found anybody really talking about

this exact kind of problem in this way.

I think people have noticed the ordering
problem of a standalone unstructured

task is very well understood.

And you said, it's not
a bug, it's a feature.

And you're right, that is
how it's supposed to work.

But I think that when you start
introducing concurrency, With stateful

systems into existing applications.

That's the only time these kinds of
things are really going to come up.

Leo Dion (host): yeah, and it's
I think that's the key is like

stateful right where it's like Oh,
you need to know when something

is ready and then run the task

Matt Massicote (guest): right?

Absolutely.

That's the critical component
of, I think many people have been

introducing concurrency into their
apps, using things like the SwiftUI.

task, and they're probably loading
code, not loading code, loading

data from some remote from stateful.

Leo Dion (host): Right, right.

Yeah.

What I wanted to jump in and talk a
little bit more about you mentioned

some like older APIs that you're
running into were any of those

running into issues with async await?

Now I'll, I'll just preface by saying
I've run into issues with like NS

operation, like maintaining some
old code that uses NS operation.

And then we want to do async await.

And it's like, Oh yeah, there's like all
sorts of issues with older objective C

APIs once you start doing async await,
did you run into anything like that?

Matt Massicote (guest): I'm very
curious what your problem was,

but first I'll say I totally did.

So, I think that the, my first
realization along this journey was

that I didn't really understand
how to establish asynchronous

contexts in a way that would let me
do the things I was already doing.

That was like one big realization.

But then the second really
important realization was All the

warnings are turned off by default.

And so what I was doing, was I was
making an API that was inherently

async, but I was, because there was
no warnings, I didn't understand

how to do that correctly.

Leo Dion (host): Okay.

Matt Massicote (guest): And so once I
started realizing, okay, in order to do

this, I have to turn on these warnings,
turned on these warnings I had built an

API that was fundamentally incompatible.

And then what does that even mean?

And it could be what you're talking
about is if you have an async function,

it needs to be either accepting sendable
stuff or it needs to be both accepting

sendable stuff and returning sendable
things or isolated to a global actor.

And you have no other alternative.

That is it.

Leo Dion (host): Right.

Right.

Mm hmm.

Matt Massicote (guest):
And so what's interesting.

So two things I have
noticed existing APIs.

One is apple.

I think many people on apple
in apple internally did not

realize this was the case.

Leo Dion (host): Mm

Matt Massicote (guest): And so apple has
shipped a few APIs that don't pass these

warnings, but they are explicitly async.

Leo Dion (host): Yeah.

Matt Massicote (guest): like one
example I'll give that I just happened

to notice was it's in HealthKit.

It was like a HealthKit, I can't
remember if it's called Query,

but it's called an async query.

And it is specifically built to allow
you to use concurrency both accepted

and returned non sendable stuff.

So whoever made this did not
understand that that was, that

was an impossible API to build.

Leo Dion (host): Yeah.

And I think that's a big, like, that's
a big Swift 6 thing is like, all

that stuff has to be fixed by then.

Matt Massicote (guest): Right.

But now, so the health kit
team had this problem, right?

Because, because they ship this API,
they, they must either make the HK

health store, I think it's called.

And they must make that sendable as
well as the return value, or they were

going to have to deprecate this API.

Cause if they couldn't make
them sendable, this API

can never be made to work.

Well, I suppose

Leo Dion (host): isn't there like
an attribute where it can basically

say, Oh yeah, it's sendable, don't
worry about it, and you don't

Matt Massicote (guest): has to
actually be sendable, but yes, yes,

Leo Dion (host): Okay.

Okay.

Matt Massicote (guest): You're right.

I suppose the other, other alternative
and one that I have used a lot

is you just can't use this on
anything other than a global actor.

Leo Dion (host): Yeah.

Matt Massicote (guest): hammer
that you can use that you can

always put things onto your own
global actors onto the main actor.

And that is necessary in many cases

Leo Dion (host): so we healthcare,
were there any other APIs you ran into

like any app kit stuff or anything like

Matt Massicote (guest):
well, extension kit.

Leo Dion (host): Okay.

Matt Massicote (guest):
so, and widget kit.

So the, so examples of these
things are, these are APIs where.

It's probably supposed to be main actor
isolated and by all accounts, by how

you're understanding how the API is
work, it really should be, but Apple

has not done that annotation yet.

Leo Dion (host): I want to say like,
if you do any of the new stuff in,

in Xcode 15 beta, everything is like
automatically main actored for you.

Oh, really?

Matt Massicote (guest): Yeah.

So both extension kit and
widget kit are still not fixed.

And so they're impossible
to use without warnings.

Leo Dion (host): Okay.

I know SwiftUI, I used to have
to put everything in a main

actor for UI changes for obvious
reasons, but now, like, they

automatically do that for you.

So,

Matt Massicote (guest): Yeah.

You know, there's a really
strange Swift UI in particular.

There's a really strange behavior.

I'm going to mix up which one it is off
the top of my head, but there are, it's

possible for property wrappers, which
is used all over the place in Swift UI

to implicitly impose actor isolation.

So this is the thing that trips up so
many people cause they don't understand.

They're like, if I remove an at state
object, everything, if I, if I leave in

the at state object, everything works.

And if I remove it, all of a sudden
I'm getting warnings about not being on

the main actor, what's going on here.

And the reason is that as of right
now, property wrappers can change the

actor ness of the type that uses them.

Leo Dion (host): Well, I'm wondering,
too, like, you can put, you can

say something as main actor on a
protocol, and then if you're putting

all sorts of semantic sugar, like,
macros, if it's automatically

putting that in there for you, too.

Because I've been doing a lot more
observation stuff, and less, like, the

Matt Massicote (guest):
that is possible also.

But I can tell you that they're
going to remove that behavior.

So the behavior of protocol of
excuse me, of property wrappers,

changing actor ness of types is

Leo Dion (host): Okay.

Okay.

Matt Massicote (guest): because
it just, it's confusing everybody.

And so that's, you might need to
start putting more at main actors

on your types because of that.

Leo Dion (host): Yeah.

Yeah.

Yeah.

Yeah.

And that's, I've, so going back to
what you were talking about, about like

sendable and stuff, there's like, at
least as far as an Xcode and in the

Swift package, you can, you can turn
those flags on and, Man, like, yeah,

I've run into, so there's all sorts
of actor stuff you have to add for

Swift 6, there's every protocol now
requires any keyword, like, it's crazy

how much stuff and it's understandable
why we haven't seen Swift 6 being ready

yet after, after dub dub, so, yeah.

Matt Massicote (guest): know, I, so I
think that, and I'm going to make this

prediction in my talk, but I think
that's probably going to be the theme.

I think, I think that Swift 6 is going
to be rough because I think there are

Leo Dion (host): I think it's going to
be the roughest since, whatever, SWF3

or SWF4, whenever we got ABI Stability.

It's been a while since we've had any
rough upgrades in SWF, so yeah, I agree.

Matt Massicote (guest):
going to be even rougher.

I think it's going to
be the worst one yet.

Yeah.

And the reason because, and I'm just
using my experience as an example is

that I built an API that can never be,
it was using async await everywhere

and it can never work impossible.

And I needed to change the API.

That API was unsupportable.

And so, there are, I'm sure there
are people right now that are

building their apps happily building
async await everywhere into their

app in a way that will never
be compatible with concurrency.

And once those war so, and so this
is really weird because Apple went

from optional warnings to errors.

This is, this is a
mistake in my opinion.

Leo Dion (host): well and I it's
gonna take a while I feel like it's

gonna take a while like I wouldn't
be surprised if Swissx isn't even

ready for dub dub 24 at this point Cuz

Matt Massicote (guest): That's possible.

Leo Dion (host): like we like you
said, I don't feel like it seems

weird to go from optional warning
to error to error I think at some

point maybe in the next year.

We'll see an Xcode release where
Those are gonna become actual warnings

Matt Massicote (guest): Yeah, and
I think that if you are using, if

you are using concurrency and don't
have complete turned on, not just

targeted, but complete, You're opening
yourself up, you're opening yourself

up to some really serious pain.

Because if you are building a system
that cannot be compatible with this,

what are you going to do at that point?

And I think you want to know that now.

So you want to have those warnings
turned on, so you know right away at the

beginning, Oh, I'm building something,
but it's actually harder than I

Leo Dion (host): yeah.

And I'll I have a good blog post, I
forgot who it was, who showed you how

to turn those warnings on for Swift
6, and I'll put that in the show

notes because it's really helpful.

Do you want to talk about well, one
of the questions I had, do you miss

anything regarding dispatch queue?

It sounds like you do miss a lot as
far as dispatch queue, is that correct?

Matt Massicote (guest): I mean, I don't
know if miss is the right terminology.

Leo Dion (host): Yeah, I know.

I know.

Matt Massicote (guest): I, I think that
I don't think that for, I'm talking

about for like complex use cases, I
would be surprised if you can get away

with using a concurrency in complex
ways without using a current concurrency

compatible lock and or queue.

I think it's possible.

I think some apps can do it, but I, but
I, boy, I think you'll have a hard time.

I mean,

Leo Dion (host): You keep saying this
stuff and I'm like, why, why not actors?

What's wrong with actors?

Isn't that kind of
what it's fundamentally

Matt Massicote (guest):
that's a great question.

That's a great question.

So, what are actors for?

So actors protect mutable state,

Leo Dion (host): Okay.

Matt Massicote (guest): they, what
they cannot do is they cannot control

ordering of access to that state.

So actors are

Leo Dion (host): they can, but they're
specifically for race conditions, right?

So you could, you're like,

when you talk about a lock, like it's
essentially what an actor is for, right?

Matt Massicote (guest): yeah.

So the lock is about re entrancy.

So actors are re entrant, which
means that the same object so

that you can get the call into
the same method multiple times,

Leo Dion (host): Yeah.

Matt Massicote (guest): more than one
thread can be running inside of an

actor, isolated method at the same time.

Leo Dion (host): Say that one more time.

Matt Massicote (guest): So more than
one thread, more than one thread

can be inside, running inside of it.

So, take a really,
really simple example.

Imagine you have a little cache,
where you want to be able to like

reach out to some service, and it
takes a long time to get that value,

so you want to cache it in an actor.

Leo Dion (host): Okay.

Matt Massicote (guest): So you're
probably going to do some little check

if the value is op it's optional and
if the value is there, I'm going to

return it, and if not, I'm going to
go do this await, and I'm going to get

it, and then I'm going to return it.

This is like a really classic
caching pattern, I hope you're

following what I'm talking about.

That doesn't work with an actor.

Even something like that does not work
with an actor, because between the

check and the await call, another object
can come in and make that call again.

Leo Dion (host): See my thought, my
whole idea with actor was that like

it's basically a way to make sure
that somebody can't like two people,

two people, two, two threads can't do
something to an actor at the same time.

Like I thought it was kind of
like that where it was like

essentially a cue where it's like

Matt Massicote (guest): You know what?

In a lot of ways, it is
exactly like a dispatch queue.

But the problem with, and it's the
same kinds of problems with dispatch

queues, where the dispatch queue,
the body of the queue is synchronous.

Leo Dion (host): right.

Matt Massicote (guest): So, and
the same, it's the same kind of

thing with an actor, is that the
synchronous code, yes, is serial,

and only one thread can be running
in the synchronous code at one time.

But as soon as you put an
await in there, more than

one thread can hop in there.

Leo Dion (host): Okay.

Matt Massicote (guest): And so, and
that's the danger, is that it's kind

of similar to queues, where like, if
you need to do some work in a queue

and it's all serial work, you're safe,
you can totally isolate everything.

But if you want to hop out to some
other queue, do some long work, and

then get back into that queue, somebody
else can get in, another thread can

get into that queue at the same time.

It's a very similar kind of problem.

Leo Dion (host): Okay.

Matt Massicote (guest): And so,
there's this wonderful package called

semaphore that is a concurrency
compatible lock and it lets you

solve that specific problem.

If you look at the actual
implementation required to make

something simple like a cash to
value in an actor, it is bananas.

It is bananas how complicated it is
and it's because of this re entrancy.

Leo Dion (host): okay.

Matt Massicote (guest): And a
simple, a simple concurrency

compatible lock, you cannot use
the regular locks and semaphores.

But a concurrency compatible
lock makes it so much easier.

It's worth it.

Leo Dion (host): Okay.

Yeah, I've actually had to use a
dispatch semaphore for an async

call because there is no, like,
that's the closest thing to a

semaphore I had in i i i in Swift.

So, yeah, I feel like that's
definitely something missing.

Matt Massicote (guest): it is.

And so there's, there's one built, but
the dispatch semaphore has a problem

because of the concurrency runtime
requires that all actors be able to

make forward progress and a regular
semaphore breaks that requirement.

So you rest, you risk hangs
using a regular kind of lock.

Leo Dion (host): Was there anything
you missed from dispatch queues?

Matt Massicote (guest): So, so we're
talking about locks here and all this

why actors don't solve that problem.

So, but, so there's also,
there's no mechanism.

Actors, even if reentrancy is a thing,
actor reentrancy is a thing that they

address, which is being seriously
talked about for Swift 6, because a

lot of people are having this problem.

Even if that gets addressed, it still
does not help you with ordering.

Or

Leo Dion (host): Right, right,

Matt Massicote (guest): stateful system,
there's no way to control how things go.

So there, you need a queue.

A queue is a thing that
you're going to need.

Leo Dion (host): Yeah.

So like one of the things I think
people, I actually, like I said,

I think it's a feature, it's a bug
because one of the things that I had

to learn is that when I first started
async await was that I assumed in

a function, when you run a bunch of
async stuff in a function, it was

going to do it in in, not in an order.

So I'm in like the opposite boat.

And then I learned, Oh, if you want
things to not run in an order, then

you have to do like the async let.

In order to do things in a non order.

This is not what you're running into.

You're

Matt Massicote (guest): No, I,
yes, that is, that is confusing.

You're right.

Leo Dion (host): Because I was
like, I don't, like, these things

don't depend on each other.

Compiler, please just
run it in whatever.

Like, run them all together.

I don't care.

And then I was like, Oh, you have to do
this async lat, which is totally not...

Like, that's a little bit weird to

Matt Massicote (guest):
I agree with you.

It

Leo Dion (host): Because it's like, the
whole point of async away to me is like,

I don't, these things don't, unless they
depend on each other, and I figured the

compiler can figure that out, I don't
need to tell it, like, it should, it

should just run it in whatever order,
I don't care, like, so that was one of

the things I first had to, had to learn
is like, oh yeah, use this async let to

let it know that I don't care the order.

Matt Massicote (guest): Yeah.

Well, you can do that for things
that are, have no dependency.

So if you're doing like ABC
and they don't matter, then

you can do that kind of thing.

But if you have like, you're going to
do a, and it's an async call, and then

you need to use the result of that
in B now the ordering is required.

So within a particular context, within
a particular async context, it's

all going to run things in order.

Leo Dion (host): right, by default,

Matt Massicote (guest): these contexts.

Leo Dion (host): around, which is
your issue, where you have Function

over here and function over there.

Yeah, yeah, yeah.

Matt Massicote (guest): And I think
that's, so that's one of the reasons

why I think there was this deep
misunderstanding even internally at

Apple is the, when, when async await
was originally introduced, there's

this automatic translation that
you can use between a a completion

Leo Dion (host): handle her.

Yeah.

Refactor and Xcode.

Yeah.

Matt Massicote (guest): it'll
just like magically make it work.

And I think that is, that was
done because I don't think there

was a deep appreciation for how
dangerous that kind of thing can be.

Because that kind of change can be so,
if you're thinking, oh, I'm just going

to change it into an async an async
await, and I'm going to wrap it in a

task, that it has different semantics.

And so you're changing, when
you make these refactors, you're

actually changing the semantics
of how the code works as well.

Leo Dion (host): Yeah, yeah, totally.

Matt Massicote (guest): And I'm not
sure everybody understood that one.

Leo Dion (host): it seems like you're
looking at some of the SWIFT proposals.

What do you see out there as something
you're looking forward to that kind

of remedies some of these issues?

Matt Massicote (guest): Oh,
well, there's a, there are many

changes that are out there.

So one really difficult one that I
think is also pretty hard to understand,

even before concurrency was out there,
is needing to do stuff in a D init.

So in your dinit method, if you
have a main actor thing, you're

thinking, okay, my dinit is going
to run in the main actor too.

But that is actually not the case.

And I think that is really
surprising to people.

Even from objective C, you might think
like, how could it be my view is being

deallocated, not on the main thread?

That's, doesn't seem right.

Leo Dion (host): Even if you, like,
even if you mark your whole type

as, or class as main actor, it's
still not gonna run, didn't it?

Okay.

Matt Massicote (guest): yeah, yeah.

And this is, this can be a
really big problem for certain

Leo Dion (host): I would

Matt Massicote (guest): Yeah.

Yeah.

And I don't know that they have fully
sorted out what they're going to do

about it, but it is an understood
problem and it cause UI kit.

I don't even think this is well
known, but UI kit and UI view in

particular, it goes through these
Herculean efforts to try to make sure

your D in it, or your, your dialect
actually does run on the main thread.

Leo Dion (host): Okay.

Matt Massicote (guest): But it requires
an enormous amount of work at the

app library level to make it happen.

Leo Dion (host): Okay.

Matt Massicote (guest): And so I think
that they're trying to solve this

problem and I think that'd be wonderful.

But I don't know yet if there's
currently any solution out there.

Leo Dion (host): Okay.

Matt Massicote (guest): So that's one,
that's one that's being talked about.

Well, there's this whole property
wrapper changing actorness.

That's a, that's a really confusing one.

I'm really happy to see that
one has been accepted and

it's gonna, gonna happen.

Leo Dion (host): Okay.

Have you looked at any
of the observation stuff?

Does any of that?

Okay.

Matt Massicote (guest): to,
but I haven't seen it yet.

Leo Dion (host): Okay.

Okay.

Matt Massicote (guest): I mean,
there's also things that are

tangentially related to async await.

Like.

I have had a really hard
time using async sequences.

Leo Dion (host): Okay.

Matt Massicote (guest): of, one of
the reasons why is async sequence does

not have a primary, the protocol does
not have a primary associated type.

So you can't use any async

Leo Dion (host): Yeah, nah,

Matt Massicote (guest): You
can't use any async sequence.

Leo Dion (host): right.

Matt Massicote (guest): And so
that's usually not a big deal

unless it's at an API boundary.

Leo Dion (host): Okay.

Matt Massicote (guest): And then
it's an enormous deal because what

type are you supposed to return?

Leo Dion (host): Okay.

Yeah.

Yeah, that's weird.

Matt Massicote (guest): it is weird.

Yeah.

Leo Dion (host): because they slapped on
primary associated types so many places.

It's so weird that

Matt Massicote (guest): you know,
it was, it was, it was intentional.

And the reason why was they
were thinking about how they

were going to expose the error
property of async sequence as well.

And I think that's what
caused the hook, the hangup.

But I would love to see it.

I would love to see it because that's,
that's been a problem for sure.

Leo Dion (host): and I'll put a link
to my talk at Swift heroes somewhere

in here So people can check that
out if they want to know why primary

associated types are so important

was there anything you looked
at at DubDub DC this year?

You said, you said a few
things, like what specifically?

And anything that
related to Chime I guess?

Matt Massicote (guest): Well,
you know, I was hopeful for

some more extension kit changes.

There's a few little things
that have been problematic,

but there was nothing there.

No, there was nothing really.

I mean, I'm always interested in
what goes on with the text system

because there was this big migration
from TextKit 1 to TextKit 2.

And I would say that
that has gone largely.

Terribly text kit two is, is
getting better, but it is so

it was, it was launched in
an absolutely unusable state.

I'm amazed that it, that it chipped.

That was with, I think
that was Mac iOS 11.

So that was two years ago.

Last year it got a lot better.

But still has some really major bugs
that I don't know how to work around.

I haven't tried hard, but
I know that it's a problem.

So I was hoping for a little bit of talk
about like what's new in the tech system

and maybe some changes that would help.

I didn't see anything there.

The things I did see, I think
the macro stuff is fascinating.

Leo Dion (host): Mm hmm.

Yeah, I agree.

Matt Massicote (guest): a lot
of people have started to feel a

little bit like Swift is getting to
be too complicated of a language.

And it's complicated.

But yeah, but I, I think that it's,
I think it's a very interesting

direction to go in anyways.

These are the fundamental problems,
they have to be solved somewhere.

And so I like the idea of people
thinking deeply and trying to come up

with a, a solution in the language.

Leo Dion (host): I have an
idea for a talk here about

how complicated Swift is.

I, it's, it's been floating in my
head, but yeah, I have an idea for

a talk I want to put together on
why people should try not being too

intimidated by it and, you know.

Anyway.

You'll see that in the future.

Future, in the future, soon.

Cool.

Is there anything else you
wanted to cover about Async Way

about Chime before we close out?

Matt Massicote (guest): Well, you
know, so, last year was all about me

adopting extension kit and building
this API that was never going to work.

And then this year, kind of in
the background, I've been slowly

chipping away at fixing it.

And I can say that it's, it's
been incredibly difficult.

And I think the reason why
it's difficult, one is that

actorness is very viral.

So if you find there's this
one little thing you need to

change to be main actor, it's
a big, it can be a big problem.

So that's one thing another thing
is, you know, you got to be careful

with protocols because protocols
and actors and even main actor

isolated objects don't always mix.

And I think that we've been very, as
like a swift community have been very

quick to use protocols everywhere.

And that can be problematic
when when adopting concurrency.

So that was a one that
was tricky for me.

But I have, I'm pretty close actually.

So I, I'm almost finished.

Updating an enormous amount of packages
and a big API surface to actually

be something that works correctly
and concurrent with concurrency.

And is I think also what I want.

So I'm very happy with that
progress, but it's been very tough.

Leo Dion (host): awesome.

Well, I am excited even though I
won't be in Toronto, I'm excited

that you'll be presenting on
this topic and telling people all

the lessons that you've learned.

I think it's gonna be
awesome and fascinating.

Matt, thank you so much for
coming back on the show.

I really appreciate it.

Matt Massicote (guest): Absolutely.

Thank you for having me.

Leo Dion (host): Where can
people find you and Chime online?

Matt Massicote (guest):
Well, Chime is at ChimeHQ.

com.

And I've just finished removing
all of the bird site references,

so you can find me on Mastodon.

You can find me on Mastodon.

social slash at Maddie M.

Leo Dion (host): It's
on a bird site today.

Today, as of the recording, it's,
it's an X site, so you actually have,

I'll have to, yeah, I'll have to fix,
I'll have to fix this in editing,

make sure that people know it's the
X site, not the bird site today.

People can find me on the X site at
LeoGDeon but I'm also on Macedon at

LeoGDeon at My company is bright digit.

Please take some time.

If you're watching this on
YouTube to like, and subscribe.

And if you're listening to this on a
podcast player, please give me a review.

If there's anything you want to talk
about or anything you want to hear

about, let me know, DM me, email me.

Send me an X, I guess.

I don't know, whatever it is.

But and also buy a ticket to Swift
Toronto if you haven't already,

hopefully this episode will be
out in time for you to do that.

Thank you everybody.

And I look forward to
talking to you again.

Bye everyone.