0:00

All right, how are we starting this? You're starting it.

0:02

I'm starting it. OK. You're the host, man. All right,

0:04

well, here we go. All

0:07

right, so hey, everybody. We're doing something

0:09

extremely special today, and I am genuinely

0:11

exceedingly excited about it. And so I

0:14

teased last episode that we would have a little surprise coming

0:16

up. And a little treat is, I think, what I called

0:18

it. And it's actually more than a little treat. It's a

0:20

big treat. So today, we have

0:23

a special guest. But not one special

0:25

guest. We have two special guests. So

0:27

here we have today Ben Cohen, who

0:30

is a software engineering manager for the

0:32

Swift team, and Holly Borla, the Swift

0:34

language engineering manager. We are in the

0:36

presence of greatness. And I don't know how we ended

0:39

up here, but I'm happy about it. So thank

0:41

you, Ben and Holly, for being here. I know I

0:43

speak for all three of us in saying we are

0:45

extremely excited and lucky. So thank you. Thank you very

0:47

much for having us on. Of course. I do interviewees

0:49

very often. So you're welcome, Ola. And actually, just this

0:52

morning, I was watching your video, which was very good,

0:54

and we'll talk about that. But I

0:56

guess, Holly, if you don't mind if you wouldn't

0:58

mind starting, would you give me

1:00

the nickel tour of who you are and what you do? I mean,

1:02

I know, but not everyone knows. So who are you and what do

1:04

you do for Apple? Sure. Yeah. My name's

1:06

Holly. I'm the engineering manager of the

1:09

Swift language team, like you just said.

1:12

My team focuses a lot on the user-facing

1:14

language features like the generic system, type inference.

1:16

And this year, our major focus has been

1:18

the concurrency model and specifically,

1:20

data race safety and Swift 6. Before

1:23

I joined the Swift team, I was a Swift

1:25

programmer working on Xcode. And before that, I was

1:28

a computer science student at the University of Michigan.

1:30

That's incredible. And Ben? Yeah. So

1:32

my name is Ben Kern, and I manage the

1:35

Swift team overall. So that includes the language, but

1:37

also the back end, the optimizer,

1:39

a lot of the tooling that goes around the

1:41

language, like code completion and things

1:43

like that. At Apple,

1:45

about eight years, I worked on various parts

1:47

of the Swift compiler, including the standard library,

1:49

the optimizer. And before that, I was not

1:51

a compiler engineer. So I was

1:54

actually working in sort of fintech type stuff. So

1:56

I'm going to really make John happy. I'm going

1:58

to jump right in. Immediately. Jump right

2:00

to the end. Right to the end. We're

2:03

not doing follow up then, is that? No, we're

2:05

not doing follow up this time. Well, I guess in

2:07

real time follow up, how did you end up, and

2:09

I'm asking both of you, but Ben, since you most

2:11

recently spoke, we'll start with you, how do you end

2:13

up being a compiler engineer? Because my perspective as a

2:15

Swift developer is there's people like

2:17

me who kind of know what we're doing, and then

2:19

there's compiler engineers who really know what

2:21

they're doing. It's like a priesthood where you're a programmer

2:24

and you write the thing, and then if there's something

2:26

wrong with the compiler, you're like, oh, it's not my

2:28

fault. There are people in

2:30

an ivory tower somewhere that make this work, and

2:32

they're crossing over that path.

2:34

I know there's lots of advertising for job positions that say,

2:36

you don't need compiler experience, just come, be on the team,

2:38

we'll teach you. Well, that is true.

2:41

You do not need compiler experience. In fact,

2:43

I think actually neither me nor Holly had

2:45

direct compiler experience before joining the

2:47

Swift team to work on the language, to have

2:49

a high tolerance for pain. So

2:54

actually I came to Swift through pain

2:56

from other languages. That is such a

2:58

good answer. You sure are not in PR. So

3:02

my love for Swift comes from the fact

3:04

that I have experienced what other languages have

3:07

to offer. And there are,

3:09

you know, I've always been the language

3:11

enthusiast. And so whether it's Java

3:13

or C++ or higher level languages

3:16

like Ruby or Perl, there's something

3:18

great about all of these different languages. But

3:20

I always felt historically like these languages had

3:23

compromises. They were either a little bit too

3:25

slow because they were more dynamic and scripting

3:27

based or they were unsafe

3:29

like C++ or really hard to comprehend

3:31

like C++. True

3:33

story. And

3:35

my background is actually I used to

3:37

work on trading systems and performance

3:40

is really important in trading systems. And so we

3:42

used to do a lot of things in C++, but at the

3:45

same time, safety is really important in trading

3:47

systems. So you do not want the machine

3:49

to do the wrong thing. And

3:51

so we always used to have this trade off between like C++

3:53

and Java. And when

3:56

I saw Swift 10 years ago now, I

3:59

was actually blown away by

4:01

the fact that it actually managed to find the

4:03

sweet spot between those different things. It was deterministic,

4:05

it didn't have a garbage collector, but

4:08

also it had that like higher level feel. It

4:10

does sometimes look a lot more like sort of

4:12

the Ruby-like language where it's really joyful to programming

4:14

and it's really great

4:16

to see. That realized in things like SwiftUI

4:18

where it's like brings back that joy of programming

4:20

that I think sometimes we lose a little bit.

4:22

And so that was what brought me to Swift

4:24

and I joined Apple originally. I was I was

4:26

actually a library developer. So

4:28

I didn't have that background in compilers, but I did

4:30

have that background in like writing algorithms and data structures

4:33

and things like that. And that was a really nice

4:35

route in and from that I learned about compiler performance

4:38

and from that got more into the general

4:40

language design and that's that's how come I

4:42

ended up here. And then

4:44

Holly you said you started working in Xcode is that

4:46

right and then kind of meandered from there. What was

4:49

that story like? Yeah, that's right. So I actually signed

4:52

up for a mentorship program that the

4:54

developer tools organization offered. And

4:57

they deliberately paired mentees

4:59

up with mentors from different parts of the

5:01

organization so that you could get to meet

5:04

people who you didn't work with on a day-to-day basis

5:06

and I got paired up with a Swift compiler engineer

5:08

and that sort of sparked my interest

5:10

in actually joining the team. So

5:13

for me, I feel like I became a compiler

5:15

engineer by accident. What brought

5:17

me to developer tools at Apple is I was

5:19

really interested in in education for programming. I also

5:22

ended up studying computer science sort of by

5:24

accident. I didn't go into

5:26

university knowing anything about programming or

5:29

computer science like a decade ago today. You

5:32

