Ludicrous Types with Nick Lockwood

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Leo Dion (host) (00:03):
Welcome to another episode, empower Haps.
I'm your host, Leo Dion.
Today I am joined by Nick Lockwood.
Nick, thank you so much for coming on.

Nick Lockwood (guest): Thanks for having me. (00:13):
undefined

It was so awesome to be with you in London
at Riverside Swift Conference.
I'm a big fan of yours for a long time.
Big fan of Swift Format and yeah, youdid a great job at your presentation.
But before we jump in, I'll letyou do your own introduction.

Nick Lockwood (guest) (00:31):
Okay.
My name's Nick.
I'm an iOS developer.
I have been for about 15 years now.
Prior to that I was aweb dev for a few years.
I.
I've mostly workedlike in, in companies.
I do a little bit of my ownsort of side projects as well.
And I maintain quite a lot ofopen source libraries as well.
And some tools including SwiftFormat, as you mentioned.

So before we get started talking about some of the
stuff we wanted to, I just wantedto see if you had any thoughts about
the conference and like how has itmaybe changed your perspective on
Swift and where things are headed?

Yeah, I really enjoyed the conference actually.
I wasn't really sure whatto expect beforehand.
I've never been to a sort of serviceside Swift conference before.
And yeah, obviously like mymain focus is app development
predominantly iOS development.
So I wasn't sure how relevant itwould be, but it was actually,
it was really interesting.
And I think the the sort of the realburied lead was the presence of so
many Apple people there as well.

(01:25):
Like the opportunity to.
Meet and talk to like folks who actuallywork on Swift and Apple tooling.

And I'm like, I've been to a few conferences, but I
think this is the first one whereI've seen a lot of Apple people and
also like Apple actually sponsors itbesides some of the other companies
and of course Tim's company as well.
But yeah, I mean they're like activelyinvolved and actively interested in it.
It was almost, I was telling people,especially the talks from Ben and
Tony at the beginning were very muchlike mini dub up talks in a lot of

(01:55):
ways, especially the announcementof Java and AOP was really cool.

Yeah, it absolutely had that feel to it.
And the fact that they were there inan official capacity as well, not just
hiding in the crowd and being anonymous.

It's so like you have, you, you have a gradient
from marketing apple stuff tolike developer geeky Apple stuff.
And at the very top you might havethe, like announcement of a new Apple
TV show, and then you have a littlebit more, is like an announcement
of a certain Apple product.
And then you get a little bitmore and you have the WWDC

(02:26):
keynote and then a little bitgeekier is the state of the union.
And this is like the lastlevel of like geekiness Apple
announcements is like Java interop.
And I was trying to think what othertalks there were, but just like for
instance, Franz talk on the widthpattern with Async Away, it's like
even more, it's like way down the geekylevel of apple talks and announcements.

(02:48):
So that was very cool.
At least I enjoyed it a lot.
And it was great to see them there.

Nick Lockwood (guest): Yeah, couldn't agree more. (02:53):
undefined

So should we start by talking about linting or do you want to
talk about your talk at the conference?

I guess we can talk a little bit about the talk.
So because, I was presenting to whatI was aware was a service side, Swift
audience, and of course, like my areaof expertise is really not that, like
I try to keep it as general as possibleand it seems to go down pretty well.
But yeah, generally the topic ofthe talk was Swift specifically
rather than necessarily like mobiledevelopment or app development.

(03:23):
With Swift.

I think everybody in that audience learned
something new from your talk.
It was pretty hilarious.
All the little ins and outs.
I'm just trying to thinkof what I picked up on.
I knew a lot of it oh, the factthat you, there's two ways of doing
an initializer with an optionalI knew optional was a enum.
I didn't know that.
If you say that, it changes theformat of the generated in it, which

(03:47):
I thought was really interesting.
And then, I don't know, therewere a lot of like odds and ends.
I knew that you could do a lotwith labels, but I'm always
scared of labels because I alwaysfeel like there were antiquated.

Got a sort of go-to feel to it, right?

yeah.
Yeah, exactly.

I think that is, that, it's like when I
first encountered labels, they werein fact a substitute for go to.
I'm a super old school developer.
Like I started with BBC basic, wherelike every line was numbered and,
you'd go to like line 10 or whatever,and then if you inserted more code,
you had to renumber everything.
I think I first encountered labelswhen upgrading to like visual Basic,
and it was like, there's no linenumbers, but how do you go to,

(04:23):
and that was the answer, right?
Yeah, I was a little surprisedthat labels are still around,
but they are quite useful.
And the way that they're usedin Swift is very structured.
You can't like.
Break out of a function or somethingcrazy and end up somewhere.
It, it is still followingstructured programming principles.
It's just sometimes it gives youthat little bit of extra flexibility
when you know it's break, but Okay.
But break from wherethere's so many options.

That was actually really helpful.
Yeah, I remember that from your talk.
That was really interesting.
Because I hadn't thought of that,like break from, so does that
work with continue, or would iteven be applicable to continue?

yeah.
Break, continue.
Like all of the kind of like loopterminating commands work that way.

That you talked about, what was the one thing that you're
like, people should know about it,and what was the one thing that you
say people should not know about it?

Oh gosh.
I mean there was a few thingsin there which are of the form.
It's really cool that you cando this, but please don't like,
like these little tricks were,

Do you remember one of 'em?

I'm trying to remember now.
I think the thing with the optionals,so that the fact that you can, depending
on whether you use optional shorthandor like the longhand form it's, I
have used it but like whenever Iuse it I put a big fat comment above
it saying, this is why I'm doingthis, because it's not intuitive.
It's all, and even so Swift Formathas like a rule that will turn like

(05:43):
one type of optional into the other.
And if you start like actually treatingthese as having a difference in your
code, it's easily the kind of thing thatsomebody will just come along and say,
oh, that's not our coding convention.
I'll just switch it to theother one and then maybe have
some unexpected side effects.
So it is dangerous to play withthings like this and actually I,
I caught up with one of the Appleengineers and they were laughing about
this 'cause they were saying likeI don't think that was intentional.

(06:04):
This wasn't like, it justhappens to be this way.
Like they didn't design it that way.
It's, it was somebody forgot toupdate a code path or something that
otherwise they'd have both workedthe same way all along, most likely.
So
It's relying on a bug.

I would almost go with the question mark
because that's the preferredway and the syntactic sugar way.
And then if you want a customin it, then just create a
custom in it that forces you to

Yeah, for sure.
I think one of the things I'verun into with Swift is that you
are really spoiled by all thecode gen that it does for you.
And having to you unfortunately getthese kind of like points where you
you just wanna do some little thing,you just wanna do some little bit
of customization and now you haveto rewrite everything yourself.
So it's it's

Codeable is a classic example

Codeable is and in fact this is yeah,
this is related to that.
So like sort of default initializers aresomething where it's yeah, you either
write nothing at all or suddenly youwant it to be public and now you have
to write like, 50 lines of initializerand then you have to keep that in sync
and update it forevermore every timeyou add a property from now on Codeable.
Yeah.
I really hate writing like manualcodeable implementations, not

(07:06):
because they're particularlydifficult to write or understand, but

But if it's one field, then you're like, what the hell?

