ATP Interview: Holly Borla & Ben Cohen
John:
All right.
John:
How are we starting this?
John:
You're starting it.
John:
I'm starting it.
John:
Okay.
John:
You're the host, man.
John:
All right.
John:
Well, here we go.
John:
All right.
John:
So, hey, everybody.
John:
We're doing something extremely special today, and I am genuinely exceedingly excited about it.
John:
And so I teased last episode that we would have a little surprise coming up and a little treat is, I think, what I called it.
John:
And it's actually more than a little treat.
John:
It's a big treat.
John:
So today we have a special guest, but not one special guest.
John:
We have two special guests.
John:
So here we have today Ben Cohen, who is Senior Software Engineering Manager for the Swift team, and Holly Borla, the Swift Language Engineering Manager.
John:
We are in the presence of greatness.
John:
And I don't know how we ended up here, but I'm happy about it.
John:
So thank you, Ben and Holly, for being here.
John:
I know I speak for all three of us in saying we are extremely excited and lucky.
John:
So thank you.
NEW_SPEAKER_SPEAKER_01:
Thank you very much for having us on.
John:
Of course.
NEW_SPEAKER_SPEAKER_01:
I do interviewees very often, so...
John:
Well, and actually just this morning I was watching your video, which was very good, and we'll talk about that.
John:
But I guess, Holly, if you don't mind, if you wouldn't mind starting, would you give me the nickel tour of who you are and what you do?
John:
I mean, I know, but not everyone knows.
John:
So who are you and what do you do for Apple?
NEW_SPEAKER_SPEAKER_00:
Sure, yeah.
NEW_SPEAKER_SPEAKER_00:
My name's Holly.
NEW_SPEAKER_SPEAKER_00:
I'm the engineering manager of the Swift language team, like you.
NEW_SPEAKER_SPEAKER_00:
like you just said.
NEW_SPEAKER_SPEAKER_00:
My team focuses a lot on the user-facing language features like the generic system, type inference, and this year our major focus has been the concurrency model and specifically data array safety in Swift 6.
NEW_SPEAKER_SPEAKER_00:
Before I joined the Swift team, I was a Swift programmer working on Xcode, and before that I was a computer science student at the University of Michigan.
John:
That's incredible.
John:
And Ben?
NEW_SPEAKER_SPEAKER_01:
Yeah, so my name is Ben Cohen, and I manage the Swift team overall.
NEW_SPEAKER_SPEAKER_01:
So that includes the language, but also the backend, the optimizer, a lot of the tooling that goes around the language, like code completion and things like that.
NEW_SPEAKER_SPEAKER_01:
At Apple, about eight years, I've worked on various parts of the Swift compiler, including the standard library, the optimizer.
NEW_SPEAKER_SPEAKER_01:
And before that, I was not a compiler engineer.
NEW_SPEAKER_SPEAKER_01:
So I was actually working in sort of fintech type stuff.
Yeah.
John:
So, you know, I'm going to really make John happy, and I'm going to jump right to the end.
John:
We're not doing follow-up, then.
John:
No, we're not doing follow-up this time.
John:
Well, I guess a real-time follow-up.
John:
How did you end up, and I'm asking both of you, but Ben, since you most recently spoke, we'll start with you.
John:
How do you end up being a compiler engineer?
John:
Because my perspective as a Swift developer is there's people like me who kind of know what we're doing, and then there's compiler engineers who really know what they're doing.
John:
It's like a priesthood where...
John:
You're a programmer and you write the thing, but then if there's something wrong with the compiler, you're like, that's not my fault.
John:
There are people in an ivory tower somewhere that make this work, and they're crossing over that path.
John:
I know there's lots of advertising for job positions that say, you don't need compiler experience.
John:
Just come and be on the team.
John:
We'll teach you.
NEW_SPEAKER_SPEAKER_01:
Well, that is true.
NEW_SPEAKER_SPEAKER_01:
You do not need compiler experience.
NEW_SPEAKER_SPEAKER_01:
And in fact, I think actually neither me nor Holly had direct compiler experience before joining the Swift team to work on the language.
NEW_SPEAKER_SPEAKER_01:
To have a high tolerance for pain?
NEW_SPEAKER_SPEAKER_01:
So...
NEW_SPEAKER_SPEAKER_01:
Actually, I came to Swift through paying from other languages.
John:
That is such a good answer.
NEW_SPEAKER_SPEAKER_01:
That is so good.
NEW_SPEAKER_SPEAKER_01:
Are you sure you're not in PR?
NEW_SPEAKER_SPEAKER_01:
So my love for Swift comes from the fact that I have experienced what other languages have to offer.
NEW_SPEAKER_SPEAKER_01:
And there are, you know, I've always been a language enthusiast.
NEW_SPEAKER_SPEAKER_01:
And so whether it's
NEW_SPEAKER_SPEAKER_01:
Java or C++ or higher level languages like Ruby or Perl.
NEW_SPEAKER_SPEAKER_01:
There's something great about all of these different languages, but I always felt historically like these languages had compromises.
NEW_SPEAKER_SPEAKER_01:
They were either a little bit too slow because they were more dynamic and scripting based, or they were unsafe like C++ or really hard to comprehend like C++.
NEW_SPEAKER_SPEAKER_01:
It's a true story.
NEW_SPEAKER_SPEAKER_01:
And my background is actually I used to work on trading systems, and performance is really important in trading systems.
NEW_SPEAKER_SPEAKER_01:
And so we used to do a lot of things in C++, but at the same time, safety is really important in trading systems.
NEW_SPEAKER_SPEAKER_01:
You do not want the machine to do the wrong thing.
NEW_SPEAKER_SPEAKER_01:
And so we always used to have this trade-off between C++ and Java.
NEW_SPEAKER_SPEAKER_01:
And when I saw Swift 10 years ago now, I was actually...
NEW_SPEAKER_SPEAKER_01:
blown away by the fact that it actually managed to find the sweet spot between those different things.
NEW_SPEAKER_SPEAKER_01:
It was deterministic.
NEW_SPEAKER_SPEAKER_01:
It didn't have a garbage collector.
NEW_SPEAKER_SPEAKER_01:
But also, it had that higher level feel.
NEW_SPEAKER_SPEAKER_01:
It does sometimes look a lot more like sort of the Ruby-like language, where it's really joyful to program in.
NEW_SPEAKER_SPEAKER_01:
And it's really great to see that realized in things like Swift UI, where it brings back that joy of programming that I think sometimes we lose a little bit.
NEW_SPEAKER_SPEAKER_01:
And so that was what brought me to Swift.
NEW_SPEAKER_SPEAKER_01:
And I joined Apple originally.
NEW_SPEAKER_SPEAKER_01:
I was actually a library developer.
NEW_SPEAKER_SPEAKER_01:
So I didn't have that background in compilers, but I did have that background in writing algorithms and data structures and things like that.
NEW_SPEAKER_SPEAKER_01:
And that was a really nice route in.
NEW_SPEAKER_SPEAKER_01:
And from that, I learned about compiler performance.
NEW_SPEAKER_SPEAKER_01:
And from that, got more into the general language design.
NEW_SPEAKER_SPEAKER_01:
And that's how come I ended up here.
John:
And then Holly, you said you started working in Xcode, is that right?
John:
And then kind of meandered from there.
John:
What was that story like?
NEW_SPEAKER_SPEAKER_00:
Yeah, that's right.
NEW_SPEAKER_SPEAKER_00:
So I actually signed up for a mentorship program that the developer tools organization offered.
NEW_SPEAKER_SPEAKER_00:
And they deliberately paired mentees up with mentors from different parts of the organization so that you could get to meet people who you didn't work with on a day-to-day basis.
NEW_SPEAKER_SPEAKER_00:
And I got paired up with a Swift compiler engineer.
NEW_SPEAKER_SPEAKER_00:
And that sort of sparked my interest in actually joining the team.
NEW_SPEAKER_SPEAKER_00:
So for me, I feel like I became a compiler engineer by accident.
NEW_SPEAKER_SPEAKER_00:
What brought me to developer tools at Apple is I was really interested in education for programming.
NEW_SPEAKER_SPEAKER_00:
I also ended up studying computer science sort of by accident.
NEW_SPEAKER_SPEAKER_00:
I didn't go into university knowing anything about programming or computer science like a decade ago today.
NEW_SPEAKER_SPEAKER_00:
You know, it's Swift's 10-year anniversary.
NEW_SPEAKER_SPEAKER_00:
Ten years ago, I knew nothing about programming.
NEW_SPEAKER_SPEAKER_00:
I was graduating high school.
NEW_SPEAKER_SPEAKER_00:
Yeah.
NEW_SPEAKER_SPEAKER_00:
set to study dance at the University of Michigan, and engineering was sort of my backup, and all engineers have to take a programming class, and I really enjoyed it, and that, I think, for me, really showed the power of making Swift, or not Swift, making programming more approachable to people who weren't exposed to that previously, so I thought
NEW_SPEAKER_SPEAKER_00:
Working on developer tools was a good way to do that, and that was how I started to learn Swift when I joined the Xcode team.
NEW_SPEAKER_SPEAKER_00:
The part of Xcode that I worked on had just been entirely rewritten in Swift.
NEW_SPEAKER_SPEAKER_00:
So yeah, it was this series of opportunities that led me to really becoming interested in working on the Swift language itself, and now this is sort of the ultimate opportunity to make programming more approachable.
NEW_SPEAKER_SPEAKER_00:
to people who have an idea and are interested in bringing that to life through code.
John:
I love that.
John:
And I'll throw Marco under the bus with me, because I can tell you that Marco and I went to school for CS and computer engineering, and I cannot fathom a situation where engineering is like my fallback.
John:
Like, oh, I'm sure I'll be fine in engineering if this other stuff doesn't work.
John:
That's incredible.
John:
I just couldn't dance.
John:
Her story is like an after-school special of how you can slippery slope into the seedy world of compiler engineering.
John:
She started out as a promising dancer, but somehow the compiler people got her, and now look at her.
John:
Now, I'm going to continue to make John upset by continuing to be at the bottom of the document, but I promise, John, I will come back up to the beginning.
John:
At least you're in the – I'm about to ask if it's not even in the document.
John:
There's that.
John:
You're doing great.
John:
We have a structure.
John:
We're sticking to it.
John:
Are we?
John:
Well, this is our structure, despite what John says.
John:
It's not copyable.
John:
John, have you heard the show?
John:
Right.
John:
So, Ben, you were very rightfully, in my opinion, slagging on C++ just a few minutes ago.
John:
Guess what the Swift compiler is mostly right?
John:
Well, that's exactly what I was going to say.
John:
So, last I remember hearing, the Swift compiler, last I looked, the Swift compiler is largely, if not entirely, C++.
John:
So, you're pointing at me like, wait, there's more.
John:
So, tell me, is there more?
NEW_SPEAKER_SPEAKER_01:
Okay.
NEW_SPEAKER_SPEAKER_01:
There is more.
NEW_SPEAKER_SPEAKER_01:
So the compiler, I actually don't have the right percentage.
NEW_SPEAKER_SPEAKER_01:
It's actually slightly difficult to tell because if you look at the GitHub repo, it gives you lies for two reasons.
NEW_SPEAKER_SPEAKER_01:
One is, like, we have a lot of tests written in Swift, and those shouldn't count, right?
NEW_SPEAKER_SPEAKER_01:
Right, right, right.
NEW_SPEAKER_SPEAKER_01:
But also, we have started the process of writing parts of the compiler in Swift.
NEW_SPEAKER_SPEAKER_01:
Okay.
NEW_SPEAKER_SPEAKER_01:
And that started quite a while ago now.
NEW_SPEAKER_SPEAKER_01:
I think maybe four years ago now.
NEW_SPEAKER_SPEAKER_01:
But when we do that, we actually create those bits of the compiler that we rewrite as packages.
NEW_SPEAKER_SPEAKER_01:
And when you do that, we break them out into a separate repo.
NEW_SPEAKER_SPEAKER_01:
So if you go to github.com slash Apple for now, soon, Swift Lang, slash Swift dash driver, that was the first part of the Swift compiler that we started rewriting in Swift.
NEW_SPEAKER_SPEAKER_01:
That happened about four years ago.
NEW_SPEAKER_SPEAKER_01:
And the driver is basically the way into the front end of the compiler.
NEW_SPEAKER_SPEAKER_01:
So it's the thing that does the initial processing of your command lines, and it organizes the build and things like that.
NEW_SPEAKER_SPEAKER_01:
That was written in Swift.
NEW_SPEAKER_SPEAKER_01:
Two years ago now, we started rewriting the parser in Swift.
NEW_SPEAKER_SPEAKER_01:
And so that is actually part of a wider project called Swift Syntax, which is itself written in Swift, which is originally a way of just manipulating Swift code.
NEW_SPEAKER_SPEAKER_01:
It was a library for manipulating Swift code.
NEW_SPEAKER_SPEAKER_01:
And that evolved into a replacement for our current C++ parser.
NEW_SPEAKER_SPEAKER_01:
That is actually a foundation for macros.
NEW_SPEAKER_SPEAKER_01:
So last year, when we introduced macros, those are based around Swift Syntax and the Swift parser.
NEW_SPEAKER_SPEAKER_01:
We have some ongoing work that's happening at the moment to do the next layer down, which is
NEW_SPEAKER_SPEAKER_01:
what's called AST generation.
NEW_SPEAKER_SPEAKER_01:
So what you do is you parse the code and then you turn it into an abstract syntax tree.
NEW_SPEAKER_SPEAKER_01:
And then you have to lower that down into the underlying representation.
NEW_SPEAKER_SPEAKER_01:
That is ongoing at the moment.
NEW_SPEAKER_SPEAKER_01:
And once we've done the AST gen layer, we will actually be throwing away the C++ parser.
NEW_SPEAKER_SPEAKER_01:
Now, that's going to be an interesting moment because that is the point at which there is no way back.
NEW_SPEAKER_SPEAKER_01:
That is the point at which you will need a Swift compiler to build Swift.
NEW_SPEAKER_SPEAKER_01:
MARK MIRCHANDANIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
NEW_SPEAKER_SPEAKER_01:
So we're very familiar with that.
NEW_SPEAKER_SPEAKER_01:
But yeah, and then more recently than that, we have started writing optimizer passes in Swift.
NEW_SPEAKER_SPEAKER_01:
So that is actually using C++ interop, which is another important feature of Swift.
NEW_SPEAKER_SPEAKER_01:
We obviously interoperate with LLVM, which is written in C++.
NEW_SPEAKER_SPEAKER_01:
And we use that to build our optimizer passes to do things like hoist variables out of loops and things like that.
NEW_SPEAKER_SPEAKER_01:
And those are now written in Swift as well.
NEW_SPEAKER_SPEAKER_01:
So we are getting there.
NEW_SPEAKER_SPEAKER_01:
It'll be a ways away.
NEW_SPEAKER_SPEAKER_01:
It's not our main goal.
NEW_SPEAKER_SPEAKER_01:
We don't rewrite things for the sake of it, even though it's written in C++.
NEW_SPEAKER_SPEAKER_01:
It's working.
NEW_SPEAKER_SPEAKER_01:
And so really, when we decide we want to do something where we want to rewrite a part of the compiler, we try to make it for a good reason.
NEW_SPEAKER_SPEAKER_01:
And those good reasons can be, for example, creating a macro system with a nice, friendly Swift API.
NEW_SPEAKER_SPEAKER_01:
Or when we rewrite the optimizer passes, we usually do it in order to simplify them and make them more effective.
NEW_SPEAKER_SPEAKER_01:
Yeah, so we are on that path to self-hosting.
NEW_SPEAKER_SPEAKER_01:
But it's going to feel really good when you get to delete that code, though.
NEW_SPEAKER_SPEAKER_01:
It feels very good to delete code.
John:
So, Bill, I'm not sure which one of you is more appropriate to answer the following, but building on that, it certainly seems the implication is there is a strong interest to become self-hosted.
John:
And I'm not sure I'm the best person to summarize that, but basically the Swift compiler is written in Swift, right?
John:
And is it fair to say
John:
the eventual, I'm not looking for a date, but the eventual one sometime goal would be to self-host entirely if possible.
John:
Is that fair to say?
NEW_SPEAKER_SPEAKER_01:
We don't comment on future products.
NEW_SPEAKER_SPEAKER_01:
Well, this is not a product.
NEW_SPEAKER_SPEAKER_01:
This is the Swift language that is entirely open source and that we are perfectly at liberty to comment on.
NEW_SPEAKER_SPEAKER_01:
So, yes, I think the ultimate goal is that the compiler should be written in Swift.
NEW_SPEAKER_SPEAKER_01:
If nothing else, it does improve the safety of the compiler.
NEW_SPEAKER_SPEAKER_01:
The compiler...
NEW_SPEAKER_SPEAKER_01:
is not filled with segfaults, but they can happen.
NEW_SPEAKER_SPEAKER_01:
And obviously rewriting parts of it in Swift eliminates that possibility because it's a safer language.
NEW_SPEAKER_SPEAKER_01:
And so that's one benefit that comes from it as well as bringing other features.
NEW_SPEAKER_SPEAKER_01:
The other benefit is it makes it more approachable for outside people.
NEW_SPEAKER_SPEAKER_01:
I mean, you were talking about working on the Swift compiler as if it's a very intimidating thing, but at the end of the day, it's...
NEW_SPEAKER_SPEAKER_01:
It's actually kind of pretty straightforward code when you look at a small part of it, right?
NEW_SPEAKER_SPEAKER_01:
When you look at a particular optimization pass, you can usually see pretty much what it's doing.
NEW_SPEAKER_SPEAKER_01:
And it's actually a great opportunity to get contributors involved.
NEW_SPEAKER_SPEAKER_01:
I know Holly's worked with quite a lot of people who've come new to the Swift programming language as well.
NEW_SPEAKER_SPEAKER_00:
Yeah, we also organize a mentorship program called the Swift Mentorship Program, where open source contributors who are interested in contributing to various parts of the Swift project, including but not limited to the compiler, they sign up, they get paired with someone who regularly contributes to the compiler, and they work together for 10 weeks on open source contributions.
NEW_SPEAKER_SPEAKER_00:
And I find that a lot of people who write Swift, who are iOS developers, are really interested in making
NEW_SPEAKER_SPEAKER_00:
some contributions to the compiler just as a learning experience or better understanding how their code works.
NEW_SPEAKER_SPEAKER_00:
If you're in the depths of how type inference or the actor isolation checker works, it gives you a little more knowledge into how the compiler sees your code when you're writing Swift code.
NEW_SPEAKER_SPEAKER_00:
So yeah, it's a cool program and a really good learning experience for people who are writing Swift.
NEW_SPEAKER_SPEAKER_00:
And I completely agree that moving more of the compiler over to Swift will make contributing to the compiler a lot more approachable for people.
John:
Does that include the standard library?
John:
Like if someone wants to add a method that says first, second, third, spelled out, fourth, fifth, sixth, and you stop them when they get to 30 seconds.
John:
Like that's all Swift code in the standard library.
John:
So you can contribute to that and say, hey, I contributed to the Swift language, but you're just making Swift methods in the library.
John:
So I'm curious, and probably for Holly, as we go into this new era of Swift concurrency and data race safety and everything, Swift, I think, has always struck an interesting balance.
John:
I think it's kind of a roller coaster.
John:
Sometimes it's more successful than other times at this balance of –
John:
being easy to use for non-experts or newbies to a language or just new programmers, and also having all this power behind it and having quite a bit of complexity behind it.
John:
And as we go into this new data race safety era,
John:
How do you strike that balance?
John:
Obviously, these are some very advanced concepts, and somebody might get some warning as they're building their code saying something's not sendable because it has mutable state, and they might not even know what any of that means.
John:
How do you balance that with being approachable to new programmers or to less experienced programmers?
NEW_SPEAKER_SPEAKER_00:
Yeah, so...
NEW_SPEAKER_SPEAKER_00:
The goal for concurrency is really similar to what we've accomplished with other advanced features of the language, like the generic system is the one that I always go to because from the very first lines of code that you write in Swift, you're using the generic system because you're using standard library types like array.
NEW_SPEAKER_SPEAKER_00:
Or you're using frameworks like SwiftUI, which are really heavily leveraging these advanced features to make APIs that are really natural to use for programmers.
NEW_SPEAKER_SPEAKER_00:
But you don't need to understand generics.
NEW_SPEAKER_SPEAKER_00:
You don't need to understand how it works until you're at a point where you need to use those advanced features in your own code.
NEW_SPEAKER_SPEAKER_00:
And that's the end goal with concurrency as well.
NEW_SPEAKER_SPEAKER_00:
For newcomers to app development or newcomers to Swift, when you're writing code, by default, that code should be on the main actor.
NEW_SPEAKER_SPEAKER_00:
And you shouldn't have to actively think about the fact that that code is on the main actor until you're trying to actively introduce concurrency into your project.
NEW_SPEAKER_SPEAKER_00:
And at that point, you'll be confronted when you make a mistake that can lead to a data race in your code.
NEW_SPEAKER_SPEAKER_00:
And I think
NEW_SPEAKER_SPEAKER_00:
that both the progressive disclosures is the way to make that complexity more approachable, but I also think introducing those checks at compile time will also make learning to write concurrent code a lot more approachable for people who are new to concurrency in general.
NEW_SPEAKER_SPEAKER_00:
And this is a continued evolution of making concurrent programming more approachable,
NEW_SPEAKER_SPEAKER_00:
Like concurrent programming is just notoriously really hard to get right.
NEW_SPEAKER_SPEAKER_00:
I don't know if you've ever debugged a data race before, for those of you who are listening, but if you have, you know that it can take days or even weeks.
NEW_SPEAKER_SPEAKER_00:
And the introduction of dispatch even was a huge step forward for making concurrent code easier to write.
NEW_SPEAKER_SPEAKER_00:
Working with dispatch queues is way easier than managing low-level system resources like threads manually in your app.
NEW_SPEAKER_SPEAKER_00:
But you still have to know when to apply those tools to protect mutable state in your code.
NEW_SPEAKER_SPEAKER_00:
And with data race safety in Swift 6, you can't get it wrong.
NEW_SPEAKER_SPEAKER_00:
The compiler will tell you if there's a risk of a data race in your code.
NEW_SPEAKER_SPEAKER_00:
And having to confront those concepts at the point when you make a mistake is better for...
NEW_SPEAKER_SPEAKER_00:
forming a mental model of how concurrent code should be written in your project.
NEW_SPEAKER_SPEAKER_00:
So I'm really excited for people to start to learn concurrency for the first time with data ray safety in Swift 6, as opposed to, I think a lot of people right now have internalized how to use dispatch, and they've been using that for many years, and now they're trying to learn this other, like...
NEW_SPEAKER_SPEAKER_00:
It's not a completely different system in how you write code, but it is different in how you approach it and at what point you're confronted with the issues.
NEW_SPEAKER_SPEAKER_00:
And I think that might be a little bit more difficult than learning concurrency for the first time with the compiler checks in place to help prevent you from making mistakes.
John:
Is that how you characterize the difference between the Swift concurrency and the predecessor concurrency systems at Apple?
John:
Like we've had...
John:
Grand Seltzer Dispatch, the Dispatch Queues, NS Operation Queue, P-threads back in the day, locks of various kinds over the years.
John:
And all of those were kind of, you'd have sessions on, and they'd say, here's how you properly use this.
John:
Here's how many queues you should have, and stuff like that.
John:
But it was all sort of like runtime stuff.
John:
And everything I hear about Swift concurrency is always,
John:
we will do these checks for you at compile time so that you don't have to run your thing to see if there is a problem or audit the code and look over it.
John:
This is like the compiler will check it for you and make sure it's mostly OK.
John:
Would you say that's the big difference?
NEW_SPEAKER_SPEAKER_00:
Yeah, absolutely.
NEW_SPEAKER_SPEAKER_00:
You should be able to program by bumper where the compiler is there to tell you, oh, no, you got this a little bit wrong with actionable suggestions for how to fix that code.
John:
So you're talking about the progressive disclosure and you don't have to know about this until you start introducing concurrency.
John:
That's true of the Swift language, if you're writing just Swift code.
John:
But everyone else in this company makes a bunch of frameworks.
John:
And those don't know or care about Swift concurrency for the most part.
John:
And they're in your code.
John:
And you think, I haven't introduced any concurrency.
John:
But it's like, well, this method has a callback.
John:
And it is cranky now.
John:
And you're like, but why?
John:
I didn't make that API.
John:
It's complaining about something that I don't understand.
John:
It's not an API that I wrote.
John:
And so you're faced with this dilemma of just
John:
You stare at it for a while, it's like, should I not use that API?
John:
I think we've all had experience, and everyone you've probably talked to has had experience trying to enable strict concurrency in 5.10.
John:
And you set the setting in Xcode, you see all the warnings, and you're like,
John:
How far away am I really?
John:
You're like, how many, you know, and I think we've all taken different swings at this, like, and I've seen you both sort of counter the conventional wisdom.
John:
It's like, I'll just make everything sendable and that will fix everything, but that doesn't work.
John:
And so you're like, well, maybe I can just add annotations.
John:
I'll put main actor on a bunch of things, but that doesn't work.
John:
And it's like, well, maybe I'll just sprinkle a Zoom isolated everywhere.
John:
And it's like, well, that's probably not the right approach.
John:
And I think my personal experience is I've taken like four different runs at bringing one of my apps on just stricken currency.
John:
And I just keep backing off and scratching my, I know there's a WWC session about it and I haven't seen it, my bad.
John:
It was a busy day.
John:
And it's migrating to Swift concurrence.
John:
But I feel like that is a lot of the barrier.
John:
And it's nothing to do with the language.
John:
It has to do with the APIs that we're using that were created decades ago that have their own conventions.
John:
And stricken currency.
John:
And it's not wrong.
John:
It's correct.
John:
There is a potential for a mutable state to be messed up there.
John:
And then, of course, even in our own code, it's like, well, I use queues for this.
John:
And I use locks.
John:
And I'm pretty sure it's safe.
John:
But stricken currency is safe.
John:
Well, that's what unchecked sendable is for.
John:
Yeah, but that's the whole thing.
John:
Like you don't want to go through and sprinkle it through.
John:
It says, I'm sure this is OK.
John:
I'm sure this is OK.
John:
Like there are annotations to do that.
John:
But all you're doing is undercutting yourself by saying, no, I'm totally sure the code I wrote last year is bug free and there is no races.
John:
And it will satisfy the compiler.
John:
But you haven't actually solved the problem.
John:
You haven't actually used the system you're saying, which is you should be able to write it.
John:
The compiler tells you whether it's wrong.
John:
You might as well just turn that mode off.
John:
So, I mean, I think a lot of users find it frustrating, but it is a difficult problem.
John:
And I'm assuming, well, you tell me what you think the correct approach is.
John:
Give me the three-second summary of the session that I didn't watch.
NEW_SPEAKER_SPEAKER_00:
I'll let Ben do that in a spend session.
NEW_SPEAKER_SPEAKER_01:
It is, and well done for Casey for getting ahead of John and watching it already.
NEW_SPEAKER_SPEAKER_01:
So...
NEW_SPEAKER_SPEAKER_01:
It really partly depends on what kind of frameworks you're using, and it's possible that you're using some frameworks that make it harder or easier, depending on what kind of code you're using.
John:
Mac frameworks.
NEW_SPEAKER_SPEAKER_01:
Right.
NEW_SPEAKER_SPEAKER_01:
Oh, you're screwed.
NEW_SPEAKER_SPEAKER_01:
So, for example, the UI layer, we've actually, and it's worth tying the new SDK because...
NEW_SPEAKER_SPEAKER_01:
At the UI layer, there's been a lot of work to indicate which parts of SwiftUI, also UIKit and AppKit, are by definition always supposed to be running on the main thread.
NEW_SPEAKER_SPEAKER_01:
And that should actually, for people who've tried 5.10, it's well worth downloading the new SDK and giving that a go.
John:
Does that also include, like, I know this is a documentation issue, but often you'll see a thing with a callback and you have a question, it's like,
John:
What thread will the callback run on?
John:
And you're just like, oh, you're just supposed to know whatever thread you register it on, that's the thread the callback will run on, but you don't see that in a documentation.
John:
So you're like, well, I registered for this on the main thread.
John:
And when the callback gets called, it will probably get called on the main thread.
John:
And sometimes they take a queue as an argument, and you just have to know that the main queue is the same as the main thread.
John:
But documentation-wise, I always feel like I look up one of these old AppKit things, and it's guesswork.
John:
Well, but did you know, John, I learned this morning that there's a keyword, what is it?
John:
It's assume main thread?
John:
Yeah, assume isolated.
NEW_SPEAKER_SPEAKER_01:
There it is.
John:
I knew I couldn't quite get there.
John:
But there's tools for this, John, as it turns out.
NEW_SPEAKER_SPEAKER_00:
I know about assume isolated.
John:
That's not the tool for that.
John:
You're nuts.
John:
Don't do that.
John:
Assume isolated, all it's going to do is throw a runtime error when it finds out it's not on the main thread.
NEW_SPEAKER_SPEAKER_01:
Yeah, don't do that.
NEW_SPEAKER_SPEAKER_01:
Just dispatch it to me.
NEW_SPEAKER_SPEAKER_01:
So assume isolated does throw a runtime error when you're not on the main thread.
NEW_SPEAKER_SPEAKER_01:
This is actually something that a lot of good programmers are already doing, which is they put in preconditions where they know this is supposed to be on the main thread.
NEW_SPEAKER_SPEAKER_01:
And they put in a precondition just in case they call it from somewhere else in their app where they're getting a call from a dispatch queue that's not isolated to the main thread.
NEW_SPEAKER_SPEAKER_01:
And that can lead to trouble.
NEW_SPEAKER_SPEAKER_01:
I think somebody was saying earlier
NEW_SPEAKER_SPEAKER_01:
you run your program and you find out it doesn't quite work, as opposed to at compile time, you find out that you need to do something.
John:
Yeah, it feels like it's undercutting.
John:
The bumper thing Holly was saying is like, I don't want to find out at runtime.
John:
Every time I do assume I isolate it, I'm like, there must be a better way.
John:
Don't use that there, man.
John:
That's not what it's for.
NEW_SPEAKER_SPEAKER_01:
So I would say that finding out at runtime that your code is broken is the best case scenario under the old world, which is that you hope to find out when you run your code that something is wrong.
NEW_SPEAKER_SPEAKER_01:
But what actually happens is that in some of these techniques,
NEW_SPEAKER_SPEAKER_01:
you find out in the wild when your program is crashing and you do not exactly know why.
NEW_SPEAKER_SPEAKER_01:
I'm always amused by people who make these jokes on Mastodon or Twitter where they say like, they make a joke about concurrency where they jumble up the words.
NEW_SPEAKER_SPEAKER_01:
And that's cute.
NEW_SPEAKER_SPEAKER_01:
But that is, again, the best case scenario is jumbled up words.
NEW_SPEAKER_SPEAKER_01:
That's very benign.
NEW_SPEAKER_SPEAKER_01:
What's worse is like, you know, you crash, you corrupt user data.
NEW_SPEAKER_SPEAKER_01:
This is no good.
NEW_SPEAKER_SPEAKER_01:
And so that's why a lot of people have these really great practices in the old world of dispatch.
NEW_SPEAKER_SPEAKER_01:
where they will insert these assertions saying, I want you to stop me if I'm not running on the main queue.
NEW_SPEAKER_SPEAKER_01:
So I think the long-term goal is that we need to lift this information out of documentation.
NEW_SPEAKER_SPEAKER_01:
We want to take it out of documentation and put it actually in the definition of the API.
NEW_SPEAKER_SPEAKER_01:
It's not in the documentation now, so you don't have to lift it out.
NEW_SPEAKER_SPEAKER_01:
So the benefit of putting it there so that the compiler actually enforces it is that you can't not have that information.
NEW_SPEAKER_SPEAKER_01:
By definition, your code does encapsulate the information about where you are running and how it's running.
John:
Yeah, because one of the things I do when flailing is like there's a callback and I'm like, can I just annotate the callback as main actor?
John:
And the answer is no.
John:
And then it's like, why?
John:
Is it already on, always on the main thread?
John:
I figure what the error is, I'm sure.
John:
Just wait for the framework to be updated with async calls.
John:
Yeah, well, you don't have all the time in the world to wait.
John:
What it comes down to, like you mentioned queues, right?
John:
So one of my apps has concurrency.
John:
I'm sorry it does.
John:
And I use queues.
John:
And in one situation, I wrote a little class and I use locks, old style locks.
John:
And
John:
Pretty sure it's probably okay.
John:
But I look at that and I'm like, I would like to use Swift concurrency because then I would feel more sure.
John:
But there's nothing you can do to sort of annotate or mark up dispatch cues or locks other than the reassurance of just telling the compiler, I'm pretty sure that I'm right.
John:
I would rather just like pull that out and re-implement it with actors and so on.
John:
And that sometimes just seems daunting.
NEW_SPEAKER_SPEAKER_00:
So another thing that there's a ton of Swift code out there and Swift code that interoperates with C based languages like Objective-C and C++.
NEW_SPEAKER_SPEAKER_00:
We're at the start of this transition to start to integrate Swift's native safer concurrency primitives into these like vast languages.
NEW_SPEAKER_SPEAKER_00:
code bases that are using older library-based concurrency primitives like dispatch queues.
NEW_SPEAKER_SPEAKER_00:
The system is designed for incremental migration.
NEW_SPEAKER_SPEAKER_00:
So in the case, if you have a class backed by a dispatch queue, there is a technique that you can use to turn that class into an actor that's backed by a dispatch queue.
NEW_SPEAKER_SPEAKER_00:
It uses a fancy feature called custom actor executors, but the way to do it, it's only like four or five lines of code that you actually have to write in your own code.
NEW_SPEAKER_SPEAKER_00:
And what that lets you do is from your Swift code, it lets you use the static actor isolation and not have to mess with the dispatch queue.
NEW_SPEAKER_SPEAKER_00:
But when you're interacting with APIs that are based on dispatch queues, you can still pass the dispatch queue there.
NEW_SPEAKER_SPEAKER_00:
And then you can bridge between the dynamic isolation in the static world with tools like Assume Isolated.
John:
That brings up another question of incremental adoption.
John:
I know, so this Swift 6 just came out, and in the old 5 world, we had the little setting to set it on complete concurrency or whatever.
John:
I know there's a whole bunch of features in Swift 6 and new things for setting ability and everything that make it easier.
John:
But what is the mechanism in your project of saying, like, I want, you know, is it per module?
John:
Is it per file to saying, I want the Swift 6 language features, but this file is not ready for strict concurrency?
John:
What does that look like?
NEW_SPEAKER_SPEAKER_00:
So the setting is per module.
NEW_SPEAKER_SPEAKER_00:
So in your Xcode build settings, there's a language version setting, or if you're in a Swift package manifest, there's an API for setting it per target.
NEW_SPEAKER_SPEAKER_00:
And many people currently have that set to something, whether it's for 4.2 or 5.
NEW_SPEAKER_SPEAKER_00:
So you would change that to 6 for the specific module that you're looking to migrate to Swift 6.
NEW_SPEAKER_SPEAKER_00:
And then if you have a particular file that...
NEW_SPEAKER_SPEAKER_00:
violate some of the rules in ways that are really difficult for you to change, there are ways to opt out of checking in specific areas in your project using things like pre-concurrency import statements.
NEW_SPEAKER_SPEAKER_00:
If the issue is in an API that you're using, or tools like non-isolated unsafe, if you have, for example, like a global variable that you're manually guarding with a lock or a queue, at the point when you access it, you can use non-isolated unsafe to opt out of the compilers checking there.
NEW_SPEAKER_SPEAKER_00:
So there are a variety of tools like that to let you opt out of the checking in narrow situations in your code.
NEW_SPEAKER_SPEAKER_00:
And then those are also things like handles that you can audit for later to actually take a look at the opt-outs that you're using in your code and try to use those as refactoring opportunities to rewrite some of that code to use something safer.
John:
So you're picking the Swift 6 as the language, and that includes everything having to do with Swift 6.
John:
No.
NEW_SPEAKER_SPEAKER_01:
So Swift 6, the language mode where you go into the Xcode settings and you say language mode of Swift 6, that purely governs the strict concurrency checking.
NEW_SPEAKER_SPEAKER_01:
So the Swift 6 compiler that you get with the latest Xcode, that has all of the new features.
NEW_SPEAKER_SPEAKER_01:
So I think you made a glancing blow to non-copyable types.
NEW_SPEAKER_SPEAKER_01:
Those features are available.
NEW_SPEAKER_SPEAKER_01:
New generic capabilities for non-copyable types are available in the Swift 6 compiler.
NEW_SPEAKER_SPEAKER_01:
You do not need to
John:
So you would pick the Swift 5 language mode, but it's using the Swift 6 compiler to run in Swift 5 language mode.
John:
You get non-copyable types.
John:
You don't get the stricken currency.
NEW_SPEAKER_SPEAKER_01:
That's right.
NEW_SPEAKER_SPEAKER_01:
And that's exactly, this is part of a journey that the entire Swift ecosystem needs to go through.
NEW_SPEAKER_SPEAKER_01:
So being ready for Swift 6, having your dependencies ready for Swift 6, there's actually at swiftpackageindex.com, which is this great website, they have a tracker.
NEW_SPEAKER_SPEAKER_01:
now that tells you which packages they are compiling that build cleanly under Swift 6 code.
NEW_SPEAKER_SPEAKER_01:
But it really does depend on the nature of your program and whether your dependencies are now ready for Swift 6, whether you want to turn on that language mode.
NEW_SPEAKER_SPEAKER_01:
And this dates back to we've been doing this now since the Swift 4 days.
NEW_SPEAKER_SPEAKER_01:
So since we introduced the Swift 4 language mode, we've always had this source compatibility guarantee promise that whenever you download the new compiler,
NEW_SPEAKER_SPEAKER_01:
With a couple of exceptions, where maybe there are a couple of issues with your code where maybe the code was explicitly incorrect, we always want you to be able to compile your code as is with the latest compiler.
NEW_SPEAKER_SPEAKER_01:
And then when you're ready for some breaking change, there were a few in Swift 5, and obviously in Swift 6, the key change here is strict concurrency, you're then able to turn it on on a per target basis.
John:
MARK MANDELSKI- Is that like a ?
John:
a longstanding kind of marketing decision to tie them to the, I mean, just deciding that Swift 6 means stricken currency.
John:
You could have, for example, said Swift 6 just means Swift 6 language features and there's some other option for stricken currency.
John:
But you said, no, we're tying this feature to this number because people want the higher number.
John:
Is that like a sort of a...
John:
social engineering decision?
NEW_SPEAKER_SPEAKER_01:
It's a way of thinking about the forward progress.
NEW_SPEAKER_SPEAKER_01:
I mean, you don't want to be stuck in this world with the Python 2 for 2 to 3 transition style thing, where those were tied to updating your compiler, and then you couldn't get the new stuff without changing your code to adapt to the way that the new language works.
NEW_SPEAKER_SPEAKER_01:
So it's this way of helping engineer
NEW_SPEAKER_SPEAKER_01:
the ecosystem to help have this continuous forward progress.
NEW_SPEAKER_SPEAKER_01:
But at the end of the day, people also, you know, some people have written code in such a way that it won't be so easily adapted to Swift concurrency.
NEW_SPEAKER_SPEAKER_01:
Some people have written code using a lot of new frameworks and a lot of async await, and the path for them is actually pretty clean.
NEW_SPEAKER_SPEAKER_01:
And so we want people to be able to opt into that.
NEW_SPEAKER_SPEAKER_01:
The choice as to whether you opt in or not is up to you.
NEW_SPEAKER_SPEAKER_01:
If you're finding that you are experiencing quite a lot of pretty gnarly crashes,
NEW_SPEAKER_SPEAKER_01:
It's probably worth considering opting in.
NEW_SPEAKER_SPEAKER_01:
One great time to opt in is if actually you want to start introducing a lot more parallelism to your code, right?
NEW_SPEAKER_SPEAKER_01:
So we have these powerful new devices.
NEW_SPEAKER_SPEAKER_01:
They have many cores.
NEW_SPEAKER_SPEAKER_01:
You might find yourself with an app that previously was doing most of its work on the main thread with a little bit of background processing, but you really want to take advantage of a lot more parallelism in your code.
NEW_SPEAKER_SPEAKER_01:
That would be a great time to turn on Swift 6 mode in order to...
NEW_SPEAKER_SPEAKER_01:
know that you can do those refactorings without fear of introducing new data races.
NEW_SPEAKER_SPEAKER_01:
So yeah, it's really up to each individual project to make that decision and to see how the community is moving forward with them in order to update their dependencies and then take the plunge.
John:
Do you worry about like releasing Swift version 10 many years from now and huge code bases are still in Swift 5 language mode?
John:
Like they're using a Swift 10 compiler to run Swift 5 language mode because they could never get the wherewithal to go stricken currency compliant.
John:
And you're just plowing bravely forward here at Apple for making version after version and they're all great, but they can never cross to the sixth threshold because they can never get their code
John:
to run under stricken currency is millions of lines of like dispatch queue and manually created locks.
John:
Like, do you worry about hindering your parks?
John:
You've basically made a hard gate of like, you're not going to be running a Swiss 7 next year or whenever if you can't go stricken currency.
John:
And you're like, well, my reason I can't go is because we have 10 million lines of, you know, manually managed locks or something.
NEW_SPEAKER_SPEAKER_01:
So it really only governs a handful of things.
NEW_SPEAKER_SPEAKER_01:
So the goal is always, whenever we introduce a new language feature, that you do not have to update to the new language mode.
NEW_SPEAKER_SPEAKER_01:
We were looking at somebody's project yesterday where they were still on Swift 4 mode, and really there was not that much they were missing out on.
NEW_SPEAKER_SPEAKER_01:
So we have this long-term promise to always support those language features so that people aren't forced to update.
NEW_SPEAKER_SPEAKER_01:
But like I say, most of the language features themselves are not gated on the language version.
NEW_SPEAKER_SPEAKER_01:
And so really, it's only when we need to take these big step forwards that we encourage people to upgrade.
John:
They'd be running in Swift 5 language mode, but they'd still have access to all the new Swift 10 features, but they would feel bad about themselves.
John:
They're not.
John:
Because their number is five.
John:
And you're rolling out seven and eight and nine and 10.
John:
And people, they look at the little gamified badge on the Swift package index.
John:
And like, you don't have the little things that Swift 10 compliant.
John:
And I have a little star next to my package.
John:
And you don't.
John:
It's like, I get the language features.
John:
It's just not compliant.
NEW_SPEAKER_SPEAKER_00:
I also think there's a misconception that you need to totally eliminate all of the uses of tools like locks and dispatch queues in order to migrate to Swift 6.
NEW_SPEAKER_SPEAKER_00:
I don't think that's true.
NEW_SPEAKER_SPEAKER_00:
I think locks, I mean, the Swift 6 standard library includes a new...
NEW_SPEAKER_SPEAKER_00:
primitive mutual exclusion lock called mutex.
NEW_SPEAKER_SPEAKER_00:
And that is a tool that people can and should use in some scenarios in their code.
NEW_SPEAKER_SPEAKER_00:
And I know there are a variety of other lock types out there that people are currently using.
NEW_SPEAKER_SPEAKER_00:
You don't need to stop using those types in order to migrate your code base to
NEW_SPEAKER_SPEAKER_00:
the Swift 6 language mode.
NEW_SPEAKER_SPEAKER_00:
The same thing is true of dispatch queues.
NEW_SPEAKER_SPEAKER_00:
And like I said, part of the reason why the system is built on incremental migration is because we know there's so much concurrent code out there that is using dispatch and other concurrency primitives.
NEW_SPEAKER_SPEAKER_00:
And if you had to eliminate or just totally refactor all of your code in order to migrate to Swift 6, nobody would ever do it.
NEW_SPEAKER_SPEAKER_00:
So I don't think you need to actually massively refactor your code in order to migrate to Swift 6.
NEW_SPEAKER_SPEAKER_00:
Though in some cases, like in Ben's talk, you'll see the talk that he gave back in 2021, he actually took a sample app.
NEW_SPEAKER_SPEAKER_00:
And it was using dispatch.
NEW_SPEAKER_SPEAKER_00:
And he went through and replaced some uses of dispatch cues with actors.
NEW_SPEAKER_SPEAKER_00:
And that might make the migration a little bit easier in some cases.
NEW_SPEAKER_SPEAKER_00:
But you'll sort of see when you watch the talk.
NEW_SPEAKER_SPEAKER_00:
some of the things that are made easier by introducing actors in some places, but it is still possible to do it if you're using other things like dispatch queues.
NEW_SPEAKER_SPEAKER_01:
I have seen that talk.
NEW_SPEAKER_SPEAKER_01:
One of the challenges there is that doing that refactoring prior actually made it a lot easier to migrate to Swift 6, and that's actually something that we'd encourage is people who have been adopting async and await and things like that, they will find that turning on strict concurrency mode is a lot smoother for them.
NEW_SPEAKER_SPEAKER_01:
But we've also, in the latest compiler,
NEW_SPEAKER_SPEAKER_01:
added a lot more affordances, for example, around not having to make your type sendable, but also be able to pass them through between isolation domains.
NEW_SPEAKER_SPEAKER_01:
One of the challenges with writing the latest talk is that actually I had these great examples of problems that I was going to talk about, and then we fixed the compiler, so they weren't a problem anymore.
NEW_SPEAKER_SPEAKER_00:
It happened like three times.
John:
That's a good problem to have.
John:
It's a very good problem.
John:
I mean, that brings me to the next topic.
John:
For both of you, what is it like
John:
developing Swift in the open.
John:
Because I'm watching all year on Swift Evolution.
John:
I see the features coming in Swift 6 as part of the reason I kind of backed off my recent attempt.
John:
I'm like, look, they're fixing a bunch of stuff in Swift 6.
John:
And you see them go by.
John:
You see the proposals.
John:
Here, we're doing this thing.
John:
They're fixing the problems in your talk.
John:
And I see it happening all throughout the year.
John:
That's very different than most other people here at Apple.
John:
I mean, maybe some people sit down for WWDC and they're shocked by Swift 6.
John:
But if you're following the forums and watching the proposals,
John:
It's developed in the open.
John:
It's open source.
John:
The process of deciding what goes into it is open.
John:
There's no mystery involved.
John:
What is that like for you in a company where that is absolutely not true of all the other teams that you're working with, except for maybe WebKit?
NEW_SPEAKER_SPEAKER_01:
For WebKit, but also increasingly we're seeing more of this style of operating
NEW_SPEAKER_SPEAKER_01:
foundation now is operating in a similar fashion.
NEW_SPEAKER_SPEAKER_01:
And that has actually been key to the next thing that we've announced this year, which is that we now have this single unified foundation code base across platforms.
NEW_SPEAKER_SPEAKER_01:
So the same foundation that you're running
NEW_SPEAKER_SPEAKER_01:
on your phone and on your Mac, is the foundation code that you will be running if you were to stand up a server running on Linux.
NEW_SPEAKER_SPEAKER_01:
And so they've been running language proposals, sorry, language proposals, framework proposals to introduce new features such as, I think, Predicate, which is a foundation type, recently acquired support for regexes,
NEW_SPEAKER_SPEAKER_01:
And that proposal was discussed in the open.
NEW_SPEAKER_SPEAKER_01:
And then the other example, I heard your podcast last week where you were wondering, speculating about whether there was going to be a new testing framework.
NEW_SPEAKER_SPEAKER_01:
That's because I couldn't remember the name of Swift testing.
John:
That's the one I had seen, yes.
NEW_SPEAKER_SPEAKER_01:
And yeah, so Swift testing was developed in the open.
NEW_SPEAKER_SPEAKER_01:
We had some really great community feedback from that.
NEW_SPEAKER_SPEAKER_01:
And so that's another place where we're doing that kind of open dialogue with the community about sort of the next layer up of Swift framework features.
John:
You can use it as an example to the other groups.
John:
Like, look, we have a public issue tracker.
John:
And when people have problems, we can discuss them in the open.
John:
And look how much more efficient it is to go back and forth on GitHub issues and discuss proposals.
John:
And these other groups are sending carrier pigeons across the country through seven different intermediary parties with this game of telephone to find one crashing bug.
John:
Do you ever pitch the other groups and say, hey, I mean, I obviously worked on Foundation.
John:
This could be you.
John:
You could be getting bug reports from people and communicating with them in an efficient manner and
John:
and fixing them?
NEW_SPEAKER_SPEAKER_01:
Yeah, we get a huge amount of benefit from the Swift community, I think.
NEW_SPEAKER_SPEAKER_01:
When we bring ideas to them for new language features, we get this real-time feedback where the people on the forums, they spot issues with what we're proposing that we had not thought about.
NEW_SPEAKER_SPEAKER_01:
And we iterate with them on that, and we get a huge amount of value from getting that real-time feedback from people.
NEW_SPEAKER_SPEAKER_01:
And so I would...
NEW_SPEAKER_SPEAKER_01:
I would say that's certainly been a valuable process for us.
NEW_SPEAKER_SPEAKER_01:
Plus you get to argue about keywords.
NEW_SPEAKER_SPEAKER_01:
The true purpose of every language evolutionist.
NEW_SPEAKER_SPEAKER_01:
We've fallen into this mode now where we, this is something we've evolved as a process in the language steering group that Holly and I sit on, which is we're now in this mode where we will agree a proposal in principle, where we talk about the fundamentals of the language proposal and how it's going to work.
NEW_SPEAKER_SPEAKER_01:
And then what we say is we've agreed that in principle, and now there's like a free swim where everybody gets to specifically focus on the name we're going to use for the keyword.
NEW_SPEAKER_SPEAKER_01:
And that has actually helped the process a lot because the bike shedding is a shiny thing that people immediately move towards.
NEW_SPEAKER_SPEAKER_01:
And so if you say like, let's park the naming discussion for now.
NEW_SPEAKER_SPEAKER_01:
Let's talk about the fundamental feature.
NEW_SPEAKER_SPEAKER_01:
Then when we've agreed the fundamental feature and we accept it in principle, then we can have like a discussion about what we're actually going to call it.
John:
And I know that's a source of contention and it's a silly argument with people, but it really does make a big difference in language.
John:
Some people look at the Switch Evolution or other language lists and they're like, it just seems like a bunch of people arguing over whether copyable should have a tilde in front of it, should be a new keyword.
John:
But that's so important because those decisions you make, people live with those for decades.
John:
So you should spend a month arguing about it.
John:
Because I've seen it change.
John:
And for the illusion, like the original proposal will have this thing or whatever, and you'll end up with a different thing.
John:
And it's better.
John:
You're making it better by arguing about it.
John:
I guess people just don't have a tolerance for it.
John:
They think, oh, that's not important.
John:
I don't care what the word is called.
John:
But it makes such a big difference to the language.
John:
And anytime you make a slightly wrong choice.
John:
I remember I was talking to, I don't know, it was Dennis Ritchie or one of the old Unix guys or whatever.
John:
He said, do you have any regrets about your career?
John:
And he said, I wish I'd put an E on the create system call.
John:
C-R-E-A-T.
John:
Wow.
John:
How long is he been living with that?
John:
I wanted to save that character, and now it's created for just for the rest of it.
John:
It's on macOS.
John:
It's on every Apple platform right now somewhere.
John:
In the source code, there's a call to create with no E on it because this guy made a bad decision in the 70s.
John:
And so you don't want that to be you.
John:
So yeah, spend the time arguing about it.
John:
And I think that what you said, figuring out what you're going to do and arguing about the keywords is a nice separation so you can make forward progress.
John:
But I'm here to endorse arguing about keywords.
NEW_SPEAKER_SPEAKER_00:
It's also really valuable because there was a recent proposal.
NEW_SPEAKER_SPEAKER_00:
called Sending, Parameter, and Result Modifiers.
NEW_SPEAKER_SPEAKER_00:
And we did the same thing there where we had the concept from the proposal, we accepted it in principle, and then we had a revision review to focus on the name of the keyword, which was originally called transferring, now it's called sending.
NEW_SPEAKER_SPEAKER_00:
But the revision review thread is really interesting because a lot of people are coming in and as part of justifying why they think this keyword should be called something specific, they're reasoning through how they're thinking about the feature and how they would explain it to other people.
NEW_SPEAKER_SPEAKER_00:
And at points where they maybe got something slightly wrong, someone else would come in and say, oh, I think this actually works this way, and I think this keyword's a little bit misleading.
NEW_SPEAKER_SPEAKER_00:
And so that review thread is really cool because it didn't feel like a really heated, contentious debate.
NEW_SPEAKER_SPEAKER_00:
It felt like a healthy debate of people trying to come in and explain a concept and then listening to other people explain how they thought about it.
NEW_SPEAKER_SPEAKER_00:
And that's also valuable for us in figuring out...
NEW_SPEAKER_SPEAKER_00:
how to actually explain the feature to Swift programmers, because what the formal specification is in the proposal is not, you know, the level of detail that you actually need to understand in order to use the feature.
NEW_SPEAKER_SPEAKER_00:
So yeah, those name bike shedding threads are valuable for a bunch of different
John:
Yeah, and that's part of the reason doing it in public I feel like is so beneficial because the people who are working on the proposal know it at such an intimate level.
John:
And then you throw it in a bunch of people who have no idea what you're talking about.
John:
And they will tell you, this is confusing to me.
John:
Like if they're using a term of art that's meaningful to compiler people or you've just all internalized as a group what this means because you've been debating it for a month or whatever.
John:
And the word doesn't make in their mind make them think of what it actually is.
John:
And so changing the word will make it more learnable and more memorable.
John:
And again, the people who don't like bike skating will say, well,
John:
yeah, it's a weird word, but you learn it and then it just becomes internalized.
John:
That's what happens to everybody, but that doesn't make the language approachable.
John:
If you pick a good word, if the word means what you want it to mean, it will help people learn the feature faster.
John:
I definitely find that because, again, some Swift features, I read the proposal and I don't understand it until you change the keyword.
John:
And then I'm like, I read the same proposal.
John:
I'm like, oh, now I get it because the word you've chosen is different and now I understand what you're getting at.
John:
Even non-copyable types was like that because I didn't understand what you were trying to do until it went around a few times.
John:
I'm like, okay,
John:
It's not like the sending or whatever.
John:
And I think you picked that because of the – was it part of the synergy with sendable and everything?
NEW_SPEAKER_SPEAKER_00:
The connection with concurrency.
NEW_SPEAKER_SPEAKER_00:
Yeah.
NEW_SPEAKER_SPEAKER_00:
Previously, it didn't sound like it had anything to do with concurrency.
NEW_SPEAKER_SPEAKER_00:
And so riffing off of sendable in a slightly different form so that it's not like if I'm talking about sendable versus sendable.
NEW_SPEAKER_SPEAKER_00:
Someone did actually suggest calling it like lowercase s sendable.
NEW_SPEAKER_SPEAKER_00:
Yeah.
NEW_SPEAKER_SPEAKER_00:
It's really difficult to talk about.
NEW_SPEAKER_SPEAKER_00:
But sending is close enough that you're, it's very clear you're talking about sending a value over an isolation boundary because that's the term that Swift uses for that concept.
NEW_SPEAKER_SPEAKER_00:
So you have this immediate connection to concurrency and then you can dig in deeper to how it works.
John:
Just don't let the math people know the language.
John:
That's all I'm saying.
John:
Well, it's funny just to kind of reiterate what John said, you know, when I still had a real job and I was working with other Swift developers, it was hilarious the younger ones when our code base was, some Objective-C was largely Swift, but you would bring a young,
John:
typically a younger person who has grown up on more, you know, JavaScript-y languages.
John:
And I think Swift is like that.
John:
And I don't mean that in a bad way.
John:
I mean, in a good way, it's much more approachable.
John:
And then we would, they would look at a file of Objective-C and they would just recoil because it just looks so different.
John:
Like, even though there, I like Objective-C just fine.
John:
I'm not a super fan, but I like it just fine.
John:
But it's so much less approachable, I think in so many ways, because it's so different.
John:
And I think
John:
Those silly arguments about a tilde, one of you said a minute ago, like a tilde or not, and what keyword to use, they really dramatically, in aggregate, can change the whole kind of vibe of a language.
John:
And Swift's vibe, I think Marco had said earlier, or maybe somebody said, you know, there was a window of time where...
John:
It was getting a little architecture astronaut-y, I feel like, but I feel like that's really been brought around in a good way, and I feel like we're heading on a good path.
John:
And those arguments, while I was one of those people that was like, oh my God, why do I care?
John:
But then, just like John said, you think about it for a minute, and you're like, oh no, this is what you two just said.
John:
This is worth arguing about, and I think it's important.
John:
Architecture astronauts are saving your butt, okay?
John:
That's very true.
John:
You're doing a good enough job of architecture astronaut, and you're like, oh, they all went away.
John:
No, they didn't.
John:
They just did their job.
John:
No, that's fair.
John:
That's fair correction.
NEW_SPEAKER_SPEAKER_01:
Yeah, I mean, the goal is very much we have to plot this path, right, between helping people make code correct and also helping make people easily able to bring forth what's on their mind and make it like a low-ceremony language where they don't have to put that many keywords...
NEW_SPEAKER_SPEAKER_01:
And sometimes those two things can be intention, and that's something that the community really helps us work through.
NEW_SPEAKER_SPEAKER_01:
So I think even with concurrency, the strict checking mode, the goal there is to have the compiler help you work through exactly what you're trying to express.
NEW_SPEAKER_SPEAKER_01:
And so...
NEW_SPEAKER_SPEAKER_01:
sometimes we do have to resolve that tension.
NEW_SPEAKER_SPEAKER_01:
And that's really the game of language design, is making sure that we keep that vision of having Swift be as low ceremony as possible, but not any lower than that.
NEW_SPEAKER_SPEAKER_01:
Because if you have no ceremony, then you don't know what's going on.
NEW_SPEAKER_SPEAKER_01:
And right now you're in an untyped language where it's really difficult to understand exactly what the code is doing.
NEW_SPEAKER_SPEAKER_01:
If you have too much ceremony, then you get...
NEW_SPEAKER_SPEAKER_01:
a language more like Java, where you have to write multiple different things to achieve the same result that in Swift would just be like a couple of words.
NEW_SPEAKER_SPEAKER_01:
So yeah, it's plodding that path.
NEW_SPEAKER_SPEAKER_01:
And that's actually something that we think Swift hits the spot of, which is why we think it would be such a great language to expand beyond just its existing app development ecosystem and expand into other places where people want
NEW_SPEAKER_SPEAKER_01:
the performance of a ahead-of-time compiled language that doesn't have garbage collection, whilst also giving you the ability to have a joyful experience writing code, where you don't have to write that much code, and you don't have to fit too much stuff in your head at once.
John:
MARK MIRCHANDANI- Still hanging on to that dream of Swift being the language that spans from the lowest level of the operating system up to scripting.
John:
And there's a lot of programmers who are the potential audience for Swift.
John:
But obviously, a lot of the programmers who are your target audience are Apple employees.
John:
how do you work with the other teams at Apple when it comes to language features?
John:
How does that work?
John:
So to just give an example, like result builders for the SwiftUI thing, non-copyable types, Objective-C interop.
John:
Do you come to them and say, hey, we think I have an idea?
John:
Do they come to you?
John:
What is the interaction with the rest of Apple for language features?
John:
The language features, obviously, they will benefit everybody when they get out there in the world.
John:
But sometimes you look at them, you're like, OK, that was a language feature that was made specifically for teams at Apple so they could adopt Swift faster or whatever.
NEW_SPEAKER_SPEAKER_01:
I mean, I think the way I would think about it is that no feature is ever good unless you use it.
NEW_SPEAKER_SPEAKER_01:
So when we're developing a feature, we really need to do that development with somebody who is directly using that feature.
NEW_SPEAKER_SPEAKER_01:
And ideally, you do that development in real time.
NEW_SPEAKER_SPEAKER_01:
And so when we're working with developers,
NEW_SPEAKER_SPEAKER_01:
a team like the SwiftUI team, we really want to know that something like Result Builders is really going to hit the spot of them being able to create that really expressive API and develop that feature with them and have them use it and give us feedback in real time.
John:
MARK MIRCHANDANI, Are you bringing Result Builders to them?
John:
Or are they bringing the idea of the SwiftUI to you and saying, we need a generic system to do this?
John:
And I don't think SwiftUI in particular is not... So another example would be Embedded Swift.
NEW_SPEAKER_SPEAKER_01:
So obviously we've got a lot of material this week and we've been putting it up actually prior to this week encouraging people to check out Embedded Swift and use it for developing for the Raspberry Pi Pico or the Playdate or something like that.
NEW_SPEAKER_SPEAKER_01:
But we also developed it in conjunction with some of our developers who are working on things like the Secure Enclave.
NEW_SPEAKER_SPEAKER_01:
And we've talked about that's actually one of the
NEW_SPEAKER_SPEAKER_01:
the places where we've adopted it this year.
NEW_SPEAKER_SPEAKER_01:
And so we directly work with them and they inform our thinking about how to target that language mode.
NEW_SPEAKER_SPEAKER_01:
And it really ends up being a better product.
NEW_SPEAKER_SPEAKER_01:
I think if we developed the language ahead of time and then said, here it is, we knew you needed to do some firmware development, here's a language that does it, we would not get as good a result.
John:
And another example of SwiftUI is like the old...
John:
the old limitation for the parameter thing.
John:
So you get 1 through 10 or whatever.
John:
And what was it, parameter packs or whatever thing that goes around that?
John:
Was that an example of like, OK, well, obviously you didn't have that language feature.
John:
They rolled out SwiftUI anyway, and there was this kind of semi-not-well-known limitation or whatever.
John:
And why was the limitation?
John:
There was a language limitation.
John:
Then you could look at that and say, all right, well, our language is failing the team here.
John:
How can we solve that, but not just by hard coding a thing for SwiftUI, but adding a language feature that now is
John:
beneficial to anybody who wants to use it.
John:
But as a side effect, that limitation in SwiftUI is gone.
NEW_SPEAKER_SPEAKER_00:
Yeah.
NEW_SPEAKER_SPEAKER_00:
So parameter packs specifically were a generics feature that I think we always knew we wanted to have because there are such a wide variety of use cases for them.
NEW_SPEAKER_SPEAKER_00:
And SwiftUI ViewBuilder is not the only API that adopted parameter packs last year.
NEW_SPEAKER_SPEAKER_00:
You also see it in Foundations Predicate API.
NEW_SPEAKER_SPEAKER_00:
You see it in WeatherKit APIs because there's a lot of APIs that are structured like that where you have a variable number of things that you pass in and then you get the same variable number of things as your output there.
NEW_SPEAKER_SPEAKER_00:
But I help a lot of people try to express something in Swift every day across a wide variety of framework teams, people writing apps, people on the forums.
NEW_SPEAKER_SPEAKER_00:
And one really important job of my team, the language team, is to take...
NEW_SPEAKER_SPEAKER_00:
see all of these different use cases that people have, and first and foremost, help them use the language as it is today.
NEW_SPEAKER_SPEAKER_00:
In a lot of cases, people are just trying to use some feature that already exists, and they need some help figuring out how to exactly make it work for their specific use case.
NEW_SPEAKER_SPEAKER_00:
And in cases where there is an expressivity limitation in the language, we take all of these different use cases, again, from a variety of different sources.
NEW_SPEAKER_SPEAKER_00:
We use the forums as a big source of use cases for different things as well.
NEW_SPEAKER_SPEAKER_00:
Macros are a really great example of this.
NEW_SPEAKER_SPEAKER_00:
There were a variety of different use cases for frameworks at Apple.
NEW_SPEAKER_SPEAKER_00:
Swift data adopted macros.
NEW_SPEAKER_SPEAKER_00:
The new observation library from last year as part of the Swift standard library uses macros.
NEW_SPEAKER_SPEAKER_00:
But there were also a ton of use cases spinning up on the forums about people who were wanting to do really similar things in their code.
NEW_SPEAKER_SPEAKER_00:
And something that was
NEW_SPEAKER_SPEAKER_00:
awesome during the review process of macros in Swift Evolution was people were trying it out and putting up example macro packages on GitHub.
NEW_SPEAKER_SPEAKER_00:
And that also was a really great example of people actually trying out the feature and seeing how it worked for them at the same time that it was being developed.
NEW_SPEAKER_SPEAKER_00:
And that turned into real feedback that was incorporated into the design.
NEW_SPEAKER_SPEAKER_00:
So yeah, usually the way that these things work out, unless there's some big overarching goal like data race safety, that was a goal that was driven by us.
NEW_SPEAKER_SPEAKER_00:
But a lot of times it's that we're helping so many different people use the language in a variety of different ways, and we can generalize these expressivity limitations into a single language feature that works for everybody.
NEW_SPEAKER_SPEAKER_00:
It's a really interesting process.
NEW_SPEAKER_SPEAKER_01:
Parameter packs is actually, I think, an example where we really feel like we're successfully doing what we try to do, which is have this progressive disclosure where we have these really advanced language features that ultimately are able to produce APIs, help people produce APIs, that you would not know you're using these advanced features when you use them day to day.
NEW_SPEAKER_SPEAKER_01:
You do not know when you go create a view with 11 things in it that actually that is only possible because of parameter packs.
NEW_SPEAKER_SPEAKER_01:
You don't know that when you're
NEW_SPEAKER_SPEAKER_01:
when you've got this really nice api where you tell the weather api to give you like temperature and wind speed it's actually giving you two strongly typed values that then instead of giving you like two untied values like in any type value that you used to have before you immediately get these two strongly type values where you get like code completion on exactly the the the types that you have that that make it so much easier to use um macros is another example where like
NEW_SPEAKER_SPEAKER_01:
The creation of macros was general enough that people were able to create these great new APIs that you do not have to think about when you're using them.
NEW_SPEAKER_SPEAKER_01:
So Swift Testing is another one I know you folks were ragging on the fluent design of other testing frameworks.
NEW_SPEAKER_SPEAKER_01:
And one of the beautiful things about Swift Testing is that you write just regular expressions.
NEW_SPEAKER_SPEAKER_01:
Sorry, I shouldn't say regular expressions.
NEW_SPEAKER_SPEAKER_01:
I can't say that's a jump game.
NEW_SPEAKER_SPEAKER_01:
You write ordinary expressions, ordinary Swift expressions like A is not equal to nil or something like that.
NEW_SPEAKER_SPEAKER_01:
You put them inside a pound expect and then the pound expect macro will do some magic stuff under the hood to do reflection actually exactly similar to what you were talking about where it breaks down the object and looks at all the different properties.
NEW_SPEAKER_SPEAKER_01:
We don't have diffing quite yet.
NEW_SPEAKER_SPEAKER_01:
That's a great idea to...
NEW_SPEAKER_SPEAKER_01:
Maybe bring to the Swift forums and talk about it.
John:
If you just look at any other testing framework, I'm pretty sure they know it exists.
John:
Fair enough.
John:
That's the thing with testing frameworks.
John:
There's so many of them.
John:
There's so much prior art.
John:
NexiTest was a little bit crusty, but you're spoiled for choice.
John:
You just look at all the popular languages and all the testing frameworks, and you've chosen this time not to go with a bunch of words with dots between them, but some people like that.
John:
So I predict that Swift testing, it looks like a great advancement over what came before, but I feel like testing frameworks are difficult to get right on the second or third try.
John:
Going beyond XC tests is great.
John:
We actually had planned to talk to the both of you more about Swift testing, but in interest of time, I wanted to give, or we wanted to give you guys a couple of, the floor to answer a couple of softball questions.
John:
First of all, I'm going to start a little bit negative, and then we're going to end with a positive.
John:
Is there any misunderstanding?
John:
It's more of a curveball.
John:
Yeah, right.
John:
I actually have a statement.
John:
I don't know if it supports me.
John:
Is there any common misunderstanding in the community that maybe grinds your gears or you just feel bad, like I'm trying to make this not so negative, like you just feel bad that people just haven't grokked that, oh, you know, all of us, myself maybe included, think A, but it's actually Z, you know, or whatever the case may be.
John:
And maybe there isn't anything, but if you had, let's say, you know, a couple of minutes to correct some common misunderstanding, is there anything that jumps to mind?
John:
About Swift, not just the one.
NEW_SPEAKER_SPEAKER_00:
Yes.
NEW_SPEAKER_SPEAKER_00:
Yeah.
NEW_SPEAKER_SPEAKER_00:
There is one immediate one that comes to mind.
NEW_SPEAKER_SPEAKER_00:
People in Swift love protocols.
NEW_SPEAKER_SPEAKER_00:
Protocols are great.
NEW_SPEAKER_SPEAKER_00:
I love protocols, too.
NEW_SPEAKER_SPEAKER_00:
But a lot of people, when they're starting to write an app, they start by adding a protocol into their code, and then they end up
NEW_SPEAKER_SPEAKER_00:
using a lot more abstraction than they really needed to in their code.
NEW_SPEAKER_SPEAKER_00:
Like they end up using any types, or if you're familiar with the formal term, existential types, which we try to steer people away from because those are a really complicated feature.
NEW_SPEAKER_SPEAKER_00:
And understanding why they have some of the behaviors they have is really, really nuanced and hard for a lot of people to grasp.
NEW_SPEAKER_SPEAKER_00:
And in a lot of cases, you don't need them.
NEW_SPEAKER_SPEAKER_00:
So I would tell people to start with a concrete type, start with a struct.
NEW_SPEAKER_SPEAKER_00:
specifically until you need more abstraction or you need reference semantics and then sort of evolve from there.
NEW_SPEAKER_SPEAKER_00:
The same thing is true of global.
NEW_SPEAKER_SPEAKER_00:
I've seen so many people write static variables that never change throughout their code base.
NEW_SPEAKER_SPEAKER_00:
So I would tell people to start with a let and that's really helpful for data race safety as well.
John:
I blame, what is it, maybe you know, protocol-oriented programming.
John:
Remember that LWDC session?
NEW_SPEAKER_SPEAKER_00:
I was thinking the same thing.
John:
A lot of people went to that session and were like, protocols, they're the future.
John:
I'm starting every app with protocols.
NEW_SPEAKER_SPEAKER_01:
It's worth re-watching that talk.
NEW_SPEAKER_SPEAKER_01:
What the talk said was, if you're thinking about creating a subtyping relationship, instead of a class hierarchy, start with the protocol.
NEW_SPEAKER_SPEAKER_01:
Unfortunately, what people heard was, start with the protocol.
NEW_SPEAKER_SPEAKER_01:
It's right in the title.
John:
They read the title and they're like, great, I'm on board.
NEW_SPEAKER_SPEAKER_01:
It's the right tool for everything.
NEW_SPEAKER_SPEAKER_01:
It gets to that point where it's kind of like the black box.
NEW_SPEAKER_SPEAKER_01:
Why don't they make the entire plane out of protocols?
NEW_SPEAKER_SPEAKER_01:
That's not what you want.
NEW_SPEAKER_SPEAKER_01:
You want to start from structs, like Holly said, and then generalize your problem when you find you need to generalize it.
John:
That's what programmers do, though.
John:
They generalize it from the start.
John:
Yeah, that's really good advice.
John:
And then finally, because we really are running low on time, what are you proud of lately?
John:
Like, I mean, obviously, and I mean, there's obvious answers like Swift concurrency in the strict concurrency.
John:
It's an incredible land and you should be proud of that.
John:
But is there maybe something that, you know, your pet feature or project or what have you that maybe not a lot of people have seen, like embedded Swift is a great example that, I mean, I've seen a lot of this on the WWDC session titles anyway, but is there something maybe a little more esoteric or just your pet thing that you're really, really into that you're
John:
proud of?
NEW_SPEAKER_SPEAKER_01:
I don't know if it's esoteric, but I think we're pretty proud of the progress we've made around cross-platform support.
NEW_SPEAKER_SPEAKER_01:
And that's especially something that we've been pushing this year.
NEW_SPEAKER_SPEAKER_01:
We have support for more distros this year.
NEW_SPEAKER_SPEAKER_01:
We have now Debian and Fedora.
NEW_SPEAKER_SPEAKER_01:
We've been working with the community on creating this really great plugin for VS Code that allows you to use VS Code if that's what you're into.
Yeah.
NEW_SPEAKER_SPEAKER_01:
Personally, I'm sticking with Xcode, but a lot of people have very personal preferences.
NEW_SPEAKER_SPEAKER_01:
We also have some articles up on how to integrate code completion into NeoVim and Emacs, if that's your jam as well.
NEW_SPEAKER_SPEAKER_01:
So I think we've made some really great progress in that area, and we've seen both internally and in the outside community a lot of more rapid adoption of Swift on Linux environments and on the server generally.
NEW_SPEAKER_SPEAKER_01:
I think if you saw
NEW_SPEAKER_SPEAKER_01:
some discussion in the keynote to the fact that we're now running Swift on the server to do some of the new Apple intelligence features.
NEW_SPEAKER_SPEAKER_01:
And that's all built on this foundation that we've been working on for years with projects like the Swift Neo framework and things like that that have always given us this ability to stand up servers that have this really great ability to, again, have this high-level
NEW_SPEAKER_SPEAKER_01:
language that we feel is really enjoyable to write, but that managed to get you, in the case of the server, really low memory footprints, which can be a big challenge when it comes to large server farms, especially.
NEW_SPEAKER_SPEAKER_01:
And that's been a really big win for us that we're pretty proud of.
NEW_SPEAKER_SPEAKER_01:
World domination is still on the table.
John:
Still on the table.
NEW_SPEAKER_SPEAKER_01:
How about you, Holly?
NEW_SPEAKER_SPEAKER_00:
My team's focus this year was, you know, data race safety and SWIFT 6.
NEW_SPEAKER_SPEAKER_00:
I'm personally really proud of my team because a lot of the team was new to the data race safety model and the concurrency model in general.
NEW_SPEAKER_SPEAKER_00:
You know, at the beginning of this year, originally it was built by...
NEW_SPEAKER_SPEAKER_00:
a smaller group of engineers and then more people got involved in concurrency.
NEW_SPEAKER_SPEAKER_00:
So yeah, I'm really proud of the work that the team has put in, in general, into this release.
NEW_SPEAKER_SPEAKER_00:
And I'm also really excited by how the community has started to adopt these features and surface feedback to us and talk about what's difficult, talk about what error messages are confusing, and sort of seeing the community
NEW_SPEAKER_SPEAKER_00:
really embrace this new model of programming and come to a shared understanding and improve both the compiler and the documentation and the language.
NEW_SPEAKER_SPEAKER_00:
I'm really excited to see where this goes from here.
John:
That's awesome.
John:
Ben Cohen, thank you so much for joining us.
John:
I really appreciate it.
John:
Thank you very much.
John:
Holly Borla, thank you so very, very much to both of you guys.
John:
We really, really appreciate it.
NEW_SPEAKER_SPEAKER_00:
Thank you so much for having us.
John:
And thank you to Apple for hosting.
John:
And with that, I think we're good.
John:
See you next week.