All right, how are we starting this? I didn't even start again. Okay, you're the host, man. All right, well, here we go. All right, so hey, everybody, we're doing something extremely special today and I am genuinely exceedingly excited about it. 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.
And it's actually more than a little treat. It's a big treat. So today we have a special guest, but not one special guest. We have two special guests. 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. We are in the presence of greatness and I don't know how we ended up here, but I'm happy about it. So thank you, Ben and Holly, for being here.
I know I speak for all three of us and saying we are extremely excited and lucky. So thank you. Thank you very much for having us on. Of course. So interview is very often. He'll also. And actually just this morning I was watching your video, which is very good. And we'll talk about that. But I guess Holly, if you don't mind, if you would, if you wouldn't mind starting, would you give me the nickel tour of who you are and what you do?
I mean, I know, but not everyone. So who are you and what do you do for Apple? Sure. Yeah. My name is Holly. I'm the engineering manager of the Swift Language team, like you just said. 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 ray safety and Swift 6.
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. That's incredible. And Ben. Yeah. So my name's Ben Kern and I managed the Swift team overall. So that that includes the language, but also the back end, the optimizer, a lot of the tooling that goes around the language like code completion and things like that.
Yeah, Apple about eight years. I worked on various parts of the Swift compiler, including the central library, the optimizer, and before that I was not a compiler engineer. So I was actually working in sort of fintech type stuff. So you know, I'm going to, I'm going to really make John happy. I'm going to jump right to the end or to right to the end. So I don't think we're not doing follow up then.
Is that how well I guess in real time, Paul, how did you end up, but I'm asking both of you, but Ben, since you've most recently spoke, we'll start with you. How do you end up being a compiler engineer? 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.
It's like a priesthood where you're a programmer and you write the thing. And then if there's something wrong with the compiler, you're like, oh, it's not my fault. There are people in an ivory tower somewhere that make this work. And you know, and they're crossing over that path. I know there's lots of advertising for job positions that you don't need compiler experience. Just come be on the team. We'll teach you.
Well, that is true. You do not need compiler experience. And in fact, I think actually neither me nor Holly had direct compiler experience before joining the Swift team to work on the language. To have a high tolerance for pain. So actually I came to Swift through pain from other languages. That is such a good answer. My love for Swift comes from the fact that I have experienced what other languages have to offer. And there are, you know, I've always been in the language enthusiast.
And so whether it's Java or C++ or high level languages like Ruby or Pearl, there's something great about all of these different languages. But I always felt historically like these languages had compromises. 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++.
It's true story. And my background is actually I used to work on trading systems and performance is really important in trading systems. And so we used to do a lot of things in C++. But at the same time, safety is really important in trading systems. So you do not want the machine to do the wrong thing. And so we always used to have this trade off between like C++ and Java.
And when I saw Swift 10 years ago, I was actually blown away by the fact that it actually managed to find the sweet spot between those different things. It was deterministic. It didn't have a garbage collector.
But also it had that like higher level feel. It does sometimes look a lot more like sort of the Ruby like language where it's really joyful to program in. And it's really great to see that realized in things like Swift UI where it's like brings back that joy of programming that I think sometimes we lose a little bit. And so that was what brought me to Swift and I joined Apple originally I was I was actually a library developer.
So I didn't have that background and compilers, but I did have that background in like writing algorithms and data structures and things like that. And that was a really nice routine. And from that I learned about compiler performance. And from that got more into the general language design. And that's that's how come I ended up here.
So and then Holly you said you started working next code is that right and then kind of me entered from there. What was that story like? Yeah, that's right. So I actually signed up from mentorship program that the developer tools organization offered. And they deliberately paired mentees up with mentors from different parts of the organizations that you could get to meet.
People who you didn't work with on a day to day basis and I got paired up with a Swift compiler engineer and that sort of sparked my interest in actually joining the team. So for me, I feel like I became a compiler engineer by accident. What brought me to developer tools Apple is I was really interested in education for programming.
I also ended up studying computer science sort of by accident. I didn't go into university knowing anything about programming or computer science like a decade ago today, you know, it's Swift's 10 year anniversary 10 years ago. I knew nothing about programming. I was graduating high school.
I 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 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.
The part of Xcode that I worked on was had just been entirely rewritten and Swift. So yeah, it was the 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 to people who have an idea and are interested in bringing not to life through code.
I love that and I'll throw Marco under the bus with me because I can tell you that Marco and I went to school for you know CS and computer engineering and I cannot fathom a situation where engineering is like my fallback like oh, I'm sure I'll be fine in engineering if this other stuff doesn't work. That's incredible. I just couldn't dance that was my first thing I heard stories like an after school special how you can slippery slope into the CD world of compiler.
Yeah, you started out as a promising dancer but somehow the compiler people got her and now look at her. Now I'm going to continue to make John upset by continuing to be at the bottom of the document, but I promised John I will come back up to the beginning. At least you're in the document. That's not even the document. Well, you're doing great. We have a structure. We're sticking to it. Well, well, this is a structure. Just by which it's not a copyable. John, have you heard the show?
You're right. So then you were very rightfully, my opinion, slagging on C++ just a few minutes ago, but last time. That's what gets out the stuff for a compiler. Smell see right? Well, that's exactly what I was going to say. So last I remember hearing the you know, the Swift compiler last I looked at the Swift compiler is largely if not entirely C++. So you're pointing at me and wait. Wait, there's more. So tell me is there more there is more.
So the compiler I actually don't have the right percentage. It's actually slightly difficult to tell because if you look at the GitHub repo, it gives you large because of two reasons. One is like we have a lot of tests written a Swift and those shouldn't count. Right. Right. Right. Right. But also we have started the process of writing parts of the compiler in Swift. Okay. And that started quite a while ago now. I think maybe four years ago now.
But when we do that, we actually we create those bits of the compiler that we rewrite as packages. And when you do that, we break them out into a separate review. So if you go to GitHub.com slash Apple for now, soon, Swiftlang, slash Swift-driver. That was the first part of the Swift compiler that we started rewriting in Swift. That happened about four years ago and the driver is basically the way into the front end of the compiler.
Right. So it's the thing that does the initial processing of your command lines and it organizes the build and things like that. That was written in Swift. Two years ago now, we started rewriting the parser in Swift. 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. It was a library for manipulating Swift code. And that evolved into a replacement for our current C++ parser.
That is actually a foundation for macros. So last year, I mean, she used macros. Those are based around Swift syntax and the Swift parser. We have some ongoing work that's happening at the moment to do the next layer down, which is what's called a ST generation. So what you do is you parse the code and then you type in the abstract syntax tree. And then you have to lower that down into the underlying representation. That is ongoing at the moment.
And once we've done the AST-Gen layer, we will actually be throwing away the C++ parser. Now, that's going to be an interesting moment because that is the point at which there is no way back. That is the point at which you will need a Swift compiler to build Swift. No, you can look back in the good history. It will be. It's still there soon.
Well, it is actually, it's an interesting thing because we have an app developers sometimes point out that, you know, they have to wait a year or two before they can raise them in a minimum deployment target in order to use SDK features. We as compiler authors know that pain because we cannot use the very latest Swift features when implementing the Swift compiler because you have to be able to use the shipping pilot in order to bootstrap. So we're very familiar with that.
But yeah, and then more recently than that, we have started writing optimizer parses in Swift. So that is actually using C++ interrupt, which is another important feature of Swift. We obviously interpret with LVM, which is written in C++. And we use that to build our optimizer parses to do things like hoist variables out of loops and things like that. And those are now written in Swift as well. So we are getting there. It will be a ways away. It's not our main goal.
We don't rewrite things with sake of it, even though it's written in C++. It's working. 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. And those good reasons can be, for example, creating a macro system with a nice friendly Swift API. Or when we rewrite the optimizer parses, we usually do it in order to simplify them and make them more effective. Yeah. So we are on that path to self hosting.
But it's going to feel really good when you get to delete that code though. It feels very good to delete code. So 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. And I'm not sure I'm the best person to summarize that, but basically the Swift compiler is written in Swift.
And is it fair to say the eventual, I'm not looking for date, but the eventual one sometime goal would be to self host entirely if possible. Is that fair to say? We don't comment on a future product. Well, this is not a product. This is the Swift language that is entirely open source. And we are perfectly liberty to comment on. So yes, I think the ultimate goal is the compiler should be written in Swift. If nothing else, it does improve the safety of the compiler.
The compiler is not filled with seqfalt. But they can happen. And obviously rewriting parts of it in Swift eliminate that possibility because it's a safer language. And so that's one benefit that comes from it as well as bringing other features. The other benefit is it makes it more approachable for outside people.
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 actually kind of pretty straightforward code when you look at a small part of it, right? When you look at a particular optimization pass, you can usually see pretty much what it's doing. And it's actually a great opportunity to get contributors involved. And I know Holly's worked with quite a lot of people who come new to the Swift programming language as well.
Yeah, we also organized 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.
And a lot of people, I find that a lot of people who write Swift, who are iOS developers, are really interested in making some contributions to the compiler just as a learning experience. Or better understanding how their code works if you're in the depths of how type and friend, 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.
So yeah, it's a cool program and a really good learning experience for people who are writing Swift. 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. So I can put the standard library, 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.
Like that's all Swift code in the standard library. So you can contribute to that and say, hey, I contributed to the Swift language, but you're just making Swift methods in a library. So curious, you know, 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.
I think it's kind of a roller coaster. Sometimes it's more successful than other times at this balance of 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. And as we go into this new data race safety era, how do you strike that balance?
These are some very advanced concepts. And you know, if somebody might get some warning as they're building their code saying, you know, something's not sendable because it has mutable state and they might not even know what any of that means. How do you how do you balance that with being approachable to new programmers or to less experience programmers?
Yeah. So 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 or you're using frameworks like Swift UI, which are really heavily leveraging these advanced features to make APIs that are really natural to use for programmers.
But you don't need to understand generics. 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. And that's the end goal with concurrency as well for newcomers to app development or newcomers to Swift when you're writing code by default that code should be on the main actor and you shouldn't have to actively think about the fact that that code is on the main actor until you're trying to
to actively introduce concurrency into your project. And at that point, you'll be confronted when you make a mistake that can lead to a data race in your code. And I think that both the progressive disclosures is the way to make that complexity more approachable. But I also think introducing those checks that compile time is will also make learning to write concurrent code a lot more approachable for people who are new to concurrency in general.
And this is a continued evolution of making concurrent programming more approachable like concurrent programming is just notoriously really hard to get right.
I don't know if you've ever debugged a data race before for those of you who are listening, but you if you have you know that it can take days or even weeks and the introduction of dispatch even was a huge step forward for making concurrent code easier to write working with dispatched uses way easier than managing low level system resources like threads manually in your app.
But you still have to know when to apply those tools to protect mutable state in your code and with data race safety in swift six. You can't get it wrong. The compiler will tell you if there's a risk of a data race in your code and having to confront those concepts at the point when you make a mistake is is better for
forming a mental model of how concurrent code should be written in your project. So I'm really excited for people to start to learn concurrency for the first time with data race safety in swift six as opposed to I think a lot of people right now are
have internalized how do you dispatched and they've been using that for many years and now they're trying to learn this other like 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. 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 for making mistakes.
Is that how you characterize like the difference between the swift concurrency and the like the predecessor concurrency systems at Apple like we've had. And I guess we've had a grand cedrus batch of dispatch cues and this operation queue but P threads back in the day locks of various kinds over the years and all those were kind of you have sessions on they say here's how you properly use this here's how many cues you should have and stuff like that.
But it was all sort of like runtime stuff and everything I hear about Swift concurrency is always we will do these checks for you at compile time so that it run time you don't have to run your thing to see if there's a problem or like you're not at the code and look over this is like the compile a little check it for you and make sure it's mostly okay.
Yeah, would you say that's the big difference? Yeah, absolutely. You should be able to program by bumper where you know the compiler's there to tell you like oh no you got this a little bit wrong with actionable suggestions for how to fix that code.
Yeah, so you're talking about the progressive disclosure and like you don't have to know about this until you start interesting concurrency but I feel like that's true of the Swift language if you're writing just Swift code but once they have everyone else in this company makes a bunch of frameworks.
And those don't know or care about the Swift concurrency for the most part and they're in your code and you think I haven't introduced any concurrency but it's like well this method has a call back and it is cranky now and you're like but why I don't I didn't make that API it's complaining about something that I don't understand it's not an API that I wrote and so you're like your face with this dilemma of just you stare at it for a while it's like should I not use that API should I you know like I think we've all had experience.
I think we've all had experience and everyone you probably talked to is had experience trying to enable strict concurrency and 510 so if I've been you know when you set this setting and I scored you see all the warnings and you're like how far away am I really 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's like I'll just make everything sendable and that will fix everything but that doesn't work and so like well maybe I can just add annotations but main actor and a bunch of things but that doesn't work and it's like well maybe I'll just sprinkle assume isolated everywhere and that's probably not the right approach and I think my personal experience I take like.
For different runs it at at bringing one of my apps on this strict concurrency and I just keep back and often scratch my I know this WBC session about and I haven't seen it my bad I was busy day yesterday and my great business with nerds but I feel like that is a lot of the barrier and it's nothing to do with the language.
It has to do with the API's that we're using that were created you know decades ago that have their own conventions and strict concurrency and it's not wrong it's correct there is a potential for a mutable state to be messed up there and then of course even in our own code it's like well I use cues for this and I use locks and I'm pretty good.
I'm pretty sure it's safe but strict concurrency says well that's what unchecked sendable is for yeah but that's the whole thing like you don't want to go through and and sprinkled through it says I'm sure this is okay I'm sure this is okay like there are annotations to do that 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's no races and it will satisfy the compiler but you haven't actually
solved the problem you haven't actually use the system you're saying which is you should be able to write it the compile tells you what's wrong you might as well just turn that mode off so I mean I think a lot of users find it frustrating but it is a difficult problem and I I'm assuming well you tell me what you think the correct approaches give me the three second summary of the session that
didn't watch I'll let I'll abandon that and it's been session but it is and well done for Casey for getting ahead of the gun and watching it already so it really partly depends on what kind of frameworks you're using and it's possible that you're using some frameworks that the make it hard or easier depending on what kind of code mac framework right you're screwed so for example the UI layer we've actually and it's worth trying the new STK
because at the UI layer there's been a lot of work to indicate which parts of Swift UI also UI kit and the app kit are by definition always supposed to be running on the main thread and that should actually for people who've tried 510 it's well worth downloading the new STK and giving that
ago does that also include like this documentation issue but often you'll see a thing with a call back and you have a question it's like what thread will the call back and you're just like oh you're just supposed to know whatever you thread you you register it on that's the thread the call back will
run on but you don't see that in a documentation so you're like well I registered for this on the main thread and when the call back gets called it will probably get called in the main bread 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 but like documentation wise I always feel like I look up one of these old app kit things and I'm just it's guesswork right did you know John I learned this morning that there is a keyword there what is it
assume assume yes you're isolated there it is there's tools for this John as it turns out I know I know I know I have a tool for that right yeah I'm not still doing it I say that all it's going to do is is through a runtime error when you when it finds out it's not
on the main thread yeah don't do that scenario right just dispatch it to me so it so assume isolated does throw a runtime error when when you're not on the main thread this is actually something that a lot of good programmers are already doing which is like they put in preconditions where they they know this is supposed to be on the main thread and they put in precondition just in case they call it from
somewhere else in the app where it's they're getting a call from a dispatch queue that's not isolated to the main the main thread and that can lead to trouble I think somebody was saying earlier you know you run your program and you find out it doesn't quite work as
opposed to a compile time you find out that you need to do yeah it feels like it's undercutting the bumper thing that we're saying is like I don't want to find out at runtime so every time I do assume isolated I'm like there must be a better way so don't use that there man that's not what it's for so I would say that finding out at runtime that your code is broken is the best case scenario under the old world right which is that you you you really you hope to find out when you run your code
that's something is wrong but what actually happens is that in in in some of these techniques you you find out in the wild in when your program is crashing and you do not exactly know why I'm always amused by people who make these jokes on on master normal to where they they say like they make a joke about concurrency where they jump up the words words and that's cute but that is again the best case scenario is jumbled upwards that's very benign what's worse is like you
know you can ask you corrupt user data this is this is no good and so that's why a lot of people have these really practices in in the old world of dispatch where they will insert like these assertions saying I I want you to stop me
if I'm if I'm not running on the main queue so I think the the long term goal is that we need to lift these kind of this information out of documentation we want to take it out of documentation and put it actually in the definition of the AP it's not an organization now so you don't have to
so the benefit of putting it there so that the compiler actually enforces it is that you can't not have that right the by definition your code doesn't encapsulate the information about where you were running and how it's running yeah because one of the things I do when failing is like there's a call back and I'm like can I just annotate the call back as main actor and the answer is no can't and then it's like why is it already on
always on the main thread is you know I figured with the error is I'm just wait for the framework to be up to with acing call yeah we don't have all the time in the world the way it isn't it's it's what it comes down like you mentioned queues right so I I one of my abs has concurrency I'm sorry it does and I use queues and in one situation I wrote a little class and I use locks old style locks and pretty sure it's probably okay but I look at that and like I
would like to use swift concurrency because then I would be a feel more sure but there's nothing you can do to sort of annotate or markup dispatch queues or locks and other than than the reassurance of just telling the compiler I'm pretty sure that I'm right I would rather just like pull that out and re implement it with actors and so on and that sometimes just seems daunting.
So another thing that there's a ton of swift code out there and swift code that inner operates with C-based languages like objective C and C++ we're at the start of this transition to start to integrate swifts native safer concurrency primitives into these like vast code bases that are using older you know library based concurrency primitives like dispatch queues.
The system is designed for incremental migration so in the case if you have like 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 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 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 but when you're in the dispatch queue you can still pass the dispatch queue there and then you can bridge between like the dynamic isolation in the static world with tools like us who isolated.
That brings about another question of like incremental adoption I know so this swiftsick just came out and in the old five world we had the little setting to set it on complete concurrency whatever I know there's a whole bunch of features and swiftsicks and new things for set and ability and everything that make it easier but what is the mechanism in your project of saying like I want you know is it per module is it per file to saying I want the
Swift six language features but this file is not ready for strict concurrency what does that look like. So the yeah the setting is per module so in your xcode build settings there's a language version setting or if you're in a switch package manifest there's an API for setting it per target and you many people currently have that set to something whether it's four four point two or five so you would
change that to six for the specific module that you're looking to migrate to swift six and then if you have a particular file that violates some of the rules and 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 per concurrency import statements if it 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 so there are a variety of tools like that to let you opt out of the
checking in narrow situations in your code 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 so you're picking the swift six as the language and that includes everything having to do with swift six when you pick no no so so swift six the language mode where you go into the Xcode settings and you you say language mode of swift six that purely governs the strict
concurrency checking so the swift six compiler that you get with the latest X code that has all of the new features so I think you made a glancing bloater non-copyable types those features are available new generic capabilities non-copyable types are
available in the swift six compiler you do not need to tell you you would pick the swift five language mode but it's using the swift six compiler to run in swift five language mode you get nine copy all types you don't get the strict correct that's right and that's
exactly this is part of a journey that the entire Swift ecosystem needs to go through so being ready for Swift six having your dependencies ready for Swift six there's actually a Swift package index dot com which is great website they have a
tracker now that tells you which packages they are compiling that build cleanly under Swift six code but it really does depend on the nature of your program and whether your dependencies are now ready for swift six whether you want to turn on that language mode and this dates back to we've been doing this now since the swift four days so since we introduced the swift four language mode we've always had this source compatibility
promise that whenever you download the new compiler with a couple of exceptions where like maybe there are a couple of issues with your code where maybe the code was like explicitly incorrect we always want you to be able to compile your code as is with the latest compiler and then when you're ready for some breaking change there were a few in swift five and obviously in swift six the key key change here is strict concurrency you're then able to turn it on on a
target basis is that like a long standing kind of marketing decision to tie them to the I mean just deciding that Swift six means strict concurrency you could have for example said Swift six just means swix language features and then some other option for strict concurrency said no we're tying we're trying this feature to this number because people want the higher number is that like a sort of a social engineering decision or it's a way of thinking about like the
progress I mean you don't want to be stuck in this world with the Python two to three transitions right where those were tied to you know 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 so it's this this way of helping engineer the the ecosystem to help have this continuous forward progress but at the end of the day people
you know some people have written code in such a way that it won't be so easily adapted to swift concurrency some people have written code using a lot of new frameworks and a lot of a think away from the path for them is actually pretty clean and so we want people to be able to opt into that the choice has to whether you opt in or not is up to you if you're finding that you are experiencing quite a lot of pretty nile crashes is probably
worth considering opting in one great time to opt in is if actually you want to start introducing a lot more parallelism to your code right so we have these powerful new devices they have many cause and you might find yourself with an app that previously was doing most of its work on the main thread with a little bit about crime processing but you really want to take advantage of a lot more parallelism in your code that will be a great time to turn on Swift six mode in order to
know that you can do those refactorings without fear introducing new data races so yeah it's really up to each individual project to make that decision and to see how how the community is moving forward with them in order to update their dependencies and then and then take the plunge
do you worry about like releasing swift version 10 many years from now and huge code bases are still in Swift five language mode like they're using the Swift 10 compiler to run Swift five language mode because they could never get the wherewithal to to go strict and currency compliant and you're just plowing bravely forward here to Apple for making version after version and they're all great but they can never cross the
six threshold because they can never get their code to run under strict and curses millions of lines of like dispatch q and manually created locks like you worry about hindering your party basically made a hard gate of like you're not going to be running a Swift seven next year or whenever if you can't go strict and currency and you're like well my reason I can't go is because we have 10 million lines of you know manually managed walks or
something so it really only governs a handful of things so that is the goal is always whenever we introduce a new language feature that you do not have to update the new language mode we were looking at somebody's project yesterday where they were still on Swift four mode and really there was not that much they were missing out on
the first time so we have this long term promise to always always support those those language features so that people aren't forced to update but like I say most of the language features themselves are not gated on the language version and so really it's only when we need to take these big step forwards that we encourage people to so that they upgrade they'd be running in Swift five language mode but they'd still have access to all the new
features but they would feel bad about because their number is five and you're rolling out seven and eight and nine and ten and people be at they look at the little game of five badge on the Swift package index and like you don't have the little things is to attend compliance and I have a little star next to my package and you
don't like I get the language features just not compliant so I also think there's a misconception that you need to totally eliminate all of the uses of tools like locks and dispatch cues in order to migrate to swiss six I don't think that's true I think locks I mean Swift the
swiss six standard library includes a new primitive mutual exclusion lock called mutex and that is a tool that people can and should use in some scenarios in their code and I know there are a variety of other lock types out there that people are currently using you don't need to stop using those
types in order to migrate your code base to the swiss six language mode the same thing is true of dispatch cues 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 you know
dispatch and other concurrency primitives and if you had to eliminate or just totally refactor all of your code in order to migrate to swiss six nobody would ever do it so I don't think you need to actually like massively refactor your code in order to
migrate to swiss six though in some cases like in Ben's talk you'll see talk that he gave back in 2021 he actually took a sample app and it was using dispatch and he went through and replaced some uses of dispatch cues with actors and that might make the migration a little bit easier in some cases
but you'll sort of see when you watch the talk 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 use have seen that talk one of the challenges there is that doing that
refactoring prior actually made it a lot easier to migrate to swiss six 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 strike concurrency mode is a lot smoother for them but we've also in the latest compiler 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 one of the one 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 went problem anymore it happened like three times it's a good problem it's a very good problem I mean that big
thing that's topic like for both of you what is it like developing Swift in the open because like I'm watching all year on Swift evolution I see the features coming in Swift six as part of the reason I kind of backed off my recent
time like they're fixing a bunch of stuff in so if six and you see them go by you see the proposals here we're doing this thing they're fixing the problems in your talk and I see it happening all throughout the year that's very different than most other people here at Apple we
maybe some people sit down for WBC and they're shocked by swift six but if you're if you're following the forums and watching the proposals it's developed in the open this it's open source the process of deciding what goes into it is open there's no mystery involved what is that like for you in a company where that is absolutely not true all the other teams that you're working with some maybe WebKit for WebKit but also increasingly we're seeing more of this style of operating foundation now is
operating in a similar fashion so and that has actually been key to the the next thing that we've announced this year which is that we now have this single unified foundation code base cross-platform so the same foundation that you're running 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 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 rags is and that proposal was discussed in the open and then the other example I heard your podcast last week where you're wondering speculating about whether it was going to be a new testing framework because I couldn't remember the name of swift testing that's the one I had seen yes and yeah so swift testing was
developed in the open it's it we had some really great community feedback from that 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 of Swift framework features is there any like can users an example to the other groups like look we have we have a public issue tracker and people have problems we can discuss them in the open and look
how much more efficient it is to go back and forth and get up issues and discuss proposals and these other groups are like sending carrier pigeons across the country to through seven different intermediary parties with this game of telephone to find one crashing bug like do you ever like pitch the other groups and say hey I mean I obviously worked on foundation or you know you could this could be you you could be getting bug reports from people and communicating with them in an efficient manner
and fixing them yeah we got a huge amount of benefit from the Swift community I think when we bring ideas to them for new language features we get this real-time feedback where they the people on the forums they spot issues with what we're proposing that that we had not thought about and we we iterate with them on that and we get a huge amount of value from getting that real-time feedback from people
and so I would I would say that's certainly been a valuable process for us. I see it to argue about keywords.
The true purpose of every language that was on us. We do we we've fallen into this mode now where we we this is we've we've evolved as a process in the language steering group that that Holly and I said 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 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 and that has actually helped the process a lot because the the bike setting is a shiny thing that people immediately move towards
and so if you say like let's park the park the naming discussion for now let's talk about the fundamental feature 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.
And I mean I know that's a source of contention and it's a silly argument where people but it really does make a big difference in language so I like people some people look at the like switch evolution or other language listen they're like it just seems like a bunch of people arguing over like whether copyable should have a tilde in front of it should be a new keyword or like but that's so important because for those decisions
you make people live with those for decades so you should spend a month arguing about it make it because I've seen I've seen a change in solution like the original proposal will have this thing or whatever and you'll end up with a different thing
and it's better you're making it better by arguing about it I guess people just don't have a tolerance or I think I was not important I don't care about the word is called but it makes such a big difference to language and you know anytime you make like a slightly wrong choice like I remember so I was talking to I don't know it was Dennis Richie or one of the old Unix guys or whatever you have any regrets about your career
and he said I wish I put in the on the create system call you know CREAT Wow how long has even lived with that like in like I just I wanted to save that character and now it's create for just for the rest of it we're all you it's on macOS it's on every Apple platform right now somewhere
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 and so you don't want that to be you so yeah spend the time arguing about it and I think that what you said like doing that figure out what you're going to do and arguing about the key words
is a nice separation so you can make forward progress but I'm going to endorse arguing back keywords it's also really valuable because there was a recent proposal called sending parameter and result modifiers and we did the same thing there were we you know 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
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
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 keywords a little bit misleading and so that review thread is really cool because it wasn't it didn't feel like a really heated contentious debate 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
it was also valuable for us and figuring out 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 so yeah those those name bike shutting threads are valuable for a bunch of different things
yeah and that's part of the reason doing in a public I feel like it's so beneficial because the people who are working on the proposal know it's such an intimate level and then you throw in a bunch of people who have no idea what you're talking about and they will tell you this is confusing to me like if other using a term of art to 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 and the word doesn't doesn't make in their mind make them think of what it actually is and so changing the word will make it more learnable and more memorable
and again the people who don't like bike shutting will say well yeah it's a weird word but you learn it and then it just becomes internalized that's what happens to everybody but that's just make the language approachable if you pick a good word it will if the word means what you want it to mean it will help people learn the feature faster I definitely find that because again some some Swift features I read the proposal and I don't understand it until you change the keyword
and then I'm like I read the same proposal I'm like oh now I get it because the word you've chosen is different and now I understand what you're getting it even non-copyable types of like that it's like didn't understand what you were trying to do until it went around a few times and I'm like okay
it's not like the sending whatever and I think you picked up because of the was a part of the synergy was sendable and everything the connection with concurrency yeah previously it didn't sound like it had anything to do with concurrency
and so so riffing off of sendable in a slightly different form so that it's not like I'm talking about sendable versus sendable someone did actually suggest calling it like lowercase S sendable but sending is close enough that you're it's very clear you're talking about sending a value over
installation value because that's the term that Swift uses for that concept so you have this immediate connection took in currency and then you can dig in deeper to how it works just don't want the math people in the language it's funny just to kind of read or a what John said you know when I still had a real job and I was working with other switch developers it was hilarious the younger ones when our code base was some objective see was largely Swift
but you would bring a young typically a younger person who is grown up on more you know JavaScripty languages and and I think Swift is like that and don't mean that in a bad way I mean in a good way it's much more approachable and then we would they would look at a file of objective C and they would just recoil because it just looks so different like even though there I like objective C just fine I'm not a super fan but I like it just fine
but it's so much less approachable I think in so many ways because it's so different and I think those silly arguments about a till day one of you said a minute ago like a till day or not and what keyword to use they they really dramatically in aggregate can change the whole kind of vibe of a language and Swift's vibe I think Marko had said earlier or want me to somebody said you know there was a window of time where it was getting a little architecture
astronauti 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 and those arguments while I was one of those people that was like oh my god why do I care but then you just like John said
you think about it for a minute you're like oh no this is this is this is what you to just said this is worth arguing about and I think it's important architecture astronauts are saving your butt okay you do a good you do a good enough job of architecture astronauti you're like oh they all went away no they didn't they just did their job fair no that's fair that's fair correct yeah I mean the goal is very much we 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 what's on their mind and make it like a low ceremony language where they don't have to put that many keywords and sometimes those two things can be intention and that's something that the community really helps us work through right like so I think even with concurrency right the the strict checking mode the goal there is to have the compiler
help you work through exactly what you're trying to express and so sometimes we do have to to to resolve that tension and that's really the game of language design is making sure that we keep that vision of having Swift B as low ceremony as possible but not any lower than that right because if you have like no ceremony then you don't know what's going on and right now you're in like an untapped language where you
it's really difficult to to understand exactly what the code is doing if you have too much ceremony then you get you know a language more like Java where you have to like write a multiple different things to achieve the same result that in Swift would just be like a couple of words so yeah it's plotting that path and that's actually something that that we we think Swift hits the spot of which is why we think it will be such a
great language to expand beyond just its existing app development ecosystem and expand into other places where people want like the performance of a head of time compiled language that doesn't have garbage collection whilst also giving you the ability to have like 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.
So I hang on to that dream Swift being the language that spans from the the lowest level of the operating system up to scripting and there's a lot of programmers who are the potential audience for Swift but obviously a lot of the programmers who are your target audience are Apple employees.
How do you work with the other teams at Apple when it comes to language features how does that work so do you just give example like result builders for the Swift UI thing non-copyable types objective see interrupt like do you come to them and say hey we think I have an idea do they come to you like how what is the interaction with the rest of Apple for language features language features that will obviously they will benefit
everybody when they get out there in the world but sometimes you look at them you're like okay that was language feature that was made specifically for teams at Apple so they could adopt Swift faster or whatever.
I mean I think the way I would think about it is that no feature is ever good unless you use it so when we're developing a feature we really need to use we really need to do that development with somebody who is directly using that feature and ideally you do that development in real time and so when we're working with a team like the Swift UI team we really want to know that something like result builders is
really good at the spot of them being able to create that that really expressive API and develop that feature with them and have them use it and give us feedback and you bring result builders to them or they bring the idea of a Swift UI to you and saying we need we need a generic system to do this like how is that and I don't think Swift UI in particular right so any any other example would be embedded
Swift so obviously we've 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 you know developing for the Raspberry Pi Peco or the Playdate or something like that but we also developed it in conjunction with some of our developers who are working on things like the secure enclave and we've talked about that's
actually one of the the places where we adopted it this year and so we directly work with them and they inform you know our thinking about how to target that language mode and it really ends up being a better product 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 yeah and I another another
another example of Swift UI is like the old the old limitation for the parameter things you get one through 10 or whatever and it was in parameter packs or whatever thing that goes around that it was that an example of like okay well you obviously didn't have the language issue they roll out Swift UI anyway and there was this kind of you know semi not well known limitation or whatever and why was the limitation there was a
language limitation then you could look at that and say all right well our language is failing the team here how can we solve that by not just by like hard coding I think for so if you are but adding a language feature that now was you know beneficial to anybody who wants to use it but as a side effect that limitation in Swift UI is gone yeah so parameter pack specifically were a generic feature that I
think we always knew we we wanted to have because there's such a wide variety of use cases for them and Swift UI view builder is not the only API that adopted parameter packs last year you also see it in foundations part of API you see it in weather kit APIs and 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 but I I hope a lot of people try to express something in Swift you know every day across a wide variety of framework teams people writing apps people on the forums and one really important job of my team the language team is to take see all of these different use cases that people have and first and foremost help them use the language as it is today and a lot of cases people are
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 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
we use the forums as a big source of use cases for different things as well macros are a really great example of this we there were a variety of different use cases for frameworks at Apple Swift data adopted macros the new observation
library from last year's part of the swift and the library uses macros but there were also a ton of use cases spinning up on the forums about people who were wanting to do to do really similar things in their code and something that was awesome during the review process of macros and Swift evolution was people were trying it out and putting up example macro packages on github 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 and that turned into real feedback that was incorporated into the design so yeah usually the way that these things work out unless there's some big overarching goal like data-resafety
that was a goal that was driven by us but a lot of times that's that we're helping so many different people in a variety of different ways then we can you know generalize these expressivity limitations into a single language feature that works for everybody it's a really interesting process
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 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
you don't know that when you're 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 type values then instead of giving you like two untite values like 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 types that you have that make it so much easier to use macros is another example where like 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 so if testing is not the one I know you folks were ragging on the fluent design of other testing frameworks and one of the beautiful things about Swift testing is that you write just regular expressions sorry I shouldn't say that.
You write ordinary expressions, ordinary Swift expressions like A is not equal to NIL or something like that you put them inside a pound it's spet 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 we don't have different quiet that's the great idea to maybe bring to Swift forums and talk about
there you go John you just look at any other testing framework I'm pretty sure you they know it but they know it exists fair enough that's the thing with testing frameworks there's so many of them there's so much prior our next test was a little bit crusty but like there's your spoils for Chorris 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 you know some people like that
so I predict that Swift testing is 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 so going beyond XE test looks great you know I we actually had plans to talk to the both of you about 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 softball questions
first of all I'm going to start a little bit negative and then we're going to end with a positive do you is there any missunderable right now I actually have a statement no I'm do you support is there is there any common misunderstanding 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 rocked that oh you know you all of us myself may be included think a but it's actually Z you know or whatever the case may be
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 about Swift not just yeah there is one immediate one that comes to mind people in Swift love protocols protocols are great I love
protocols too but a lot of people when they're starting to write you know an app they start by adding a couple of things to the code and then they end up using a lot more abstraction than they really needed to in their code like they end up using any types or if you're familiar with the formal term existential types which we tried to steer people away from because though those are a really complicated feature and understanding why they have some
of the behaviors they have is is really really nuanced and hard for a lot of people to grasp and in a lot of cases you know so I would tell people to start with a concrete type start with a struct specifically until you need more abstraction or you need reference semantics and then sort of evolve from there the same thing is true of global I've seen so many people write static variables that never change throughout their code base so I would
tell people to start with the lead and that's really helpful for data race safety as well yeah I blame was it you know I was thinking the same thing a lot of people under that session like protocols in the future starting every app with protocols it's worth rewatching that talk like what the talk said was if you're thinking about creating a sub typing relationship instead of a class hierarchy start with the protocol unfortunately what
people you heard was star was start with the title you just they read the title they're like great I'm on board right to the right and so it gets that point where like it's kind of like the black box what do they make the entire plane out of protocols like that's not what you want you want to start from from structs like honey said and then generalize your problem when you find you need to generalize it that's actually a start from the start yeah that's
really good advice and then finally because we really are running low on time what are you proud of lately like I mean obviously and I mean there's obvious answers like Swift concurrency in in the strict concurrency
it's an incredible land and you should be proud of that but is there maybe something that that you know your pet feature or project or what have you that maybe not a lot of people seem like I'm beddits with is a great example that I mean I've seen a lot of this on the WBC 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 proud of 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 that's especially something we've been pushing this year we have support for more distros this year we have now Debbie and and Fedora 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 personally I'm sticking with X code but like I know a lot of people have very personal preference yeah yeah yeah we also
have some articles up on how to turn to great code completion into near them and EMAX if that's your jam as well so I think we've made really some really great progress in in that area and we've seen both internally and in the outside community a lot of more rapid adoption of Swift on on Linux
environments and on the server generally I think if you saw 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 and that's all built on this foundation that we're 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 language that we feel is really enjoyable to write but that managed to get you in the case of the server really low memory
difference which can be a big challenge when it comes to to large server for large server farms especially and that's that's been a really big win for us that we're pretty proud of world domination storm table still on the table how about you Holly my team's focus this year was
you know data race safety and so six 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 you know at the beginning of this year originally it was built by a smaller group of engineers
and then more people got involved in concurrency so yeah I'm really proud of the work that the team has put in general into this release 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
how our messages are confusing and sort of seeing the community really embrace this new model of programming and come to a shared understanding and improve both the compiler and the documentation and the language I'm really excited to see where this goes from here. That's awesome Ben Cohen thank you so much for joining us I really appreciate it. Thank you very much Holly Borla thank you so very very much to both of you guys we really really appreciate it. Thank you so much for having us.
And thank you Apple for hosting and with that I think we're good. See you next week.