Exactly.
And now I just said allof these other ones.
Yeah.
And plus, you look at one of thesecustom implementations and you really
have to look at this what is this doingthat's different from the standard one?
And you find like just somewhereburied in deep among a hundred
properties is an optional sort of,ha hand handling it just in that
one little special case, just veryslightly differently from the default.
And yeah, it's annoying.

And so then you just create a macro and spend three
weeks trying to write a macro for it.

I think we'll get to that conversation
later, but Yeah, for sure.
This is what leads to allkinds of craziness, right?
Like people wanna avoid having towrite the boilerplate so they do
something that only they can understand.

Programmers love to automate, even if it
makes, means it takes 'em longer.

Yeah.
I think there's an old joke whywrite in five minutes what you could
spend three days automating like.

Okay, so I wanted to talk about the future of Linting.
How much of a headache is it to maintainSwift Format with the fact that the
language, and that's what we wantto talk about today, is how much the
language has changed over the years.
Like how much of a challenge is that?
Because if you looked at thestuff today, like one thing we'll
talk about later is type throws.
I've been really into type throwslately, and that's a big change.

(08:14):
And then you got async awaitand actors and all that, and non
ol isolate and all that stuff.

That's a really good question.
And actually it's funny because likeSwift Format's quite an old tool.
Like I think I, I started work onit in 2016, something like that.
So it's it's coming up on a decade old.
And I actually did like a podcastwith somebody like a couple of years
after I created it where I told themlike, it was basically finished.
Like I, I considered it to be inmaintenance mode and I was done

(08:41):
with this because there's onlyso much you can add to a format,
and, like it wasn't like thelanguage was changing that much.
And I think the pace of developmentof Swift has actually really
accelerated in the last few years.
It felt like Swift was prettystable for a long time between
the three to five version era.
I don't think an awful lot changed.
And maintaining Swift Format duringthat time was pretty like low effort.

(09:03):
It was pretty low maintenance.
And since async away.
It is just been an explosionof new functionality, like
new keywords in every release,like new things to think about.
And this is a great thing and I'mactually super happy that the language
is evolving and there's cool newstuff to play with, but it certainly
has made my job a little bit harder.
I think maintaining sort of format,there's kind of two pieces to it.

(09:25):
One is making sure it doesn't breakthings like, if somebody starts using
a new language feature and SwiftFormat doesn't understand it it, it
will do something ranging from notunderstanding and maybe throwing an
error to potentially like corruptingyour code in some subtle way.
And that's like really bad.
And I don't want it to do that.
And I try and keep on topof that as much as possible.

(09:45):
Ideally, even having it updatedto support new functionality
before it's out of beta so thatlike people will never actually
see this problem in the world.
But there's the, there's a secondlevel of support for features,
which is with these new featurescomes new expectations in terms of.
Formatting.
So Swift's format's thing is that it'snot just a formatter, it's opinionated.

(10:06):
And I try and, have an opinionabout like, when there's multiple
ways to do things, I try and havean opinion about which is the
best way or, which is a good way.
And I try and add format rulesthat will, enforce that so that
code bases can be kept consistent.
That's the point of the tool.
And when necessary, I'll make itconfigurable because, not everybody
will agree about the best way, butusually people will have an opinion

(10:26):
on what the best way is, and I tryand let them automate that rather
than having to do it manually.
So yes, there's a lot of stuff that'sbeen added to the language where I
haven't yet really had time to form anopinion about what to do about this.
Things like typed throws.
Should I be writing a rule that willconvert un typed throws to type throws?
Is that even feasible?
I don't know, like I haven'thad time to look into that yet.

(10:47):
What I have had time to do is make surethat if you use typed throws, then you
know it's not gonna break your code.
And I think that's the bare minimum

So yeah, I think what's the, like what's
the future, of Swift Format?
Are you intending to support allthe new stuff and maintain it?
Is there some pointwhere you're just like.
Handing it off.
How, I remember you also sayingthat you don't even use Swift
Syntax underneath, right?

(11:14):
You're using your own Lex Parser type

That's true.
Swift Format actually predatesSwift Syntax by a few years.
So when I released Swift FormatSwift Lint already existed.
People often confuse these,but they're entirely unrelated

That's realms.

That's realm.
Yep.
And Swift Lint was using somethingcalled Source Kitten, which was a
wrapper that JP Simard wrote aroundsource kit, which of course is like
the underlying compiler for Swift.
And actually much morepowerful than Swift Syntax.
It can do things which Swift Syntaxcan't do, in which Swift Format can't
do because it actually understandsthe full structure of your project.

(11:49):
So there were rules in Swift lint forthings , like removing unused imports,
I think, and stuff like insertingself and things like that, which I
have a version of in Swift Format, butit's not complete because everything
that I do is basically lexical.
Like I, I just look at the what'shappening in the current file
and I can only apply rules thathave that level of understanding.
I don't, for example, knowthe types of variables.

(12:12):
If things are defined in anotherfile, I have no idea what they are.
So there, there arelimits to what I can do.
And , switching over to SyntaxSwift Syntax wouldn't actually help
solve that, which is why I've nothad, I've not had a great deal of
compulsion to do 'cause it wouldbe a huge refactor, a huge rewrite.
And it's not it exactlyclear what it would give me.
It would potentially reduce theeffort of updating to support new

(12:33):
features in the Swift language.
But it also comes with some burdens.
For one thing, it's a huge dependency.

I was gonna say that yes.
As

Nick Lockwood (guest): I have no dependencies. (12:40):
undefined

you learn that quickly.
How Yeah.

Exactly.
So yeah it's a massive thing.
It would increasecompile times and so on.
And like that, I need a goodreason to, to switch over to it.
The other thing is that it, SwiftSyntax is version specific, like it's
built for a specific version of Swift.
And one of the nice things abouthaving my own pauser is that I
can relatively easily support.
All versions of Swift, or at least mostversions of Swift, with just a single

(13:05):
code base, which is not, it doesn't seemto be an active goal of Swift Syntax.
So I don't anticipate thatthey'll be doing that.
And so yeah it has given me a lot offlexibility that like, I can release a
version of Swift Format that supportseverything back to Swift three, up to
like unreleased versions of Swift withfeatures that are still in development.
And, people can just havethe one version of the tool.
They don't have to installthe correct version for

(13:26):
their tool chain or whatever.

So have you looked at Apple's alternative Swift Format?
And what's your opinion on, obviously

Yes.

Swift Syntax, so that's a lot of fun to
have to get going, but like

course I'm a, I'm aware of it and I was, I've monitored
it since it would, it was its inception,there was in fact a Swift-Syntax in
the code base, unmaintained and barelyfunctional when I wrote Swift Format.
And I assumed it wasn't going anywhere.
And for many years thatassumption was true.
And then, suddenly at some point postSwift Syntax I think it was actually

(14:01):
a Google engineer whose name escapesme temporarily basically said, Hey
we should build a formatter on this.
And submitted that asa a, tool to Apple.
And they accepted it and it became partof their like standard set of stuff.
And even then, like it was severalyears before it really went anywhere,
finally, now it's being included withXcode as like a thing that you can
actually invoke with a key combo.