know, it's Swift's 10-year anniversary. 10 years ago, I knew

5:34

nothing about programming. I was graduating high school. Set

5:38

to study dance at

5:41

the University of Michigan. And

5:43

engineering was sort of my backup and all engineers

5:45

have to take a programming class and I really

5:48

enjoyed it and that

5:50

I think for me really showed

5:52

the power of making Swift or not

5:54

Swift, making programming more approachable to people

5:56

who weren't exposed to

5:58

that previously. So I thought

6:01

working on developer tools was a

6:03

good way to do that. And that was how

6:05

I started to learn Swift when I joined the

6:07

Xcode team. The part of Xcode

6:10

that I worked on had just

6:12

been entirely rewritten in Swift. So

6:14

yeah, it was this series of opportunities that

6:16

led me to really becoming interested in working

6:19

on the Swift language itself. And

6:21

now this is sort of the ultimate opportunity to

6:23

make programming more approachable to

6:26

people who have an idea

6:28

and are interested in bringing that to

6:30

life through code. I love that. And

6:33

I'll throw Marco under the bus with me, because

6:35

I can tell you that Marco and I went to

6:38

school for CS and computer engineering. And I

6:40

cannot fathom a situation where engineering is like my

6:42

fallback. Like, oh, I'm sure I'll be fine in

6:44

engineering if this other stuff doesn't work. That's incredible.

6:47

I just couldn't dance. That was my problem. So

6:49

I'll hear stories like an after-school special of

6:51

how you can slippery slope into the seedy

6:53

world of compiler engineering. She started

6:56

out as a promising dancer, but somehow the compiler people

6:58

got her. And now look at her. Now I'm going

7:00

to continue to make John upset by

7:02

continuing to be at the bottom of the document. But I promise John,

7:04

I will come back up to the beginning. At least you're in the

7:06

document. There's that. You're

7:09

doing great. We have a structure. We're

7:11

sticking to it. Are we? Well,

7:13

this is our structure, despite what John says. It's not

7:15

copyable. John, have you heard the show? Right. So

7:19

Ben, you were very rightfully, in my opinion,

7:21

slagging on C++ just a few minutes ago.

7:23

But last I heard... Guess what? The

7:26

Swift compiler is mostly right. Well, that's exactly what I was going to say. So

7:29

last I remember hearing, the

7:31

Swift compiler, the last I looked, the Swift compiler is

7:33

largely, if not entirely, C++. So you're pointing at

7:35

me, wait, there's more. So

7:38

tell me, is there more? There is more. So

7:40

the compiler, I actually don't

7:42

have the right percentage. It's actually slightly difficult to

7:44

tell because if you look at the GitHub repo...

7:46

Oh, yeah, yeah, yeah. It gives you lies because

7:49

for two reasons. One is like

7:51

we have a lot of tests written in

7:53

Swift and those shouldn't count, right? Right, right,

7:55

right. But also we have started the process

7:57

of writing parts of the compiler in Swift.

8:00

Swift. And that started quite

8:02

a while ago now, I think maybe four years ago now. But

8:05

when we do that, we actually create those bits

8:07

of the compiler that we rewrite as packages. And

8:09

when you do that, we break them out into

8:11

a separate repo. So you go to github.com/apple,

8:14

for now, soon, Swift-lang,

8:19

slash Swift-driver. That was the first part of

8:21

the Swift compiler that we started rewriting in

8:23

Swift. That happened about

8:26

four years ago. And the driver is

8:28

basically the way into the front end

8:30

of the compiler. So it's the thing that does

8:32

the initial processing of your command lines, and it

8:34

organizes the build, and things like that. That

8:37

was written in Swift. Two

8:39

years ago now, we started rewriting the parser

8:41

in Swift. And so that is

8:43

actually part of a wider project called Swift Syntax, which

8:46

is itself written in Swift, which is originally a

8:48

way of just manipulating Swift code. It was a

8:51

library for manipulating Swift code. And

8:53

that evolved into a replacement for our current C

8:55

plus plus parser. That is actually a foundation for

8:57

macros. So last year, when we introduced macros, those

9:00

are based around Swift syntax and the Swift parser.

9:02

We have some ongoing work that's

9:05

happening at the moment to do the next

9:07

layer down, which is what's called

9:09

AST generation. So what you do is you parse the

9:11

code, and then you turn it into an abstract syntax

9:14

tree. And then you have to

9:16

lower that down into the underlying representation. That

9:18

is ongoing at the moment.

9:21

And once we've done the AST Gen layer, we

9:23

will actually be throwing away the

9:25

C plus plus parser. Now, that's going

9:27

to be an interesting moment, because that is

9:29

the point at which there is no way back. That

9:32

is the point at which you will need a Swift compiler to

9:35

build Swift. You know who's going to look back in the good

9:37

history? It'll be right there. It's still there, sort of. Well, it

9:39

is actually an interesting thing, because we

9:41

have, I know app developers sometimes

9:44

point out that they have to wait a year or

9:46

two before they can raise their minimum deployment target in

9:49

order to use SDK features. We

9:51

as compiler authors know

9:54

that pain, because we cannot use the

9:56

very latest Swift features when

9:58

implementing the Swift compiler, because we cannot use it. you have to be

10:00

able to use the shipping compiler in order to bootstrap. So

10:03

we're very familiar with that. But yeah,

10:05

and then more

10:08

recently than that, we have started

10:10

writing optimizer passes in Swift. So

10:12

that is actually using C++ interop,

10:15

which is another important feature of Swift. We

10:18

obviously interpret with LVM, which is written in C++.

10:21

And we use that to build our optimizer passes to

10:23

do things like hoist variables out of loops and

10:27

things like that. And those are now written in Swift

10:29

as well. We are getting there. It'll

10:31

be a ways away. It's

10:34

not our main goal. We don't rewrite things for the

10:36

sake of it, even though it's written in C++. It's

10:39

working. And so really, when we decide

10:42

we want to do something where we want to rewrite a

10:44

part of the compiler, we try to make it for a

10:46

good reason. And those good reasons

10:49

can be, for example, creating a macro

10:51

system with a nice, friendly Swift API.

10:53

Or when we rewrite the optimizer passes, we

10:56

usually do it in order to simplify them and

10:58

make them more effective. Yeah,

11:01

so we are on that

11:03

path to self-hosting. But it's going to

11:05

feel really good when you have to delete that code, though. It

11:08

feels very good to delete code. So Bill, I'm

11:11

not sure which one of you is more appropriate

11:13

to answer the following. But building on that, it

11:15

certainly seems the implication is there is a strong