(14:24):
And so maybe every year I'm thinkinglike, maybe this will be the year that
Swift Format is sherlocked for real.
Yeah, arguably maybe this is theyear, like maybe it's finally
happened now that Swift Formatin Swift-Format is official.
Like maybe that's it.
Maybe it's time to startwinding down the project.
My, my thinking at the moment islike most, like when most people

(14:46):
get Sherlock by Apple you make anassessment and you're like, do I
add value above what Apple is doing?
And is that value sufficient to beworth the effort of maintaining this?
Because, a lot of the timeunfortunately it's sadly the case
that people will use the worst thingjust 'cause it's more convenient.
Or it's more standard orit's more out of the box.
And I think the Apple community isespecially like this, like everybody

(15:06):
jumped on combine and forgot about likeRX Swift and like the RX Swift people
were like, no, this only does 10% of thestuff that we but nobody cares, right?
Because it's the standard Apple thing.
So it's like that thisis what we use now.
So there is.
There is an element of that.
I'm sure that's the case.
It's also super confusing nowbecause now that Swift Format,
Swift-Format is a real thing,but it's called Swift Format.

(15:27):
I get people like giving mesupport requests and I'm like,
no, actually this isn't my tool.
This is Apple's one.
Or vice versa.
People post about Swift Format on socialmedia and I'm not sure whether they're
talking about my tool or Apple's.
There's all kinds of confusionthere and it's, it was bad

like a little thing in the Read Me Now where it's

I, it hasn't quite, I actually can't remember
if I have something there or not.
Like I remember I used to have thisconfusion with Swift Lint, which
isn't even like the same, but people
I saw you, I saw your tool.
Got mentioned that.
I was like, no, that was Swift lit.
but anyway it's fine.
It's fine.
I think basically what I'm gonna dois wait and see I'm still working on
Swift Format, like a bunch of peopleare still using it and I don't, I

(16:01):
don't wanna give them a, I don't wannagive them a painful migration path.
And also like it, it aspires to do somethings, which I don't think Apple's
Swift Format will ever try and do.
Like I said it's an opinionated tool.
I'm deliberately I have rules inthere that might break things.
It's 90% okay, but 10% risk.
And I'm pretty sure Apple will neverdo things like that, but let a lot

(16:23):
of people like to use those things.
So I

What?
Let's say an example.

As I mentioned, because I'm not compiling your project
and I don't look at anything otherthan the file that I'm formatting.
I have to make certainassumptions and some of them
are like very safe assumptionsand some of them are less safe.
So some examples are, for exampleI remove self, like removing self.
Implicit self is a very common thing.
It's a rule that's on by default,but there are certain cases where

(16:48):
it's not actually safe to do.
One example would

closures anything with async away.
Yeah.

So it's auto closure specifically.
So closures, it's fine.
Like I can infer whether it's safeto do there and the rule is not dumb.
It works out everythingthat it possibly can.
So yeah, it knows that if you useself insider closure, it's because
you have to use self inside closure.
But if you've got an autoclosure at the call site, it
doesn't look any different.
Like it just looks likeyou're passing a parameter.
But the rule about requiringself is still there.

(17:14):
So the type system knows itself isneeded, but there is nothing in the
syntax to tell you that it's needed.
And because I don't often, I meanI potentially, if the function was
defined in the same file, I couldlook it up, but it, chances are
it's defined in a different file.
And so I have no way ofknowing what the type is there.
And so I just remove self anyway.
There's a mechanism where you can likeregister functions that, should have

(17:34):
self things like logging functionsare typically like where people use
this and some of the standard loggingstuff I've co coded in as being like,
oh yeah, this is, requires self, andthen you can add your own to that list
if you want to use the rule withouthaving to like, put exceptions at
every single place where you use it.
But it's things like that, right?
And so I don't anticipate that Apple'sSwift Format will ever have a self
removal tool because it's not actuallypossible for them to implement it

(17:57):
reliably using Swift Syntax, whichis the technology that they're using,

So just that, I was just looking at it.
So Apple has 2.5 or 2,500stars and you have almost 8,000
stars, so that's pretty good.
That's a pretty good indicationof where things are right now.
I guess it'd be interesting tosee how it changes over time.

Yeah, they, I think they probably got their 2000 stars
a lot quicker than I got my first 2000.
I suspect they're on a, likea sharper gradient than I am.
But yeah, we'll see.
We'll see how long beforethey intersect and overtake.

I think one of the good points you've made is the
thing about linting is consistency.
Like I, I'm a big fan of lintingbecause one of the things I wanna
look at when I go through my GIhistory is not white space changes.
whether somebo, somebody decided to gofrom tabs to spaces or spaces to tabs.
Like for me, if I can keep my codeas consistent as possible and just

(18:53):
insert changes that are specificallyfunctional as opposed to styling or
like formatting, then that's where likelinting is really takes a big advantage.
That, and I think just like stuff like.
Making sure you have comments andcertain, like documentation comments and
things like that are always helpful, butit's like always, that's why I'm a big
fan of linting and Swift formats, bothin Swift lint because I just wanna make

(19:17):
sure every time I put something in myrepo or I do a merger quest, it's always
gonna be consistent with what, whatever.
And it's clear to me when I look atthe history, I can see what changes
are actually functional changes

Yeah, absolutely.
I mean it's eliminates noise and italso eliminates like wasted time during
code reviews or whatever where it'sif you have a coding style, it would
be preferable if people didn't haveto like manually enforce that, oh no,
you didn't use like this, whatever.
So yeah, it's much better if there'sjust a tool that can do that for you.

Especially white space.
Yeah.
One of the things I like I don'tknow if your Swift Format does
it, but I know Swift Link does it.
It's really weird.
But like even the order of functions,I try to keep those consistent
and I know Ralph's tool, what the,what it'll do and I'm weird, but
like it'll tell me, oh, like youshould put properties first and it's
second and functions and so on last.

(20:08):
And that's really helpful to me.
'cause like I said, like then the white,like the white noise, the noise isn't
there because the function, it's likepurely functional changes whenever
I make commits to history and stuff.
And then that way everythingis properly formatted in the
correct order all the time.
But I'm like,

There is some support for that,
for a code organization.
It's again, it's opinionated becausethis was actually contributed by
Airbnb who are big contributors andactually sponsors of Swift Format.
So a lot of the rules, a lot ofthe rules in there are just this
is how Airbnb likes to do it, andif you like that, then turn it on.
But I, that's not on by default.
It's something where I guess I'm notactually that strongly opinionated about
the correct order for these things.

I am not opinionated about the correct
order, but I want it consistent.
I guess that's my thing.
It's it's not my preference to howI do it, but like at least it's
consistent every time and like thenthe deltas are just easier to read.

Nick Lockwood (guest): yeah, that makes sense. (21:01):
undefined
I think the the difference between SwiftFormat and maybe a tool like Prettier
is that it's not a complete format.
So I, it's Swift is just too complex.
There's just too much to havean opinion about everything.
I don't think there is a canonical wayto like format Swift code down to the
level of every character, so I do thebest I can, but it's generally like