11:17

interest to become self-hosted. And

11:19

I'm not sure I'm the best person

11:21

to summarize that. But basically, the Swift compiler is

11:23

written in Swift. And is it fair to say

11:26

the eventual, I'm not looking for a

11:28

date, but the eventual one-sometime goal would

11:30

be to self-host entirely, if possible? Is that

11:32

fair to say? We don't comment

11:34

on future products. Well, this is

11:37

not a product. This is the Swift language that

11:39

is entirely open source. And we are perfectly liberty

11:41

to comment on. So yes, I think the ultimate

11:43

goal is that the compiler should be written in

11:45

Swift. If nothing else,

11:48

it does improve the safety of the compiler.

11:51

The compiler is not filled

11:54

with segfaults. It's

11:56

idle. They can happen. And

11:59

obviously, we're not going to do that. rewriting parts of it in

12:01

Swift to eliminate that possibility because it's a safer language.

12:04

And so that's one benefit that comes from it

12:06

as well as bringing other features. The other benefit

12:08

is it makes it more approachable for outside people.

12:10

I mean, you were talking about working on the

12:12

Swift compiler as if it's a very intimidating thing, but

12:14

at the end of the day, it's actually

12:17

kind of pretty straightforward code. When you

12:19

look at a small part of it, right, when you

12:21

look at a particular optimization pass, you

12:23

know, you can usually see pretty much what it's doing. And it's

12:25

actually a great opportunity to get

12:27

contributors involved. I know Holly's worked with quite a

12:29

lot of people who come new to the Swift

12:32

programming language as well. Yeah, we also

12:34

organized a mentorship program called the

12:36

Swift mentorship program, where open

12:38

source contributors who are interested

12:40

in contributing to various parts of the Swift

12:42

project, including but not limited to the compiler,

12:44

they sign up, they get paired with someone

12:47

who regularly contributes to the compiler, and they

12:49

work together for 10 weeks on open source contributions.

12:53

And a lot of people, I find that a lot

12:56

of people who write Swift, who are iOS developers are

12:58

really interested in making some contributions

13:00

to the compiler, just as a

13:02

learning experience or better understanding, you

13:05

know, how their code works, if you're in the depths of

13:07

how, you know, type

13:09

inference or the actor isolation checker works, it

13:12

gives you a little more knowledge into, you

13:14

know, how the compiler sees your code when

13:16

you're writing Swift code. So

13:18

yeah, it's a cool program and a really

13:21

good learning experience for people who are writing

13:23

Swift. And I completely agree that moving

13:25

more of the compiler over to Swift will make

13:28

contributing to the compiler a lot more approachable for people.

13:30

So I can include the standard library, like if someone

13:32

wants to add a method that says first, second, third,

13:34

spelled out fourth, fifth, sixth, and you stop them when

13:37

they get to 32nd. Like

13:39

that's all Swift code in the standard library. So you can

13:41

contribute to that and say, hey, I contributed to the Swift

13:43

language, but you're just making Swift methods in the library. So

13:46

I'm curious, you know, and probably for Holly, as

13:49

we go into this new era of Swift

13:51

concurrency and data race safety and everything, Swift,

13:54

I think has always struck

13:57

an interesting balance. I think it's

13:59

kind of a roller coaster. Sometimes it's more successful

14:01

than other times at this balance of being

14:04

easy to use for non-experts or

14:07

newbies to a language or

14:09

just new programmers, and also

14:11

having all this power behind it and having

14:13

quite a bit of complexity behind it. As

14:17

we go into this new data race safety

14:20

era, how do you

14:22

strike that balance? Obviously, these are

14:24

some very advanced concepts, and as somebody

14:27

might get some warning

14:29

as they're building their code, saying something's not sendable

14:31

because it has mutable state, and

14:34

they might not even know what any of that

14:36

means. How do you balance that with being approachable

14:38

to new programmers or to less experienced programmers? Yeah,

14:41

so the goal for concurrency is

14:43

really similar to what we've accomplished with other

14:45

advanced features of the language, like the generic

14:47

system is the one that I always go

14:50

to, because from the very

14:52

first lines of code that you write in

14:54

Swift, you're using the generic system because you're

14:56

using standard library types like array, or

14:59

you're using frameworks like SwiftUI, which are

15:01

really heavily leveraging these advanced features to

15:04

make APIs that are really natural to

15:06

use for programmers. But you

15:08

don't need to understand generics. You don't need to understand

15:10

how it works until you're at a point where

15:13

you need to use those advanced features in your

15:15

own code. And that's the end

15:17

goal with concurrency as well. For

15:19

newcomers to app development or newcomers

15:22

to Swift, when you're writing code,

15:25

by default, that code should be on the main actor.

15:27

And you shouldn't have to actively think about the fact

15:29

that that code is on the main actor until

15:31

you're trying to actively introduce

15:34

concurrency into your project. And

15:37

at that point, you'll be confronted when

15:39

you make a mistake that can lead to a data race

15:41

in your code. And I think that

15:43

both the progressive disclosures is

15:45

the way to make that complexity more

15:47

approachable. But I also think introducing

15:50

those checks at compile time will

15:54

also make learning to write concurrent code

15:57

a lot more approachable for people who are new

15:59

to concurrency. in general. Concurrent

16:05

programming is just notoriously really hard to

16:07

get right. I don't know if you've

16:09

ever debugged a data race before, for

16:11

those of you who are listening, but

16:15

if you have, you know that it can take days or even weeks. The

16:20

introduction of dispatch even was a huge step forward for making

16:22

concurrent code easier to write. The

16:25

way you dispatch queues is way easier

16:27

than managing low-level system resources like threads

16:29

manually in your app. But

16:31

you still have to know when to apply

16:33

those tools to protect mutable state in your

16:35

code. And with data race safety in Swift 6,

16:38

you can't get it wrong. The

16:42

compiler will tell you if there's a risk of a data

16:44

race in your code, and

16:47

having to confront those concepts at the point when you

16:49

make a mistake it's

16:52

better for forming

16:54

a mental model of how concurrent code should

16:56

be written in your project. So I'm really

16:58

excited for people to start to learn concurrency

17:01

for the first time with data race safety in

17:03

Swift 6, as opposed to I think a lot

17:05

of people right now have internalized how to use

17:07

dispatch, and they've been using that for many years,

17:10

and now they're trying to learn this other... It's

17:14

not a completely different system in how you write code,

17:16

but it is different in how you approach it, and

17:18

at what point you're confronted with the issues. And

17:21

I think that might be a little bit more difficult

17:23

than learning concurrency for the first time with the compiler

17:25

checks in place to help prevent you from making mistakes.

17:28

Is that how you characterize the difference

17:30

between the Swift concurrency and the predecessor

17:32

concurrency systems at Apple? We've had in

17:35

GrandCeler dispatch, the dispatch queues, the

17:37

NSOperation queue, but pthreads back in

17:39

the day, locks of various kinds

17:41

over the years. And all of

17:44

those were kind of... You'd have sessions on them and

17:46

they'd say, you could properly use this, here's

17:48

how many queues you should have, and stuff like that,

17:50

but it was all sort of like runtime stuff, and

17:53

everything I hear about Swift concurrency is always, we will

17:55

do these checks for you at compile time, so that

17:57

you don't have to run your thing to see if there's a

17:59

problem, or audit the code and look over it. This

18:02

is like the compiler that will check it for you and make

18:04

sure it's mostly OK. Would you

18:06

say that's the big difference? Yeah, absolutely.

18:08

You should be able to program by bumper, where

18:12

the compiler is there to tell you, oh, no,

18:14

you got this a little bit wrong with actionable

18:16

suggestions for how to fix that code. So you're

18:18

talking about the progressive disclosure and you don't have

18:20

to know about this until you start introducing concurrency.

18:22

But I feel like that's true

18:25

of the Swift language if you're writing just Swift code.

18:27

But once they have, everyone else in this company makes

18:29

a bunch of frameworks. And those don't know

18:31

or care about Swift concurrency, for the most part. And

18:34

they're in your code. And you think,

18:36

I haven't introduced any concurrency. But it's

18:38

like, well, this method has a callback.

18:41

And it is cranky now. And you're

18:43

like, but why? I didn't make

18:45

that API. It's complaining about something

18:47

that I don't understand. It's not an API that I

18:49

wrote. And so you're like, you're faced with

18:51

this dilemma of just, you stare at it for

18:53

a while. It's like, should I not use that API?

18:56

Should I? I

18:59

think we've all had experience, and everyone you've probably talked

19:01

to has had experience trying to enable strict concurrency in

19:03

5.10. So when you set the setting

19:05

in Isecode, you see all the warnings. And you're like,

19:08

how far away am I really? You're like, how many? And

19:10

I think we've all taken different swings at this. And I've

19:13

seen you both counter the conventional wisdom. It's like, I'll just

19:15

make everything sendable. And that will fix everything. But that doesn't

19:17

work. And so you're like, well, maybe I can just add

19:19

annotations. I'll put main actor on a bunch of things. But

19:21

that doesn't work. And it's like, well, maybe I'll just sprinkle,

19:23

assume isolated everywhere. And it's like, well, that's probably not the

19:25

right approach. My personal

19:28

experience is I've taken four different runs at

19:30

bringing one of my apps on to strict concurrency. And I

19:32

just keep backing off and scratching my head. I know there's

19:34

a WWC session about it, and I haven't seen it. My

19:37

bad. It was a busy day yesterday. And it's migrating

19:39

to SwiftConchurts. But I feel like that is a lot

19:41

of the barrier. And it's nothing to do with the

19:43

language. It has to do with the APIs that we're

19:45

using that were created decades ago that have

19:47

their own conventions and strict concurrency. And it's not wrong.

19:49

It's correct. There is a potential for a mutable state

19:51

to be messed up there. And then, of course, even

19:53

in our own code, it's like, well, I use queues

19:55

for this. And I use locks. And

19:58

I'm pretty sure it's safe, but strict concurrency says. Well,

20:00

that's what unchecked sendable is for. Yeah, but that's the

20:02

whole thing. You don't want to go through and sprinkle

20:04

it through. It says, I'm sure this is OK. I'm

20:06

sure this is OK. There are annotations to do that,

20:08

but all you're doing is undercutting yourself by saying, no,

20:10

I'm totally sure the code I wrote last year is

20:12

bug free and there's no races. And it will satisfy

20:15

the compiler, but you haven't actually solved the problem. You

20:17

haven't actually used the system you're saying, which is you

20:19

should be able to write it. The compiler tells you

20:21

whether it's wrong. You might as well just

20:23

turn that mode off. So I

20:25

think a lot of users find it frustrating, but it

20:27

is a difficult problem. And I'm assuming, well, you tell

20:30

me what you think the correct approach is. Give me

20:32

the three second summary of the session that I didn't

20:34

watch. I'll let Ben

20:36

do that in the spend session. It

20:38

is, and I'm for Casey for getting ahead of

20:40

John and watching it already. So

20:44

it really partly depends on what kind of frameworks

20:46

you're using, and it's possible that you're using some

20:48

frameworks that

20:51

make it harder or easier, depending on what

20:53

kind of code you're using. Mac frameworks. Oh,

20:56

you're screwed. So

20:58

for example, at the

21:01

UI layer, we've actually, and it's worth trying the

21:03

new SDK, because at the UI

21:06

layer, there's been a lot of work to

21:08

indicate which parts of Swift UI, also UI

21:10

kit and the app kit, are by definition

21:12

always supposed to be running on the main

21:14

thread. And that should

21:16

actually, for people who've tried 510, it's

21:18

well worth downloading the new SDK and giving that

21:20

a go. Does that also include, like, I know

21:23

this is a documentation issue, but often you'll see a thing with

21:25

a callback, and you have a question. What

21:27

thread will the callback run on? And you're just

21:29

like, oh, you're just supposed to know. Whatever you

21:31

thread you register it on, that's the thread the

21:33

callback will run on, but you don't see that

21:36

many documentations. You're like, well, I registered for this

21:38

on the main thread. And when the callback gets

21:40

called, it will probably get called on the main

21:42

thread. And sometimes they take a queue as an

21:44

argument, and you just have to know that the

21:46

main queue is the same as the main thread.

21:48

But documentation-wise, I always feel like I look up

21:50

one of these old app kit things, and it's

21:52

guesswork. Well, but did you know, John, I learned

21:54

this morning that there is a keyword there. What

21:56

is it? Assume, assume, main thread? Yeah, assume oscillators.

21:58

There it is. Main act, adopt, and analyze. And

22:00

you couldn't quite get there. But there's tools for

22:02

this, John, as it turns out. So you have

22:04

to do one over. I know about Assume Isolated.

22:06

That's not a tool for that. You're nuts. Don't

22:08

do that. Assume Isolated, all it's going to do

22:10

is throw a runtime error when it finds out

22:12

it's not on the main thread. Yeah, don't do

22:14

that. It's like a scenario, right? Just dispatch it

22:16