(21:23):
making a bunch of surgical changes tothe code rather than just like taking
it down to the a ST and like fullyformatting everything from scratch.
And maybe that's a stretch goal.
Maybe one day we'll have that, butI have the feeling that it's not
really possible with Swift likethere's just too much variation in
the way that people like to do things.
And there's just too many thingswhere it's just really not clear

(21:43):
what the right approach is there.
But as much as possible.
Yeah, I completely agree with you.
It's preferable if there'sjust one agreed upon way to
do things in a code base.
Maybe not universally, but in anygiven code base, it's better just
not to have to think about that.

Exactly 100%.
So one of the things I wanted to talkabout with you is we've talked about
it, and this has especially been thecase over the last year since five,
I'd say like maybe five to five, fiveto six, or five to five five once we
started introducing Async a await.
And some of the stuff with like types,some in any and all that kind of stuff,

(22:17):
it's there's a lot of challenges thatwould seem for a newcomer to be able
to pick up Swift now that there's a lotof these new pieces that we've added.
Um, what have you seen?
I don't know how many new employeesor new software developers you've
run into, but as far as learningSwift as the programming language
has changed and like how thedesign of the language has changed.

You mean in terms of being accessible to beginners?
Yes.

Yes.
Yeah, exactly.

It's a really good question and it's one that I'm.
I feel like I'm not really qualified toanswer because I I grew up with Swift,
like I was there from the beginning.
And so a lot of the things that it doesthat are weird, I feel like I don't
notice because, I, it's just always beenthat way and you get acclimatized to it.
My feeling is, I mean like Swift's boldclaim is that because of this principle

(23:05):
of progressive disclosure, it's an easylanguage to learn and, maybe harder to
master, but it's, you should be able tolike just dive straight in, not worry
about the things you don't need toworry about yet, write basic code and it
should be simple and easy to understand.
And I think there is alot of truth in that.
People keep saying, oh,Swift's the new c plus.
It's got all these complicated,weird features in it.
It's but okay, yeah, sure, buthow often do you actually run into

(23:27):
those things in your day to day?
Have you ever seen, consumable orwhatever have you ever encountered
these keywords in code that youdidn't like deliberately put it there?
It's just not it's not at theforefront of the language, right?
It's not like the first thingyou encounter when you're
trying to write Hello world.
You don't have to worry about whetherlike your variable is being consumed
or not, or whether it's async.
You don't hit these things.
So I do think that the language is quiteapproachable and you have things like

(23:50):
Swift playgrounds where, maybe if thesort of editor was a little bit more
stable, I think it would actually bequite easy for, novice programmers to
It's, it, I, the languageis it's just simple looking.
It's deceptive.
It's not actually thatsimple, but it looks simple.
And for doing simple things,I think it is pretty simple.
The fact that it keeps memory managementand stuff out of the way and so on.
I think there is a danger to thesort of veneer of simplicity that,

(24:14):
particularly with SwiftUI, I thinkSwiftUI enters into the realm of
being so much more complicated thanit actually looks, that it's very
easy to shoot yourself in the foot.
Even as a, I'd like to thinkexperienced developer, I often find
with SwiftUI that I, I'll make someminor typo or something and I'll
be sitting there for 10 minutesthinking, why isn't this running?

(24:37):
And I'll realize that I've donesomething that has just hung the
compiler because it like the typeconfusion that I've given it is
so great that it has no idea howto even tell me what was wrong.
And like things like that are realsharp edges because, I have no idea
what a person who's not confident aboutcoding would do in that situation.
'cause what, most of the time what Ihave to do is just like undo back to the
last stable point because the chances ofme being able to diagnose, the missing

(24:59):
bracket in like a, a hundred lineSwift, SwiftUI body is basically zero.
It just it feel things like thatreally feel like maybe they've
gone a little bit too fast.
Like they've added functionalitywithout the sort of debugging story
really being able to keep up with it.
Things like async await don'tbother me particularly, but again,
now that they've introduced allthe, like the strict concurrency.

(25:22):
We're getting into stuff whereI'm seeing very experienced
programmers throwing up theirhands and going, okay, I just don't
know what I'm supposed to do here.
I just I tried to turn on likestrict concurrency and it just
yeah, I just had to give up.
And that doesn't seem good.
If experienced programmersare having this issue, I've no
idea what a sort of novice issupposed to do in this situation.
Obviously what they're supposed to dois not turn on strict concurrency, but

(25:42):
if this is the future of the language,at some point, presumably we'll get to
a point where it's not optional anymoreand everybody's expected to have it.
I don't, I dunno what happens then.

So I think a lot of it, like the stuff
you're talking about is SwiftUI.
What I've found is typeinference kind of gets in the
way of getting things to work.
Because it will just, it willtry, it's hardest to figure
out what you're doing and thinkthat you're doing it correctly.
Like I had an instance where I wasadding like a toolbar button or
something and it was like I changed,all I did is change a method.

(26:12):
So then the method call was invalid,but I didn't realize that, and it was
like obviously giving me an error,like that's misleading, which is
what happens with us 90% of the time.
It's like I did, definitely didsomething wrong with the error was like
a red herring because it was tryingto do type inference and thinking, oh,
like the SwiftUI view is incorrect.
And it's no, the type SwiftUIview is perfectly fine.

(26:34):
It's some function I was callingthat doesn't exist, but it like
took me, like you said, I had todo und undo do and figure it out.
But yeah, that's.

Swift strong typing is such a useful tool.
Like when you are coding alongand you change, you change the
signature of a method and it justtells you everywhere, oh, hey, you
need to add this extra parameter.
You learn to rely on that so muchwhen you're coding and then, yeah,
in the middle of a SwiftUI body.
Doing that means that insteadof it saying, oh, hey,
you missed this parameter.
Instead it's going wait, I haveno idea what this thing is.
I have no idea whatany of this thing is.

(27:04):
It.
You've got this kind of like explosionof type inference failure, where it goes
from like fully understanding everythingto understanding nothing at all, and
just not being able to help in any way.
It can't even tell you where theerror was because it doesn't even
know what it's dealing with anymore.

That's where they should invest in ai.
I.
Like Xcode error messages.
I know GitHub has a thinglately where it's explain error
using a copilot or something.
And I'm like, that's 'cause I'vebeen using the latest Mac OS
and LA the latest Objective-C.
So I've been using the new co codecompletion stuff in Xcode and been okay.

(27:38):
But like that to me is like, whereyou should be investing is like error
handling and like knowing the propererror that is actually going on based
on the like millions of developerswho run into this all the time.

Yeah, I'm a little skeptical of these technologies.
Like I haven't used co-pilot in anger.
I'll admit.
But the problem, the problemwith this sort of the
hallucination effect is like,

Oh, and it's very strong with SwiftUI, right?
Because is fairly new,

exactly.
This is the problem, right?
So like, when it's a wellestablished problem, sure,
it'll give you a great answer.
And like it's, it can be amazingly,like good at explaining things, but
if you are like, the second or thirdperson to ever have encountered
this problem, if only it couldjust say sorry, dude, I don't know.
But

No, you never.

a, yeah, it'll be a very cogent, very coherent
explanation that is total nonsense.
And then again, like for thenovice developer who's like
relying on this to tell them whatto do it's just making it worse,

there's just so little test data out there that it's been
trained on and it's like you try to pullup like bash scripts and it's amazing.
You're trying to pull upSwiftUI, a sink await stuff.
Yeah.
You're screwed.
The one tip I would have, so a coupleof tips I would have is a break
your SwiftUI stuff into smallerpieces and B like actually say what

(28:49):
type things are be very explicit.
'cause that's a good way ofseeing, 'cause that's what it is.
It's like when you start doingthe type inference, it like.
It could, it tries.
Its very best.
But once you start being veryexplicit about what each type is
you do colon int or colon, whatever,fu every single place you can.
That's a good way to findout what the actual error is.

(29:09):
And then it doesn't have to try,its hardest to do type inference.

yeah, absolutely.
I think this is, it is aproblem with the language.
There's no two ways about it.
I really like type inference.
I like the aesthetics of type inference.
Like it makes it nicer to writethe code, but I just don't think
they should let you infer typesin situations where the compiler
can't deal with it like this.
The rules have clearlybeen made too lenient.
The tools are not capable ofsupporting the level of like type

(29:36):
inference that they're offering us.
And, if they had just been a littlebit stricter about this and just
said, look, you have to specifythe type here, we could work it
out, but the trade off is not

Or just like it, all you have to do is in the IDE,
just put something in that says.
Explicit type and then youjust have to fill in the little
template thing and like now youat least are heading somewhere.

Yeah,

yeah, the part of the

definitely be solved with tooling.

part of the problem is when Swift was introduced,
people were pissed about how muchlike types don't just like work
like they did in an Objective-C.
So I think, I feel like it's apart of that is the fact that
like in Objective-C, it didn'tmatter if you used an INT or
double or a whatever type.
It just could do the point orconversion for you automatically.

(30:22):
And like people were pissed that like inSwift you have to be very explicit about
converting your number or your stringor whatever it is into the right type.
You know what I mean?

I, I think part of the problem with Swift's type
system is that like most of the timeit's great, it's really easy, simple
to understand a string is a string,a number is a number or whatever, but
you do get these weird cases where ifyou're doing something like, I dunno,
some functional programming where you'redoing like a lazy map of something.
Have you ever looked at those types?
They're insane.
Like the, the type will be likesome like it'll be like a hundred

(30:52):
characters worth of type with likemultiple nested generics in it.
There's no way you're gonna type that.
No

that's where some, some kind of tries to do that.

Yeah.
It's some solves part of that problem,but I think it only, this is, it's
actually something I always bump into.
It's oh, I've got this horribletype, I'll use some, oh wait, that
only works for protocols, right?
It only works for some protocol, itdoesn't work for some like generic type.
So Yeah, unfortunately that's not, it'snot a, it's not a complete solution.
But yeah, this is the thing like, withstrong types comes like ludicrous types.

(31:20):
And when you've, if you look at theact, the actual types of, SwiftUI
bodies with something that's got 10 subviews in it or whatever, like there's
no possible way they can expect you

does it do the refactor.
Do the refactor inObjective-C and Objective-C.
Like actually literally types out thetype and you're like, dude, come on.
Just do

I'm not putting that in my code
so yeah, I don't, I dunnowhat the right solution is.
I have some theories about it, butwe could probably talk about language
design forever, but I generally, Iprefer the sort of type script approach
where it's you, the typing is optional.
So like maybe, during development youjust don't need the types and then maybe
at production time you put them in.
Whereas Swift's approaches, youalways have to have the types and it

(32:00):
tries to make it easier by doing typeinference, but it, you end up with
the worst of both worlds in some waysbecause it means you're having to think
about types during your developmentprocess when you don't want to.
And then also you are leaving outtype information, which then has
to be inferred in your, like finalbuild, which means your compiles will
be forever slower just because youdidn't type in the type, so I don't
think it's necessarily the right tradeoff the way that they've done it.

(32:22):
I, I do I know enough abouthow it works to understand like
there are good reasons why itworks the way that it works.
But it as a developmentexperience, it's maybe not optimal.

Did you have any other comments about
programming language design whenit comes to any of the new stuff?

I think Swift is now feeling its age in terms of
like when you set out to design alanguage, it's all truth and beauty
and everything's terribly elegant.
And there's some things about Swiftthat are so beautiful, like the way that
they handled, mutability with struts andcopy and write and everything like that.
It's so seamless and so lovely.
And I, there's no other languageI've ever seen that handles this

(32:57):
whole mutable struts thing, the waythat Swift handles it, so elegantly
where, if the SRUs are var thenall its properties are var, like
this kind of thing is really nice.
Like I looked into Kotlin, which is likesuperficially very similar to Swift, and
it's nothing like as nice, like the waythey have to like, make mutable copies
of all of their arrays everywhere.
It's just not in the same league.
But then I first started seeing likethe cracks appearing in Swift when

(33:20):
they had this thing with slices,like array slices and substrings.
Whereas you, you remember theymade this change originally.
Like a string was a string, andthen they were like actually
there's a difference between astring and a string slice and we're
gonna have to make this explicit.
And it was like thisdoesn't feel nice anymore.
Like I, I get a range of a stringand then I try and assign it to a
string and it's not the same typeand I have to explicitly cast it.

(33:41):
And I find, felt it was alittle bit downhill from there.
So yeah, it's like Ialmost feel Swift is.
Is it's over a decade old now.
Like maybe it's time forSwift two where they can reset
everything and do it all nicely.
Of course they won't.
You know, there's no possibility.
But we, it does feel now a littlebit like, it's not the shiny
new beautiful language anymore.
It's acquiring craft thatcan't ever really be removed.

(34:01):
And it's sad, it'sinevitable, but it's sad.
It would be nice if some of the kindof early mistakes could be rectified
in a way that, didn't require themto maintain source compatibility.
But I, I

Were you the one who had the talk about why
strings don't have indexes?
Like just a simple index for character?

Yes.
That was also me.

well obviously put that your talk, but like
that was really interesting.
Do, do you think it's a good argumentto not have indexes because because
it makes it look easier than it is,

That was essentially my argument.
So it does have indexes, but the indexesaren't integer indexes basically.
And the reason for that is becausecomputing, the difference between
indexes is a bigger o operation.
So basically the longerthe distance, the longer it

Do you think that's a good thing in API design
to be explicit about, Hey, we'regonna make this look awful because
it actually is awful underneath.

Nick Lockwood (guest): It's a compromise for sure. (34:55):
undefined
So the, to turn that around, it isa very bad thing to have attractive
nuisances in your API design.
Like you do not want to have anAPI that looks like it's simple and
straightforward and will be quickand is actually like a foot gun.
So I think they're right to avoid that.
I think it would've been nice if theyhad put more effort into making it.

(35:18):
Easy to do the thing that you wantto do and making it clear how to
do the thing that you want to do.
Because I think the problem with theSwift string design, API design is there
is probably a right way of doing things.
It's different from the C way, whichis arguably the obvious way, and
it's not very clearly signpostedlike what you're supposed to do.
So what people re people reach forinter indexes, they don't find them.

(35:41):
So then they try and work withthe indexes that there are and
they're horrible to work with.
And then they're like, this is horrible.
And what should they should actually bedoing is something completely different,
but it's not easy to find the thingthat they should be doing instead,
it's like not an obvious refactorfrom the code that they started with.
So maybe more work could be done there.