to me. So Assume Isolated does throw a runtime

22:18

error when you're not on the main

22:20

thread. This is actually something that a lot of good

22:22

programmers are already doing, which is they put in preconditions

22:24

where they know this is supposed to be on the

22:27

main thread. And they put

22:29

in precondition just in case they call it from somewhere

22:31

else in their app where they're getting a call

22:33

from a dispatch queue that's not isolated to the

22:35

main thread. And that

22:37

can lead to trouble. I think somebody

22:40

was saying earlier, you run

22:42

your program and you find out it doesn't quite work as

22:44

opposed to compile time. You find out that you need to

22:46

do something. Yeah, it feels like it's undercutting the bumper thing

22:48

Holly was saying. It's like, I don't want to find out

22:50

at runtime. So every time I do Assume Isolated, I'm like,

22:52

there must be a better way. Don't use

22:55

that there, man. That's not what it's for. So

22:57

I would say that finding out at runtime that

22:59

your code is broken is the best case scenario

23:02

under the old world, which is that you

23:05

really hope to find out when you run

23:07

your code that something is wrong. But what

23:09

actually happens is that in some

23:13

of these techniques, you

23:16

find out in the wild when your program is

23:18

crashing and you do not exactly know why. I'm

23:21

always amused by people that make these jokes

23:23

on Master and on Twitter where they say

23:25

like, they make a joke about concurrency where they

23:27

jumble up the words. And

23:29

that's cute. But that is, again, the

23:31

best case scenario is jumbled up words.

23:33

That's very benign. What's worse is like,

23:35

you crash, you corrupt user data. This

23:37

is no good. And so

23:40

that's why a lot of people have these really great practices in

23:42

the old world of dispatch where

23:44

they will insert these assertions saying,

23:48

I want you to stop me if I'm not running on

23:50

the main queue. So I think

23:52

the long term goal is that we

23:54

need to lift this

23:58

information out of documentation. want

24:00

to take it out of documentation and put it actually

24:02

in the definition of the API. It's not in the

24:04

definition now, so you don't have to lift it out

24:06

of the door. Wow. So

24:11

the benefit of putting it there so that

24:14

the compiler actually enforces it is that you

24:16

can't not have that information. By

24:18

definition, your code does encapsulate the information about where

24:20

you are running and how it's running. Because one

24:22

of the things I do when flailing is there's

24:25

a callback, and I'm like, can I just annotate

24:27

the callback as main actor? And the answer is

24:29

no, you can't. And

24:32

then it's like, why? Is it always on

24:34

the main thread? I figure what

24:36

the error is. Just wait for the framework to be updated with

24:38

async calls. Yeah, well, you don't have all the time in the

24:40

world to wait. When

24:43

it comes down to, you mentioned queues, right? So

24:46

one of my apps has concurrency. I'm sorry, it does. And

24:49

I use queues. And in

24:51

one situation, I wrote a little class, and I

24:53

used locks, old style locks. And pretty

24:56

sure it's probably OK. But

24:58

I look at that, and I'm like, I would like to use

25:00

Swift concurrency because then I would feel more sure. But

25:02

there's nothing you can do to sort of

25:04

annotate or markup dispatch queues or locks other

25:06

than the reassurance of just telling

25:09

the compiler, I'm pretty sure that I'm right.

25:11

I would rather just pull that out and

25:13

reimplement it with actors and

25:15

so on. And that sometimes just

25:17

seems daunting. So another

25:20

thing, there's a ton of Swift code out

25:22

there, and Swift code that interoperates with C-based

25:25

languages like Objective-C and C++. We're

25:28

at the start of this transition

25:30

to start to integrate

25:32

Swift's native, safer concurrency primitives

25:35

into these vast code bases

25:37

that are using older library-based

25:39

concurrency primitives, like dispatch queues.

25:42

The system is designed for incremental migration. So

25:44

in the case if you have a class

25:46

backed by a dispatch queue, there is a

25:48

technique that you can use to turn

25:51

that class into an actor that's backed

25:53

by a dispatch queue. It

25:55

uses a fancy feature called Custom Actor Executors. But

25:57

the way to do it, it's only like four.

26:00

or five lines of code that you actually have to

26:02

write in your own code. And what that lets you

26:04

do is from your Swift code, it lets you use

26:06

the static actor isolation and

26:08

not have to mess with the dispatch queue. But

26:10

when you're interacting with APIs that are based on

26:13

dispatch queues, you can still pass the dispatch queue

26:15

there. And then you

26:17

can bridge between the dynamic isolation in

26:19

the static world with tools like assume

26:21

isolated. That back to another question of

26:24

incremental adoption. I know, so this Swift

26:26

6 just came out. And in

26:28

the old five world, we had the little setting to set it

26:31

on complete concurrency, whatever. I know there's a whole bunch of features

26:33

in Swift 6 and new things for

26:35

set and ability and everything that make

26:37

it easier. But what is the mechanism

26:39

in your project of saying, is

26:42

it per module? Is it per file to say, I

26:45

want the Swift 6 language features, but this file is

26:47

not ready for strict concurrency? What does that look like?

26:49

Yes. Yeah, the setting is per

26:52

module. So in your Xcode build settings, there's

26:54

a language version setting. Or if you're in

26:56

a Swift package manifest, there's an API for

26:58

setting it per target. And many

27:01

people currently have that set to something, whether it's 4,

27:03

4.2, or 5. So

27:06

you would change that to 6 for the

27:08

specific module that you're looking to migrate to

27:10

Swift 6. And then if you have a

27:12

particular file that violates

27:15

some of the rules in ways that

27:17

are really difficult for you to change,

27:20

there are ways to opt out of

27:22

checking in specific areas in your project

27:24

using things like pre-concurrency import statements. If

27:27

the issue is in an API that you're using, or

27:30

tools like non-isolated unsafe, if you have, for

27:32

example, a global variable that you're manually guarding

27:34

with a lock or a queue, at the

27:36

point when you access it, you can use

27:38

non-isolated unsafe to opt out of the compiler's

27:40

checking there. So there are a variety of

27:42

tools like that to let you opt out

27:44

of the checking in narrow situations in your

27:47

code. And then those are also

27:49

things like handles that you can audit for later

27:51

to actually take a

27:53

look at the opt dots that you're using in your

27:55

code and try to use those

27:57

as refactoring opportunities to. rewrite

28:00

some of that code to use something safer. So

28:02

you're picking the Swift 6 as the language, and that

28:04

includes everything having to do with Swift 6. When you

28:06

pick Swift 6? No. No. So Swift

28:09

6, the language mode, where you go into