Yeah, totally.
I get where you're coming from.
Swift feeling its age.
Async await was always thelast thing it had to do.
Do you feel like there's more thatthey need to add to the language that

Yeah, it's not even apple is quite
happy to tell you like the thingsthat, that they're missing.
So there's this thing I can'tremember what it's called now with
generics basically like the genericstory is not complete in Swift yet.
So there's certain kinds ofgeneric coding that you can't do.
They've made a lot of progressthere with I think there's, uh.
Parameter packs and generic parameterpacks and so on, but it's still not

parameter, brat packs are broken, by the way.
Like I, yeah, I try to do some fancystuff with parameter packs and it's
like an actual bug in Swift, so yeah.
You can only get so far with

features, yeah, so there's a lot of stuff around that.
And I think, again, this comesback to my point before about how
I prefer the TypeScript approach.
So with Objective-C and withTypeScript, there's a bunch of things
that the type system can't reallyrepresent, but you can still do them.
It just lets you do it.
It just can't really staticallyenforce that you've done it.
So it's basically the failure mode in

Are you suggesting we should just have any for everything?
Just put any and

No, not at all.

Okay.
Okay.

What I am saying is that in Objective-C,
you can do that, right?
And it doesn't hassle you and it doesn'tforce you to put typecasting everywhere.
It basically just says, if you're gonnause ID for every type, I can't help you.
Like the stat, thecompiler cannot help you.
You will fail at runtime.
That's on you.
But I like to have that as aget out, as an escape patch.
Right Now with Swift you can'tdo that because the semantics

(37:29):
of any are not the same.
So you, of course you can use any forevery variable type, but you will have
to cast it to the thing you want itto be everywhere you pass it, right?
With objectives here, itworks the other way round.
It says, ID means turnoff type checking.
Just let it go, catch it at runtime.
And I think that's a nice balancebecause it means that you can
write like anything that can bestatically type checked, you are
welcome to statically type check.

(37:50):
Anything that can't be staticallytype checked because the type
system isn't sophisticated enough.
You can have a go if youknow what you're doing.
It'll work.
In Swift, if the type systemcan't represent it, you
are not allowed to do it.
There are perfectly valid programsthat Swift will not let you write
because its type system is notsophisticated enough to handle that yet.
One day it might be sophisticatedenough, but right now it isn't.
And that means that we are basically,we're limited in what we can do with

(38:13):
the language until the, compilerdevelopers have figured out a way
of representing this, which is the

I know what

approach.

I think I know what you're talking about, but do you have
a specific like instance of somethingyou can't do in Swift because of this?

So something that you now can do, but for a long time
you couldn't is if you had a a protocolwith associated Types, A PAT, you
couldn't have an array of those, right?
You couldn't have an array of likeequatable for example, or codeable
because there was no way of sayingthis thing conforms to a protocol
and here's an array of thingsthat conforms to this protocol.

And you're talking about an array of different e

Like he hetero, heterogeneous,

right?
Heterogeneous and that'swhat ne tries to do,

so any has solved this problem but it, we had
to wait a long time for any, right?
Any wasn't until some lateversion of so a decade.
So for a decade we couldn't do that.
We couldn't have an array of, andso you had this weird compromise.
It's I'd really to add an associatedtype to this protocol, but if I do
that, it's gonna break all of my code.
And there is no way around it.
The only way around it wouldbe to use any literally
any for the array of types.

(39:18):
And then you are into like totallyun type checked like weeds, right?
So this is my point in, in somethinglike TypeScript, you'd be able
to do this and it would be finebecause it would just, the type
checking would just check asmuch as it could and no further.
And that's okay.
And it, and, protocols and Objective-Cwork in a similar sorry, not protocols.
Generics in Objective-Cwork in a similar way.
They'll check what they can checkand if they can't check, it's fine.

(39:38):
Just do it anyway.
And I, that, that's what I'msaying like is maybe more optimal
from a developer experience like.
The type system in Swift often if youtry and do something like this, you can
spend a lot of time like scratching yourhead saying, how can I represent this?
Is there some way that I can trick thetype system into letting me do this?
I know it's legitimate, I know whatI'm doing, but it just won't let
me do it because I can't explain tothe compiler what I'm trying to do.

(40:00):
And like sometimes you just realizethere's no way of doing it, and
you just have to give up and comeup with a different approach.

I think macros tries to do that where it basically
will create the type for youthat you're trying to create.
You can kinda get away with it withmacros, but of course macros are a
pain in the butt, so that's not easy.

Yeah.
Yeah.
I, again, macros were a thingthat I think I wanted in Swift
for a long time, and then whenthey finally came, like it wasn't,
that wasn't really what I wanted.
It's thank thanks, I hate it.

Thanks, I hate it.

Nick Lockwood (guest): yeah, like I I think, sorry. (40:31):
undefined
No, you carry on.

I was just gonna say I was gonna, have you looked
at like type throws at all?

I, I have, and type throws again is something
that I've wanted for a long time.
And

So the one big limitation I've run into is ros.
It doesn't know how to do ros.
And that makes them like I try touse them now wherever I can, but
anytime I have to do like a, I wantto do a re throw, then it's like
you can't do type throws anymore.

Nick Lockwood (guest): that's interesting. (41:00):
undefined
I thought that there was, becauseI, the ros keyword I think is now
deprecated because supposedly typethrows had a better solution for this.
But off the top of my head,I can't remember what that
solution was supposed to be.
But I thought you weresupposed to be able to do that.

Okay.
Okay.
Yeah.
Once you do a ery throw it like,doesn't it just basically you
lose the type, essentially, and it

So I think what you're supposed to do is make the.
Calling function generic on the throwingfunctions throws or something like that.
I could look it up, but I can't tellyou off the top of my head if you
look in the original Swift evolutionproposal for typed throws, I think
this is covered specifically as a case.
The, but the bigger problem I hadwith typed throws, which comes
down to another like languagefeature that I dearly wish that

(41:41):
Swift would have, but that the likemaintainers are like absolutely like
dead set against ever adding this.
And probably it will never happen.
But basically, so you have thissituation where you've got,
a function which throws twodifferent types of error, right?
So you need the, if you want tomaintain type throws the outer
function has to throw like aunion of those two error types.

(42:02):
It could be one or the other.
And there's not really a good wayof doing this in Swift TypeScript.
Again, I know I keep talking aboutType, I don't even use TypeScript.
I I'm like a fan from a distance,

Are you a fan of TypeScript?
Do you think It's better than Swift?

So I don't, for many reasons it's not better than
Swift, and I don't, I'm not a heavyenough user to actually judge whether
it's better in any way, really.
But there are things I likeabout, like the design of the
type system in particular.
And the thing that I like most is theway that they've handled type unions.
So in Swift, we have enums and Enums canbe used as a kind of type union because

(42:39):
you can have different cases can havedifferent associated like values of
different types in them, but it, that'snot the right tool for a situation
where you've got function like A throwserror type A and function B throws error
type B, and so function C that wrapsthose needs to throw error type A or B,
You'd have to create like a new typeof error, which was an enum that can
wrap A or B, and then you'd have todo all the wrapping yourself manually.