28:11

the Xcode settings and you say language mode

28:13

of Swift 6, that purely

28:15

governs the strict concurrency checking. So the

28:17

Swift 6 compiler that you get with

28:20

the latest Xcode, that has all of

28:22

the new features. So I think you

28:24

made a glancing blow to non-copyable types.

28:27

Those features are available. New

28:29

generic capabilities, non-copyable types are available in the Swift 6

28:31

compiler. You do not need to turn on. So you

28:34

would pick the Swift 5 language mode, but it's using

28:36

the Swift 6 compiler to run in

28:38

Swift 5 language mode. You get non-copyable types. You

28:40

don't get the strict concurrency. That's right. And that's

28:42

exactly, this is part of a journey that the

28:44

entire Swift ecosystem needs to go through. So

28:48

being ready for Swift 6, having your dependencies ready for

28:50

Swift 6, there's actually a

28:53

Swift package index.com, which is this great website.

28:55

They have a tracker now that

28:58

tells you which packages they are compiling

29:00

that build clearly under Swift 6 code.

29:02

But it really does depend on

29:04

the nature of your program and whether your dependencies

29:06

are now ready for Swift 6, whether you want

29:08

to turn on that language mode. And this dates

29:10

back to, we've been doing this now

29:12

since the Swift 4 days. So since

29:16

we introduced the Swift 4 language mode, we've

29:18

always had this source compatibility

29:20

guarantee promise that whenever you download

29:22

the new compiler, with

29:26

a couple of exceptions where maybe there are

29:28

a couple of issues with your code where maybe the code

29:30

was explicitly incorrect, we always

29:33

want you to be able to compile

29:35

your code as is with the latest

29:37

compiler. And then when you're ready for

29:39

some breaking change, there were

29:41

a few in Swift 5 and obviously in Swift 6. The

29:44

key change here is strict

29:46

concurrency. You're then able to turn

29:48

it on on a per-target basis.

29:50

Is that a longstanding marketing

29:52

decision to tie them to the, I mean,

29:55

just deciding that Swift 6 means strict concurrency?

29:57

You could have, for example, said Swift 6

29:59

just means Swift 6 language. features and there's

30:01

some other option for strict concurrency. And he

30:03

said, no, we're tying this feature to this

30:05

number because people want the higher number. Is

30:07

that like a sort of a social

30:09

engineering decision? Yeah, it's a way of thinking about the

30:11

forward progress. I mean, you don't want to be stuck

30:14

in this world with the

30:16

Python 2 to 3 transition-style thing, right?

30:18

Where those were tied to updating

30:21

your compiler, and then you couldn't get

30:23

the new stuff without changing your code

30:25

to adapt to the way that the

30:27

new language works. So it's this way

30:29

of helping engineer the ecosystem to help

30:31

have this continuous forward progress. But at

30:33

the end of the day, some people

30:37

have written code in such a way that it won't

30:40

be so easily adapted to strict concurrency. Some people

30:42

have written code using a lot of new frameworks

30:45

and a lot of async await. And the path

30:47

for them is actually pretty clean. And so we

30:49

want people to be able to opt into that.

30:52

The choice as to whether you opt in or not is up

30:54

to you. If you're finding that you are

30:56

experiencing quite a lot of pretty

30:58

gnarly crashes, it's probably worth considering opting

31:00

in. One great

31:03

time to opt in is if actually you

31:05

want to start introducing a lot more parallelism

31:07

into your code, right? So we have these

31:09

powerful new devices. They have many cores. And

31:12

you might find yourself with an app that previously was

31:14

doing most of its work on the main thread with

31:16

a little bit of background processing, but you really want

31:18

to take advantage of a lot more parallelism in your

31:20

code. That would be a great time to turn on

31:22

Swift 6 mode in order to know

31:25

that you can do those refactorings without

31:28

fear of introducing new data races. So

31:31

yeah, it's really up to each individual project to

31:33

make that decision and to see how

31:36

the community is moving forward with them in

31:38

order to update their dependencies and

31:40

then take the plunge. Do you worry about

31:42

releasing Swift version 10 many years from now?

31:45

And huge code bases are still

31:47

in Swift 5 language mode. They're

31:49

using a Swift 10 compiler to run Swift 5

31:52

language mode because they could never get the wherewithal

31:54

to go stricken currency compliant. And you're just plowing

31:56

bravely forward here at Apple for making version after

31:58

version. And they're all great. But they can never

32:00

cross the sixth threshold because they can never get their

32:03

code to run out of stricken

32:05

currency. There's millions of lines of dispatch queue and

32:07

manually created locks. Do you worry

32:09

about hindering your parks? You've basically made a hard

32:11

gate of you're not going to be running a

32:13

Swiss 7 next year or whenever if

32:16

you can't go stricken currency. And you're like, well, my reason I

32:18

can't go is because we have 10 million lines of manually managed

32:21

locks or something. So it

32:24

really only governs a handful of things. The

32:27

goal is always, whenever we introduce a new language feature that you

32:29

do not have to update to the new language mode.

32:31

We were looking at somebody's project yesterday where they were still

32:33

on Swift 4 mode. And

32:35

really, there was not that much they were missing out on. So

32:40

we have this long-term promise

32:43

to always support those language features

32:45

so that people aren't forced to update.

32:48

But like I say, most of the language features themselves

32:50

are not gated on the language version. And

32:53

so really, it's only when

32:55

we need to take these big step forwards

32:57

that we encourage people

32:59

to update. They'd be

33:01

running in Swift 5 language mode, but they'd still have access

33:03

to all the new Swift 10 features. But they would feel

33:06

bad about themselves because their number is 5. And

33:08

you're rolling out 7 and 8 and 9 and 10. look

33:12

at the little gamified badge on the Swift package index and

33:14

like, you don't have the little things that are Swift 10

33:16

compliant. And I have a little star next to my package.

33:18

And you'd be like, I get the language features. It's just

33:20

not compliant. I also think there's a misconception that

33:22

you need to totally eliminate all of

33:24

the uses of tools like locks and dispatch

33:27

cues in order to migrate to Swift 6.

33:29

I don't think that's true. I

33:32

think locks, I mean, the

33:34

Swift 6 standard library includes a new primitive

33:36

mutual exclusion lock called mutex. And that is a

33:39

tool that people can and should use in some

33:41

scenarios in their code. And I know there are

33:43

a variety of other lock types out there that

33:45

people are currently using. You don't need to stop

33:47

using those types in order to

33:49

migrate your code base to the

33:52

Swift 6 language mode. The same thing is

33:54