(43:02):
And it's a, it's like a loadof like extra boilerplate.
And it's a horrible way of doing

I think you're wrong.
I think you're wrong.
I think you should write a macrothat creates the enum for you,
and then you could refer to thatenum that's created by the macro.
I think that's whatyou should be working

we, we can debate what the right way
of doing this in Swift is giventhe constraints of Swift as the

I am being totally sarcastic though,

But the the way that Typescripts would do this is
you just say that this throws A or B,

right?

Is the obvious right way of doing it.
And that way of doing type unionsis it's useful in many contexts.
Like another place where Swift's typesystem totally lets you down is Jason.
So like when you pauseJason, it gives you a

Yeah, that's a big one.

any anything in that dictionary can be like, it
can be a number, it can be a string,it can be like a Boolean, whatever.
Like it could be an arrayof any of those things.
And what type does Swift give you?
It gives you any, because there is noway of representing that type in Swift.
And the obvious way you would representit would be a type which is a union of
int or string or a number or whatever.
And that could be strongly typed.
It would only let you use those types.

(44:02):
You couldn't throw I dunno, an

That's

Nick Lockwood (guest): there and expect it to work. (44:04):
undefined

They would tell you that's what enums are for, right?
They're like enumerations andthey're unions in a lot of

sure.
But they didn't use Enums.
Why didn't they use an enum?
Because it, the ergonomicsthat are horrible for that.
That's why they didn't, it's notactually the right tool for that job.
And so claiming that it is, butthen not using it for that job is

you need

on themselves.

You need like a computed enum, right?
That's the way you get around it orjust or I know I was being sarcastic,
but they should just have a builtin macro that does that for you

Yeah.
And may, maybe that's theapproach they'll eventually
take with this because theydon't want to add type unions.
But I wish they'd just add type unions.
Like it would, it, wouldit would be so nice.
But yeah, the, this isthe strength of type.
It's not so much like they'renice in the Jason Case, but
that's not the killer case.
The killer case is where youare composing these unions, like
on the fly for cases like errorhandling, where you don't wanna
have to define them all in advance.

(44:52):
So yeah that's the one kind oflike thorn in type throws for me.
And this was actually part of thejustification for why they didn't
have type throws originally was like,this was one of the reasons, it was
like, pretty soon if you are throwing,like you are gonna lose track of what
the type is actually supposed to be.
And you don't want to have to like,change the types throughout your whole
system just because you've added likean extra case somewhere deep in it.
So they've added type throws,but they've not fixed the

(45:14):
reason why they didn't havetype throws in the first place.
And I do feel like this, thissolution is like just sitting
there ready to be like implemented,but they're not gonna do it.

I'm glad we have type throws than not having type throws, even

Absolutely.
It was a huge, I mean it was

you had to do a reason result every time, and I hated it.
And it's

I was quite like, I was like an avid follower
of the evolution proposal forresult when it was originally added.
And this was one of thekiller use cases for it.
Like the other one, which is nowobsolete, was because like at the
time we didn't have async await.
So you were using closure callbacksfor handling maybe a network response
and you really wanted it to giveyou a result, not like an optional
error and optional data or whatever,which was a horrible ergonomic thing.

(45:53):
So they, results solved that problem.
But it also did give us like a glimpseat what a world where type throws
was possible would be like, becauseit gave us strongly typed errors

Have you done anything with non copyable?
Have you dabbled into it at all?

I, it doesn't feel like a tool that
is, much consumable and borrowingand all of these kind of things.
It's not something Ireach for very often.
Like I, I think it definitely it willhave a lot of interesting use cases,
but probably they'll mostly be inlike fairly low level library code.
I don't think it's somethingyou're gonna use much in an app.

(46:27):
I've seen

My, my gut feeling is that it's it's a way of, I, I
think you've hit it right on the nose.
I think it's basically like filesstuff that, like literally you don't,

Is a clear case.
Yeah.
The point is

you think they wanna get

using once.

do you think they wanna get rid of classes in a way?

This is an interesting question.
No, so

And what I mean by that is like either it has to be, it
has to be threat safe and be an actor,or it has to be, it has to be obstruct.
And if it has to be obstructand it can't be copied,
then make it non copyable.
Do you know what I mean?

Yeah, for sure.
Classes are a bit of a weirdthing in Swift because they,
again they cover many differentroles that sort of don't feel like
they should be coupled together.
Like one of the reasons classes existis because Objective-C compatibility was

Right.
100%.

So if you take that away, it's does
the language need classes?
It almost feels like I, I tried, Ialways feel like I'm letting myself
down when I have to use a class.
It's always it's the last choice, right?
Your first choice isa structure in Enum.
And if you have to use a class,fine, you'll user a class, but
you're not gonna feel good about it.
And the thing is though, thatthere's no such thing as like a ref.
There's no naked reference in Swift.

(47:43):
We've got like in-out for passingby reference to a function.
But you can't just havean in-out property, right?
So sometimes, if you've got somethinglike a linked list or something like
that and you need a back reference,like you have to use a class,
there's no other way of doing it.
And I often run into these situationswhere it's really frustrating because
the tooling around struts is sonice and the tooling around classes
is like so poor by comparison.

(48:03):
Like I've my, my model is like astruct and it's like self serializable,
self codeable, self equatable.
Like all of that synthesized for me.
My, my initializer issynthesized for me.
And then I suddenly realizethat I need to be able to like.
Have a shared reference to this.
So like my view model can mutatethe shared model or whatever, and
it's wait, if I turn this intoa class, it ruins everything.

(48:23):
Like now I have to write my,my, my equatable implementation.
I have to write.
Like all of this has to be donemanually and it's horrible.
And probably the nicest solutionis to wrap the struct in a class
and just have the property exposed.
But then you've got this weird APIwhere like you've got this level
of nesting that you don't want.
And what I really want is thelanguage to just let me say buy ref
my struct or something like that.
But it doesn't let you do it.
Maybe they want to get rid ofclasses, but like they, there's a

(48:46):
long way to go before we can, I think,

Oh, for sure.
I think the backwards compatibilityis a big part of that story.

but e even setting that aside, like there is no
alternative like for when you haveto have, when you really have to have
shared mutable state or whatever.
There is no alternativeright now in the language.
And sometimes you do unfortunately,and I think again with SwiftUI and
stuff and publishers and all thesekind of things, like if anything,
the usage for that has gone up.
Swift data is all about classes.
They're not getting rid of them.
If anything, they're doublingdown on use cases for them.

Yeah.
enough.
Have you seen this recentproposal for vectors?

I have, yes.
Long overdue.
I have

Tell me the story behind, tell me the story behind
it, and first of all, how pissedyou are, that it's called Vector
when you're into 3D Graphics.

Yeah.
Fair.
Okay, so there's a fewdifferent things there.
So first of all, what is it?
Basically it's, it givesyou a fixed size arrays.
So there is no way of doing fixedsize arrays in Swift right now, if
you import a fixed size array fromC because in C, all arrays are fixed
size effectively, unless they liveon unless it's a pointer to an array.
It gives you a topple, which is a,like a crazy thing because you can't

(49:51):
do anything with a topple, right?
You can't index it.
You can't get the nth item.
You can, you