true of dispatch cues. And like I said,

33:56

part of the reason why the system is

33:58

built on incremental migration because we know

34:00

there's so much concurrent code out there that

34:02

is using, you know,

34:05

dispatch and other concurrency primitives. And

34:07

if you had to eliminate or just

34:10

totally refactor all of your code in order to migrate

34:12

to Swift 6, nobody would ever do it. So

34:15

I don't think you need to actually like

34:17

massively refactor your code in order to migrate

34:19

to Swift 6. Though in some

34:21

cases, like in Ben's talk, you'll see, a

34:24

talk that he gave back in 2021, he

34:26

actually took a sample app and it

34:28

was using dispatch and he went through

34:30

and replaced some uses of dispatch queues

34:32

with actors. And that might make the

34:34

migration a little bit easier in some

34:36

cases, but you'll

34:39

sort of see when you watch the talk, some

34:42

of the things that are made easier by introducing actors

34:44

in some places, but it is still possible to do

34:46

it if you're using other things like dispatch queues. I

34:49

have seen that talk. One of the challenges there

34:51

is that doing

34:53

that refactoring prior actually made it a lot

34:55

easier to migrate to Swift 6. And that's

34:57

actually something that we'd encourage people who have

34:59

been adopting async and await and things like

35:01

that, they will find that turning

35:03

on straight concurrency mode is a lot smoother for

35:05

them. But we've also in the latest compiler added

35:08

a lot more affordances, for

35:11

example, around not having to make your type sendable, but

35:13

also be able to pass them through between

35:15

isolation domains. One

35:18

of the challenges with writing the latest talk

35:21

is that actually I had these

35:23

great examples of problems that

35:25

I was gonna talk about and then we fixed

35:27

the compiler. So they wouldn't problem them anymore. It

35:29

happened like three times. It's a good problem to have. It's

35:31

a very good problem. I mean, that brings me to the

35:33

next topic. For both of you,

35:35

what is it like developing Swift in the open?

35:37

Because I'm watching all year on Swift Evolution. I see the

35:39

features coming in Swift 6 as part of the reason I

35:41

kind of backed off my recent attempt and they're fixing a

35:44

bunch of stuff in Swift 6. And you see them go

35:46

by. You see the proposals here. We're doing this thing. They're

35:48

fixing the problems in your talk and I see it happening

35:50

all throughout the year. That's very different

35:52

than most other people here at Apple. I

35:54

mean, maybe some people sit down for WWC and they're

35:56

shocked by Swift 6, but if you're following

35:58

the forums and watching... I

38:00

mean, I obviously worked on foundation. This could be

38:02

you. You could be getting bug reports from people

38:05

and communicating with them in an efficient manner and

38:07

fixing them. Yeah, we get

38:09

a huge amount of benefit from the Swift community,

38:11

I think. When we bring ideas

38:13

to them for new language features, we

38:17

get this real-time feedback. The

38:20

people on the forums, they spot issues with what

38:22

we're proposing that we had not thought

38:24

about. And we

38:27

iterate with them on that,

38:29

and we get a huge amount of value from

38:32

getting that real-time feedback from people. And so

38:34

I would say that's certainly been a

38:36

valuable process for us. Also, you

38:38

have to argue about keywords. The true

38:40

purpose of every language evolutionist. We've

38:43

fallen into this mode now where we... This

38:46

is something we've evolved as a process

38:49

in the language steering group that Holly and I sit on,

38:52

which is we're now in this mode

38:54

where we will agree a proposal in principle,

38:56

where we talk about the fundamentals of the

38:59

language proposal and how it's going to work.

39:02

And then what we say is we've agreed that in

39:04

principle, and now there's like a free swim where everybody

39:06

gets to specifically focus on the name we're

39:09

going to use for the keyword. And

39:11

that has actually helped the process

39:14

a lot because the bike shedding

39:16

is a shiny thing that people immediately move

39:18

towards. And so if we say, let's

39:20

park the naming discussion for

39:22

now, let's talk about the fundamental feature. Then

39:25

when we've agreed the fundamental feature in

39:27

principle, then we can have a discussion about what we're actually

39:29

going to call it. I mean,

39:31

that's a source of contention, and it's a silly

39:33

argument where people... But it really does make a

39:35

big difference in language. Some people

39:37

look at the switch evolution or other language list, and they're like,

39:41

it just seems like a bunch of people arguing over whether

39:43

copyable should have a tilde in front of her. It should

39:45

be a new keyword. But that's

39:47

so important because those decisions you make, people

39:49

live with those for decades. So you

39:51

should spend a month arguing about it

39:54

because I've seen it change. And

39:56

if you're going to have a solution, like the original proposal will have

39:59

this thing or whatever, to

46:00

understand exactly what the code is doing. If you

46:02

have too much ceremony, then you get, you know,

46:05

a language more like Java where you have to like

46:07

write multiple different things to achieve

46:09

the same result that in

46:12

Swift would just be like a couple of words. So

46:15

yeah, it's plugging that path and that's actually

46:17

something that we think Swift hits the spot

46:19

of, which is why we think it would

46:21

be such a great language to expand beyond

46:24

just its existing app

46:27

development ecosystem and expand into other

46:29

places where people want like the

46:32

performance of a head of time

46:34

compiled language that doesn't have garbage collection whilst

46:37

also giving you the ability to have like a joyful

46:39

experience writing code where you don't have to write that

46:41

much code and you don't have to fit too much

46:43

stuff in your head at once. Still hanging on to

46:45

that dream, Swift being the language that spans from the

46:48

lowest level of the operating system up to

46:50

scripting. And there's a lot of programmers who

46:52

are the potential audience for Swift, but obviously

46:54

a lot of the programmers who are your

46:56

target audience are Apple employees. How

46:59

do you work with the other teams at Apple when

47:01

it comes to language features? How does that work?

47:03

So did you just give example, like result builders

47:06

for the Swift UI thing, non-copyable

47:08

types, Objective-C, Interop, like do

47:10

you come to them and say, hey, we think I have

47:12

an idea, do they come to you? Like what is the

47:15

interaction with the rest of Apple for language features? The language

47:17

features that will obviously, they will benefit everybody when they get

47:19

out there in the world, but sometimes you look at them,

47:21

you're like, okay, that was a language feature that was made

47:24

specifically for teams at Apple so they could

47:26

adopt Swift faster or whatever. I

47:28

mean, I think the way I would think about it is

47:31

that no feature is ever good unless you use it. So

47:33

when we're developing a feature, we really

47:36

need to use, we

47:38

really need to do that development with

47:40