Like UU IDs, like UUID.
The UUID type underneath is a coupleof 16 bytes and it's like, why?
Why would you do that?
Yeah.

So it's a horrible thing and it's long
overdue for them to solve this.
It was the absolute bare minimum.
Oh, what's the closest typewe can map this to in Swift?
I guess we'll use a topple.
And then they never came back to it.
So yeah, it's basically useless.
If you're trying to work withC APIs that actually give you
fixed size arrays, it's hopeless.
So Vector is like the correct typefor this now, and it required them
to do some infrastructure stuff.
I can't remember what it was now.

(50:25):
But they had to, there were somepieces missing before they could
implement this, but when they addedthose pieces, like they even said
at the time we are basically doingthis because now we can have fixed
size arrays and now we have them.
So the name is an interesting choice.
Like as you mentioned I'm a 3Dgraphics person, so like you, you
might think that I was annoyedby the name, but actually I
think I'm okay with it becausein fact it is literally a vector.

(50:47):
If you have a fixed size array oflike doubles or something like.
That is the type you would wantto use for a 3D graphics vector.
You'd want a, an array of,three doubles or whatever.
And Vector is the perfect name for it.
It would probably an, it wouldprobably annoy me because then,
now what do I call my type?
But, we always have this issue in Swift.
But no, the people it really pissesoff are the c plus developers,

'cause it's the

were, yeah, because it's a, now array means
vector and vector means array.
It's like a per, it's likeperfectly, like the wrong way
around as far as they're concerned.
And I sympathize

what was it?
What was somebody, it was likelist, Swifty, I list joints, the
chat, because that's what the,that's just even more confusing.
So I think I saw the big usecase is essentially for what do
you call it, for embedded Swiftbecause of the memory constraints.

That's true.
But generally any high performancecode, and particularly like stuff
like graphics code is gonna be like,excited about having this feature.
Because the big problem with Swiftfor performance, like writing
performant code in Swift andembedded code is performant code
almost by definition because it'susually very resource constrained.
So the big problem with Swift is itloves to allocate without telling you.
There's no way to say, don't allocate,please don't put stuff on the heap.

(51:54):
It just, it'll

It's the same thing with actors and threads, right?
It's like you have no clue.
It abstracts all that away from you,

Yeah, exactly.
It's, there's a lot of abstractiongoing on and it's really hard to get
Swift not to allocate there's a lot ofthings which don't require allocation
in c where there is no way, or there'scertainly, it's certainly no idiomatic
way of doing it in Swift withoutinvolving heap allocations and arrays.
Were one of the big ones.

And so a vector is ave a vector.
I hate, I have to use thisterm, A vector is mutable, but
you cannot change the size.
Is that correct?

That's correct.
Yes.
I think the mutability is likestruck, like it's opt-in mutability.
It also has like

That's what I

ability and all of these things, right?

But basically like you can change the values,
but you can't change the size,

Yeah.
So it's like an, it's like anarray in every sense except that
it's, yeah, the size is fixed.
But it, it has the samevalue semantics as an array.
Like you can pass it around, youcan make it immutable or mutable.

So Aday, who had a really great talk at Surfside Swift,
um, he had a question on Twitter aboutmacros that I want to close out with.
Just he wanted to know ifthere was, there would be any
macro you would wanna build.

I would reference Daniel Steinberg's very excellent.
Talk on this subject, whichis macros are not for you.
Like they, they, macros arethey're for apple to build like
infrastructure more easily.
That's how I see them.
The fact that we are able towrite our own macros is a sort
of accident of the, design of theSwift language that they wanted to
make sure that the standard libraryin Swift is all written in Swift.

(53:29):
It's all dogfooding itself.
There's no magic secret behaviorgoing on behind the scenes
or as little as possible.
As much as possible.
They want like the language runtime andeverything to be written in the language
using standard language features andmacros are another piece of that.
Macros allow them to implement, specialfunctions and useful things using
like a standard built in feature ofthe language without having to go

(53:49):
in and edit the c plus code of thecompiler, which I think they probably
hate doing as much as we would, butI don't think macros are intended.
You shouldn't be writing likea bunch of macros in your app.
Like your app shouldn't definelike 10 new macros and write
a bunch of code using macros.
You are, it's just a wayof obfuscating your code.
It's the same withcustom operators, right?
Like when, when Swift came out, it'soh, you can write your own operators and

(54:10):
everybody's writing loads of operatorsand no sensible code base does that
really maybe it'll have one, or maybeyou'll define a plus operator that
also works on vectors or whatever.
But like creating loads of custom macrosis just a way of obfuscating your code.
And I think it's the same with macrosand, unlike custom operators or property
wrappers or any of these other things,macros also come with a huge overhead in
terms of just compile time and the, justthe general effort of building them.

(54:33):
Which is why I don't, they're nota tool that I would reach for.
It would be very much the last resort.
Like I'd probably even go to likethird party code gen tools like
sorcery before I would use a macrobecause they're that on ergonomic
to use like in an actual code base.

Yeah.
No, I totally get whereyou're coming from.
100%.
Was there anything elseyou wanna talk about?
Did it was what did you wanna mentionabout 3D Graphics before we close out?

I dunno if I had anything in particular that
I wanted to talk about with that.
It's just it's an areaof interest for me.
So it's if it's something you wantedto chat about, like that's a thing
I can chat about, but I, I don'tknow that I necessarily, I noticed
you mentioned like the vision pro.
I don't have strong opinions about that.
There's some interesting stuff about thefact that they've basically killed scene
kit now, but I dunno if that's worth the

we'll have to have you on again to talk about it once you spend
the, was it $3,000 on a vision pro or,I don't even know how much they are now.
Is it

It, I think it's at least that, like they're
expensive, but I guess there'llbe like, maybe there'll be like
a vision pro mini for people withsmall heads and lower budgets.

Heads and lower budgets.
The woman's size.
Like the watch bands.
Nick, we'll have to haveyou on to talk about that.
Thank you so much for coming.
This has been fantastic.
I'm really glad we finally got you on.

Nick Lockwood (guest): Yeah, I really enjoyed it. (55:47):
undefined
Thanks for having me again.

Where could people find you online?

So I have a presence on Twitter or x as
we're supposed to call it now,but I tend not to hang out there.
I'm mostly on mastered on these days.
I think that's thebest place to find me.
Or, if you want to talk about myGitHub projects, then probably
GitHub is the logical placeto start that conversation.

We will put links to that in their show notes.
Thank you again, Nick.
It's fantastic.
People can find me on Twitter atLeo g Dion ma Sadan at Leo gd at c
Im bright digit.com is my company.
If you are interested in comingon the show or you are looking
for help with anything, justfeel free to reach out to me.

(56:26):
If you're watching this onYouTube, please and subscribe,
post a review in your podcast app.
Thank you everybody.
I look forward to talking to you again.
Bye.

All Episodes

Episode Transcript

Popular Podcasts

On Purpose with Jay Shetty

Crime Junkie

Ridiculous History

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Ludicrous Types with Nick Lockwood

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}On Purpose with Jay Shetty

Crime Junkie

Ridiculous History

All Episodes

Ludicrous Types with Nick Lockwood

On Purpose with Jay Shetty