somebody who is directly using that feature

47:42

and ideally you do that development in

47:45

real time. And so when

47:47

we're working with a team like the

47:50

Swift UI team, we

47:52

really wanna know that something like result builders

47:55

is really gonna hit the spot of them

47:57

being able to create that really

47:59

expressive AP. API and develop that

48:01

feature with them and have them

48:03

use it and give us feedback and results. Are

48:05

you bringing result builders to them or are they

48:08

bringing the idea of the Swift UI to you

48:10

and saying we need a generic system to do

48:12

this? Like how is it? I don't think Swift

48:14

UI in particular is not. Or any other. So

48:16

another example would be Embedded Swift. So obviously we've

48:19

got a lot of material this week and we've

48:21

been putting it up actually prior to this week,

48:24

encouraging people to check out Embedded Swift and

48:26

use it for developing

48:28

for the Raspberry Pi Pico or the

48:30

Playdate or something like that. But we also

48:32

developed it in conjunction with some of our

48:35

developers who are working on things like the Secure Enclave.

48:38

And we've talked about that. It's actually one of the

48:40

places where we've adopted it this year. And

48:43

so we directly work with them and

48:45

they inform our thinking about

48:49

how to target that language mode. And

48:51

it really ends up being a better product. I

48:53

think if we developed the language ahead of time

48:55

and then said, here it is. We knew you

48:57

needed to do some firmware development. Here's a language

49:00

that does it. We would not get as good

49:02

a result. And another example of SwiftUI is like

49:04

the old limitation for the parameter

49:06

things. You get one through 10 or whatever. And

49:08

it was in parameter packs or whatever thing that

49:10

goes around there. Was that an example of like,

49:12

OK, well, you obviously didn't have that language issue.

49:15

They rolled out SwiftUI anyway. And there was this

49:17

kind of semi-not well-known limitation or whatever. And boy,

49:19

was the limitation there. It was a language limitation.

49:21

And you could look at that and say, all

49:23

right, our language is failing the

49:26

team here. How can we solve

49:28

that, but not just by hard coding, I

49:30

think, for SwiftUI, but adding a language feature

49:32

that now is beneficial to anybody who wants

49:34

to use it. But as a side effect, that

49:36

limitation in SwiftUI is gone. So

49:39

parameter packs specifically were a generics feature that

49:42

I think we always knew we

49:44

wanted to have, because there are such a

49:46

wide variety of use cases for them. And

49:49

SwiftUI View Builder is not the only API

49:51

that adopted parameter packs last year. You also

49:53

see it in Foundations Partiket API. You

49:56

see it in Weatherkit APIs, because there's a lot

49:58

of APIs that are structured. where you

50:00

have a variable number of things that you pass in, and

50:05

then you get the same variable number of things

50:07

as your output there. But

50:10

I help a lot of people try to express something in Swift every

50:15

day across a wide variety of framework teams,

50:18

people writing apps, people on the forums.

50:21

And one really important job of my team, the

50:23

language team, is

50:25

to see all of these different use cases that people have.

50:29

In a lot of cases, people are just trying to use some feature

50:31

that already exists and they need some help

50:33

figuring out how to exactly make it work for

50:36

their specific use case. And in cases

50:38

where there is an expressivity limitation in

50:40

the language, we take all

50:43

of these different use cases, again

50:45

from a variety of different sources, we use the forums as

50:47

a big source of use cases for different things as well.

50:51

Macros are a really great example of this. There

50:54

were a variety of different use cases for

50:57

frameworks at Apple, the data adopted

50:59

macros, the new observation library

51:02

from last year as part of the Swift standard

51:04

library uses macros. But there were also a ton

51:06

of use cases spinning up on the forums about

51:08

people who were wanting to do really similar things

51:10

in their code. And something

51:12

that was awesome during the review process

51:14

of macros in Swift Evolution

51:17

was people were trying it out and

51:19

putting up example macro packages on GitHub.

51:24

And that also was a really great example of

51:26

people actually trying out the feature and seeing how

51:28

it worked for them at the same time that

51:30

it was being developed and that

51:32

turned into real feedback that was incorporated into

51:34

the design. So yeah,

51:36

usually the way that these things work out,

51:38

unless there's some big overarching goal like data

51:40

race safety, that was a goal that was

51:42

driven by us. But

51:45

a lot of times it's that we're helping so many

51:47

different people use the language in a variety of different

51:49

ways and we can

51:52

generalize these expressivity limitations into

51:54

a single language feature that

51:56

works for everybody. and

58:00

the outside community a lot of

58:02

more rapid adoption of Swift on

58:05

Linux environments and on

58:07

the server generally. I think if you saw some

58:11

discussion in the keynote to the fact that we're now running

58:13

Swift on the server to do some of the new Apple

58:15

intelligence features, and that's all built

58:17

on this foundation that we've been working on for

58:19

years with projects like the Swift Neo framework

58:22

and things like that that have always

58:24

given us this ability to stand up

58:26

servers that have this

58:28

really great ability to

58:30

again have this high level language that we

58:33

feel is really enjoyable to write, but that

58:35

managed to get you, in the case of

58:37

the server, really low memory footprints, which

58:40

can be a big challenge when it comes to large

58:43

server farms especially.

58:46

And that's been a really big win for us that

58:48

we're pretty proud of. World domination is still on the

58:50

table. Still on the table. How about you, Holly? My

58:55

team's focus this year was data race

58:57

safety in Swift 6. I'm personally really proud

58:59

of my team because a lot of the

59:01

team was new to the data race safety

59:03

model and the concurrency model in general. At

59:07

the beginning of this year,

59:10

originally it was built by a smaller

59:12

group of engineers and then more people got

59:15

involved in concurrency. So yeah, I'm really proud

59:17

of the work that the team has put

59:19

in in general into this release. And I'm

59:23

also really excited by

59:25

how the community has started to

59:27

adopt these features and surface feedback

59:29

to us and talk about what's

59:31

difficult, talk about what error messages

59:33

are confusing, and seeing the community

59:36

really embrace this new

59:38

model of programming and come to a

59:41

shared understanding and improve both

59:44

the compiler and the documentation and the

59:46

language. I'm really excited to see

59:48

where this goes from here. That's awesome. Ben

59:51

Cohen, thank you so much for joining us. I

59:53

really appreciate it. Thank you very much. Holly Borla,

59:55

thank you. So very, very much to both of

59:57

you guys. We really, really appreciate it. Thank you so much for

59:59

having me. And thank you to Apple

1:00:02

for hosting. And with that, I think we're good.

1:00:04

See you next week.