People Don’t Use the Weird Parts
So let's start with some follow up.
Why did Chris Lattner decide to leave Apple?
Last week we talked about this and we tried to list all the reasons we could think of why he might be leaving.
And I think we covered most of the major threads of speculation and we didn't really get a lot of listener feedback about it.
Anybody who did reply was mostly voting for one of the things we talked about.
But here's the thing on this topic.
unless there's some kind of like secret doomsday thing about apple that only chris knows it's not actually that important that we figure out like why he left apple or like what was in his heart of hearts like aside from just us being busy bodies or just wanting to know like gossip type stuff um and second pragmatically speaking this is just not the type of thing that people who leave apple talk about or you know if they do talk about it's like years and years later after no one cares anymore or you know like it's it's not a big deal
Um, so even if there was some deep dark reason, it's not like we would know about it until years from now.
And honestly, the straightforward, boring explanation is probably the right one anyway.
So, you know, I don't know.
What do you think, Chris?
That sounds about right to me, John.
would you ever buy an electric car in white you are such a jerk why are you so mean to me marco no no no i'm a fan of red cars there you go yellow if i could get them yellow that's bold my goodness all right uh we we obviously need to talk about what's happening right now so atp is not in an interview show but in extraordinary circumstances weird things can happen
And so in today's episode, we have an extraordinary circumstance.
Former Apple employee Chris Ladner was nice enough to join us on the show.
And so this is going to be three people interviewing one person, which is, to say the least, a bit peculiar.
And it's something that we've never really done before.
So this could be a little bit of a rough ride, but we're going to try to make our best of it.
And I'll just say right up front, thank you so much, Chris, for coming on the show.
And we definitely appreciate it.
To kind of kick all this off, would you mind giving us like a nickel tour of who is Chris Ladner?
Okay.
Well, I can try.
I'm a programmer.
I love coding.
I have for a long time.
I'm most...
widely known for starting LLVM and getting it off the ground and handing it off to other smarter people.
I started Clang, which is a C, C++, Objective-C compiler, and likewise got it to the point where it was thriving and then let other smarter people run it, and then started Swift and got Swift going, and it recently got past 3.0, and it has an amazing community, and it has a great team of people running it, and now I'm ready to jump to the next thing.
And so...
I guess the short version of what I'd like to do is tackle really hard problems and do things that most people think are impossible.
So we're going to go back in time a little bit, and I hope that you could tell us how you ended up coming to Apple, like if you can remember back that far.
LLVM, you started before you were at Apple, right?
So how did you end up at Apple?
Yeah, that's a great question.
So I started working on LLVM at the University of Illinois.
It was a research project, and it really was...
Kind of hoped for and designed to be fully general and production quality and all those great things that you'd want as a graduate student for people to use your code.
But it also wasn't.
It had a lot of the great architectural ideas, maybe, but it wasn't fully baked.
It wasn't.
It wouldn't solve all the world's problems.
And by the time I got to graduate, the question was, what do I do next?
And of course, my dream was to continue pushing it forward and build it out to be something real.
And to do that, I would have to go to a place that would allow me to work on it.
And I was really fortunate to build some relationships with folks at Apple.
And they took a chance on me, and I jumped to Apple and started building out LVM as my job.
It was totally a dream of mine.
So that's how I got to Apple.
Did you graduate?
Did you get your degree and then go to Apple?
Yeah.
Yeah.
Well, that was nice.
Otherwise, how would you ever get a job?
Yeah, you can't get a job without a degree.
We all know that.
No.
Yeah, clearly.
So...
How would you explain LLVM to somebody who doesn't know stuff about compilers?
Because, like, we all just rattle off, you know, LLVM compiler building toolkit or whatever.
But how would you explain that to someone, because not all of our listeners are programmers, who isn't intimately familiar with how a compiler works?
Sure.
So, I mean, first we start with what is a compiler.
A compiler is the thing that takes the code that a programmer writes and turns it into something the machine can understand.
Right.
And so there's lots of different kinds of computers with lots of different kinds of processors.
Most programmers don't want to have to think about that or know about that.
And they want to program and think at a much higher level than what the actual processor can do.
And so the compiler's job is to transform what the human wrote into something the machine can understand.
then LLVM is a modular system for building different kinds of compilers because there's lots of different reasons people would want to use compiler technology.
And I think LLVM was most successful over the years because it was built as reusable components, kind of like a framework, and then the framework can be used to solve lots of different problems.
And one of the fun things about LLVM is that it was eventually over the years used to solve problems that we had never even imagined, which is really exciting.
So one example of the type of problem is, I remember from past WWDCs, the idea that the Xcode IDE, the GUI that programmers use to make their applications, that very often in that GUI, you need to do things that have an understanding of the code.
But when the compiler is this big monolithic thing, the best you can kind of do is compile everything in the background and spit out some stuff.
But when it's a modular toolkit, you can...
Take those pieces and just use the part that understands like the syntax tree or whatever and integrate them.
Was that the first use of LLVM as something other than like, you know, a compile like a straight up compiler that you just point to your code and produces output like, you know, in other words, integrating it into applications or was there some use before that?
Well, I think the first use in production was in the OpenGL stack, which ended up shipping in a late software update for Tiger, as well as in Leopard, which is 10.4 and 10.5.
There it was used in a completely invisible way to basically repack data and upload it to the GPU.
And so when you're making OpenGL calls to say GL Vertex 3F or whatever the low-level GL call is,
those vertices need to be transformed into a very specific data format that GPU can understand.
And you have a whole bunch of different kinds of calls that can be used to produce for text or other geometry data.
But you also have a matrix of different kinds of GPUs you need to support, and they all have different formats and different capabilities and requirements.
And so LLVM was used to generate very small chunks of code to do that, and it was part of the 64-bit bring-up and the Leopard time frame.
And so that was probably the first completely invisible use of it that used and proved a lot of the kind of code generation technologies.
So forgive me one more LLVM related things.
We're going to go from what is a compiler all the way down to nitty gritty stuff here.
My vague recollection of what you just described, the whole video driver thing, was that there were files on disk in the shipping OS that were basically LLVM bytecode, like these little BC files.
And they would get slurped up and converted to machine code appropriate for the GPU.
Am I right about that?
Yeah, yeah, you're absolutely right.
And so basically the way to look at it is the bit code files, the LLVM that shipped with the OS were little snippets of code that then at runtime were recombined and optimized across.
And so that was kind of the library of primitives that the OpenGL runtime used to assemble what it was trying to do.
All right.
So my question about this, and maybe you kind of alluded to it with either a slip of the tongue or a revealing understanding is what is the difference between LLVM bytecode and what Apple currently brands as bitcode?
Oh, well, are you asking for historical?
Is this a historical question?
It's a technical and historical because I'm confused by the branding and I'm also confused by the tech.
So LLVM prior to LLVM 2.0, and these version numbers are the open source version numbers, not related to the Apple version numbers, and they're confusingly different for not very interesting reasons.
But before 2.0, it used a really horrible encoding in binary that was branded bytecode because that's what Java used.
It had a whole bunch of problems in that it wasn't extensible.
It was fragile.
The LLVM was changing.
It didn't have compatibility.
And so in the LLVM 2.0 timeframe, which, gosh, is probably...
I don't know, 10 years ago or more.
It's been a long time ago now.
I redesigned the whole thing and it now uses this quote unquote bitcode format and use bitcode as a term for two reasons.
One of which was it was different than bytecode.
And so the two could live side by side in the directory tree for a while.
And the second reason is that the encoding is a bitstream format instead of a bitstream.
But that's the origin of the term bitcode.
You can find documentation on this file format.
It's actually a very general encoding format that you can use for XML-type purposes.
It's a self-describing file format, and multiple different things can be encoded in bitcode.
yeah there was definitely some confusion about that because when apple presented it when they presented it as like the requirement was like the watch apps have to be in bitcode marco you would know this watch is required uh ios is still optional yep and then tv is required and they would have you uh send your put your stuff in bitcode and there was a lot of speculation uh early on about what that meant like uh in terms of
does that mean that what you're uploading is not a finished binary and therefore it's like this machine agnostic thing could be targeted at any cpu and the more prosaic version like it doesn't mean it's cpu agnostic all it means is that apple has slightly more freedom to like change instructions on the cpus they do target uh how would you characterize the what what what advantage are there
of compiling something to bit code and then uploading it somewhere versus sending someone a binary?
Sure.
There's a couple of different advantages for that, one of which is that the compiler keeps getting better.
And so if the compiler learns a new optimization, it can be applied to existing applications without app
developers having to re-upload their app.
So that's one small thing.
Other things are that Apple does periodically add new instructions to its CPUs.
One example of this historically was the
the hilariously named Swift chip that it launched, which was the first designed in-house 32-bit ARM chip.
This was the iPhone 5, if I recall.
That's right.
So in this chip, they added an integer divide instruction.
And all the chips before that didn't have the ability to do an integer divide in hardware.
You had to actually open code it.
And there's a library function to do that.
And so that and a few other instructions they added were a pretty big deal.
And
used pervasively.
And the only way to tackle that and handle that and use it effectively was to introduce an entire new slice.
And so if you're an app developer back then, you had the V7 slice, which was all the older chips, and then you had a V7S slice, S for Swift, which was the slice that included the integer divide.
Now, this is a pain for app developers.
It's a pain for Apple.
Everybody has to convince all the developers to take it seriously.
And if app developers don't support it, then the new hardware doesn't benefit from it.
And so BitCode allows that kind of thing to go completely away.
So with BitCode, Apple can just recompile the applications in the store.
say, ha-ha, this device has an integer divide instruction, and it works perfectly with the thinning kind of architecture they have for deploying resources to specific device types, and it all kind of plugs together.
Bitcode is not a magic solution, though.
You can't take a 32-bit app, for example,
and run it on a 64-bit device.
That kind of portability isn't something that BitCode can give you, notably because that is something that's visible in C. And so as you're writing C code, you can write ifdef, you know, pointer size equals 32, and that's something that BitCode can't abstract over.
And so it's useful for very specific low-level kinds of enhancements, but it isn't a panacea that makes everything magically portable.
The same thing, I would assume, for architecture changes, especially if there was an Endian difference, because Endianness is visible from the SeaWorld, so you can't target different Endianness.
Yep, yeah.
So it's not something that magically solves all portability problems, but it is very useful for specific problems that Apple's faced in the past.
And going back to the slice thing, that's like terminology, the Mako format, where you get to put different architectures worth of executables, or is that a different...
Yeah, I think that's technology that goes all the way back to Next when Next supported really heterogeneous different architectures like PA Risk and Spark and PowerPC and Intel, all back in the next days.
And it allows you to compile your application with multiple slices, they call them,
And then there's a tool called LiPo, which sticks them together.
And at runtime, the OS picks the slice that best matches your CPU in practice.
And so an app developer can support many different kinds of architectures.
And then the OS just does the right thing.
And so in today's world, it's very common to build an iOS app, for example, for both ARM64 and ARM32.
And the way that works is
uh in the native in the simplest cases it's just two different binaries that are stuck together and then the os picks the right one to run all right i could go on for this forever but i don't want to get too far down with this rat hole it's just uh there's some uh pent up questions about bitcode and bytecode but now i feel satisfied and we can move on to uh broader topics
We're sponsored tonight by Squarespace.
Go to squarespace.com and use code ATP to get 10% off your first purchase.
It's the new year.
You might have a new project.
You might have a new goal you want to reach, and that might involve making a website.
Make your next move with a beautiful website from Squarespace.
Squarespace sites are so incredibly easy to make, and they're incredibly beautiful, and the tools are very powerful.
This is a great combination that I personally have never seen before in the web building space until Squarespace.
The amount of power you get with these tools is just incredible.
You can make so many different kinds of sites with so little effort.
Nothing else comes close.
Your sites look professionally designed, regardless of your skill level, with no coding required.
Although if you want to jump in and alter some of the code, you actually can.
But you don't have to, and it probably isn't a good use of your time, because Squarespace is such a great platform right out of the box.
Whether you're making a website for you, or for somebody else.
If you make it for somebody else, Squarespace is the place you want to do that because you show them how to use Squarespace and then you're done.
They're not coming to you anymore.
Squarespace will support it if they need help and they'll be able to figure things out on their own because it's just so much easier to use than whatever CMS you were going to install on their server.
So check it out today.
Go to squarespace.com.
Use code ATP to get 10% off your first purchase when you decide to sign up.
Whether you're making a site for you or somebody else, make your next move with Squarespace.
So, Chris, how was your transition from coding to being a manager?
Because from an outsider's point of view, it looked like, you know, you had arrived at Apple, you were working heavily on LLVM, like you had said earlier.
But over time, I mean, even just looking at the resume on your website, it seems pretty clear that you were doing a lot more managing lately than perhaps coding.
Or maybe maybe just worked around the clock.
That wouldn't surprise me either.
But how would you how did you feel about your transition from from being just a code monkey to being a manager?
And I ask in part because at my phase of my career, I am still a code monkey, but I think it's not too far away that I might become a manager.
And so I'm curious to hear, you know, from from one code monkey to another.
How did that transition go and what did you learn from it?
Yeah, that's kind of interesting.
So I don't think it is a hard transition.
I'm still writing code.
I still love writing code.
That's something that I think is a key part of my identity in a lot of ways.
But on the other hand, it is very strange.
So I started managing people at Apple...
Really pretty early on, maybe a year or so after I joined, I started managing two or three people because I was kind of the best person to manage the nascent LLVM effort at the time.
And initially it was mostly just being a tech lead.
And so if you've ever driven a project where you have coworkers that don't report to you,
but you're kind of guiding them and helping make technical decisions.
That's where it started.
Over time, my team grew and eventually ended up picking up and running kind of a second level manager role where you're managing other managers and
Each step along the way, it introduces new challenges.
And along the way, I told myself that managing is something that I had to do because I was the best qualified to do it and I didn't want anybody else to.
And that coding was my real joy and passion.
And I think that coding really is my joy and passion.
But along the way, looking back, I realized that I am actually pretty good at managing things.
And I really do like building teams.
I like working with people.
And I've never considered myself to be a people person, which is – it's just very, very odd for me to even think about that.
But I actually do understand how people work and can really care about getting the most out of people and working with them to make them successful.
And so –
It's been kind of a transition over time, but I've always hung on to coding, and even though I have a full-time management job, I code like crazy on nights and weekends.
I'm not the kind of guy that likes to sit around idle, and so I've always just been busy.
So, I mean, you can get into as much of this history as you want to, Chris, but how did you get Swift to happen inside Apple?
Because from the outside, it's mysterious to us how big important projects come to be.
Like, you know, name the headlining things that have come out of Apple.
We hear that Apple does a lot of things that don't see the light of day.
How did you get probably one of the biggest things ever to come out of Apple in entirely new language?
created in-house how did you get that to happen and not just be some little thing that was off to the side that fizzled off and disappeared sure well so i can tell you about swift but i don't think you should project this onto every other project at apple because i'm sure they're all different so i can just talk about my experiences
So Swift started in 2010.
You know, it's kind of the timing is suspicious because it's right after a blogger wrote something about how Apple needed new programming language.
I'm not a blogger.
Oh, okay.
Ars Technica wasn't a thing.
Yeah.
not a blog that was a prestigious website still is okay okay i i stand corrected uh so i i don't remember if i if i read it exactly then and that's that was a causal link to starting working on swift or if it was just um because i had just finished up clang c++ support and we launched clang c++ and
Of course, if you write C++ code, you know how ugly and horrible it is.
But if you implement C++, it's a whole other level of challenge.
And so getting that first release out was a major accomplishment for the entire team.
And it was a major, major effort for a ton of people involved.
And as is typical, you get something over the finish line.
And of course, it wasn't fully finished.
It's a lot of long ways to go.
But a lot of the intellectually interesting, to me at least, pieces were done.
That's when I started thinking about, okay, well, what comes next?
And then implementing other people's stuff, like, for example, the C, the C++, the Objective-C standards and languages.
But there were things that we weren't happy with and things I wasn't happy with.
And so Swift started out as just a...
let's see what could be done, right?
Let's see what a much simpler language that doesn't need a preprocessor, doesn't need trigraphs, doesn't need all the weird things that have accumulated into C and C++ over the years.
Let's see what we can do and just try to build something nicer.
Initially, it was really just me messing around and nobody knew about it because it wasn't anything to know about.
But eventually it got a little bit more serious and said, hey, well, after playing around a little bit, I think that this actually could make sense.
And so I started talking to my management, started talking to some of the engineers that were working on Clang, and they seemed excited about it.
We got a couple of people working on it part time.
And I convinced my manager that it was interesting enough that we could have a couple of people work on it.
Now, this wasn't a major commitment.
This was a, okay, well, let's see what there is here.
And that started a kind of internal demo schedule and other things where we set milestones in place and tried to justify the investment that was being put into it.
Eventually, it got to the point where it was far enough along that it was posing strategic questions.
So the strategic questions were the form, okay, we have Objective-C.
Objective-C is a great language.
It is practical.
probably directly responsible for the iPhone being successful because it's really high performance.
It allows you to get your job done.
It supports high level frameworks in a beautiful way.
There's a ton of stuff to love about Objective-C.
And while there are a few things that are ugly about it, some at signs and semicolons and other stuff like that,
We can make Objective-C better.
And so the question was always, why not just make Objective-C better?
Why don't we just keep evolving Objective-C?
And why do we want to face potential disruption in terms of moving the entire development community to something new?
And we kicked that around for a long time.
We talked about both sides.
And we came to realize that, yes, we can and should make Objective-C better.
And we continue to invest in Objective-C.
We did things like Arc, for example, which is a major effort.
We got dots.
Oh, well, so dot syntax predated this.
Yeah, dot syntax.
So the Objective-C2 features and the block syntax were all kind of prior to this.
I worked on blocks, but it wasn't in this time frame.
And so we were talking about, okay, well, can we just make Objective-C better?
And can we feature creep it to the language that we want for the fullness of time?
Because if we can, that would be much less disruptive to the community.
And we decided that, yeah, we can move Objective-C a lot closer to what we want.
So we can get automatic memory management with Arc, for example.
But we can't ever take away the problems that lead to Objective-C being unsafe.
And the fundamental problem was Objective-C was built on top of C.
And C inherently has pointers, it has uninitialized variables, it has array overflows, it has all these problems that even if you have full control of your compiler and tool stack, you just can't fix, right?
To fix dangling pointers, you would have to fix lifetime issues.
And C doesn't have a framework to reason about that.
And retrofitting that into a compatible way into the system just wouldn't really work.
If you took away C from Objective-C, you couldn't use C arrays on the stack, for example.
And if you couldn't do that, there's entire classes of applications where the performance just wouldn't be acceptable.
And so we went around, around, around.
We said, OK, the only way that this can make sense in terms of the cost of the disruption to the community is if we make it a safe programming language, which means not safe as in you can have no bugs, but safe in terms of memory safety.
While also providing high performance and moving the programming model forward.
And so that was really kind of the ideas that came together to make Swift being worth the investment and being worth being disruptive to the community.
So a lot of these kinds of pitches and ideas were being held in very small meetings.
And coming out of WWDC 2013 is when we in the executive team decided, okay, let's really commit to this.
And that's coming out of WWDC 2013 is when the developer tools team
came to know about it and really started working hard on it.
And Swift is a huge, huge effort by hundreds of people.
And that's when all the work on bring up the debugger and the IDE support and playgrounds and all the other things that charge into Swift 1.0 really started coming together and make happen.
So that's kind of how Swift came to be.
It was, again, one step after another, building small things, explaining to people why it made sense, why it was worth it.
And then also I think that a major important aspect of Swift being, I guess, worth taking a risk on was that we told people that we would not guarantee source compatibility in 1.0.
And that was really interesting because that actually was a big relief for people because internally that meant that it didn't have to be perfect when it launched.
It meant that we could learn, we could adapt, and that as long as we were clear with the community about that, that that would allow us to get to ultimate greatness and learn from actual usage and practice.
And I think that was a really key piece to Swift coming and actually making it to the market.
So strategically speaking, when you were doing the work to improve Objective-C, did you have in mind the ability to potentially leverage some of that work for Swift?
I'm trying to think of the strategy of how you get it done.
Part of it is personal relationships and knowing the right people.
Part of it is persuasion.
You have to persuade them with your technical arguments and your business arguments and stuff like that.
But then part of it was part of it also...
laying the groundwork with efforts and technologies that have multiple uses?
Yeah, absolutely.
So one great example of that is ARC.
It was really clear to me that if we were to get to memory safety, we had to have automatic memory management.
And I don't know if you want to go down the GC versus ARC rabbit hole or not, but ARC seemed like obviously the right model to me and to some other people.
And so we said, okay, we need to get to an automatic memory management model.
Objective-C isn't because Objective-C at the time had the Objective-C garbage collector, which had numerous problems.
And so we had to get Objective-C to be memory managed.
And so that's why ARC became a thing.
It became a really high priority.
And I think that it's a great example of something that by itself had a huge amount of value to the Objective-C community.
And then after that, we had similar other efforts like modules, for example.
That was a huge thing that both improved build time, but was also absolutely essential to enabling Swift code to eventually just say import UIKit and get everything.
And so there's a number of things that rolled out over the years.
And it was really funny at the time because the Object-C developers externally and even internally to Apple always accused the compiler and languages team of taking Object-C on this random walk.
And they didn't know how it all fit together.
And where is the strategy?
And why are you guys working on this?
And why aren't you working on some other syntactic sugar for the thing I want?
And, of course, we could never tell them, but there was a good reason.
And so another example of that is the Object to See Literals feature.
I think we introduced that in 2013, if I recall, for array literals and other things like that.
That was an interesting feature in that it was a relatively small object.
amount of engineering work that brought the ObjectC language much closer to Swift in terms of having arrays and dictionary literals as part of the language.
But the real reason for doing it is that it was a small amount of work that moved ObjectC forward, which allowed the compiler and language team to focus on Swift.
Yeah.
Because Swift was a very large amount of work and that was, you know, appeasing the community and, you know, solving real problems.
But, you know, buying time to actually pour into the multi-year project of making the Swift language happen.
That's when you pull out the syntactic sugar.
Programmers love it.
It takes 10 minutes to implement.
Here you go.
Everyone applauds when they see the slide.
Yay.
I mean, in all fairness, that was a really big deal.
Anyway, so kind of building on the Apple internal reaction thing.
This language in its development and then its public release is probably a fairly unique language in the context in which it was released.
You have this massive company.
I mean, nobody probably had more Objective-C programmers than Apple does.
So you have this massive company with tons of internal programmers and a massive internal code base that is using this other language.
You have this entire community of iOS and Mac developers
And then you have the entire world watching every move Apple makes and putting it under very, very heavy scrutiny.
So the release of this language in this context is probably not only very high pressure, but also unique in that you knew that you were going to face a lot of people up front.
Most languages probably start out with a few people using them in some random corner of the internet, and eventually maybe it slowly takes off.
This was not that way.
And so...
What considerations, I guess, went into that?
And also, how were you able to convince people even inside of Apple to use Swift?
And how was that going?
So I guess there's different answers to that for different phases.
We...
Had no idea that the reaction would be as strong and as positive as it was.
And so I think we were blown away and caught unaware in some ways.
But in other ways, I think we did the right thing.
So, for example...
If you look at Swift over time, Swift 1 and Swift 2 are as similar to Objective-C as we can make them.
So if you look at the way that selectors are named, for example, there's a very direct correlation.
If you look at the way Swift 1 was explained to people, it was explained to people as...
It's just like Objective-C.
You can use all your same patterns.
You can use all the same frameworks.
You can continue doing object-oriented programming.
You can do all these things.
But it also has some cool new things like enums and pattern matching and these other things.
And so it's great because it's just cleaned up syntax for what you already know.
Plus it has some new cool stuff that you can play with.
And then you fast forward a year or two and the Swift community was really taking off.
People were understanding what Swift was about.
Swift open source also enabled this.
And Swift 3 is really about Swift becoming its own language that was really true to itself and stands by itself.
And that's where you see the method call syntax, for example, being radically changed and a lot of things just kind of coming together and
really focusing and polishing the language.
In terms of the rise of the external community and people using it, that was really, really hard for us because... So my experience had been with LLVM and with Clang.
Clang as a C and C++ compiler in Objective-C was completely different than Swift because when we open-sourced and launched Clang, which was at Apple,
everybody yawned.
We open sourced it very early on and people said, okay, you're nuts.
Nobody can build a C++ compiler.
That's not a thing.
Why are you even messing around with this?
And we got one contributor to the project and we had no users.
And then a month later, we might get another contributor or another person part-time sending in patches.
And it was a very slow growth that was ultimately really great because it was relatively low pressure.
With Swift and with the way it was launched, it was completely different because it went from...
nobody knowing about to everybody knowing about it overnight, literally.
And there being so much excitement, so many people that were nervous and had bad reactions, other people that were super excited, but a lot of people that were suddenly hitting bugs and having challenges and problems.
And why did you do this?
And why didn't you do that?
And some of that was misguided just because they didn't know Swift yet, but other aspects were really spot on.
And
that was when we really started learning about how people were using and started iterating and moving Swift.
And Swift between the WWC launch and Swift 1.0 release changed dramatically.
And that was a really, really hard time for the entire team because we really wanted to get it as close as we could to what we wanted, but we had a very short amount of time to do so.
And
And I think that's been true for Swift 2 and Swift 3 as well, where we have really high goals for the team and really high goals for what we want to get done.
And that makes it a lot of pressure and a lot of stress.
But it's, I think, worth it to serve and see the community around Swift grow and see people use it and see people learn it.
And it's been a lot of fun.
So I'm curious.
I know when Swift first came out, it was hard to get a lot of adoption inside of Apple for various tooling reasons among maybe whatever else was going on.
How is internal adoption going today?
Like, are we seeing meaningful adoption now or is it mostly iOS programmers who are using it and not anybody inside?
The Swift team itself...
has specific goals they need to achieve before there can be truly across-the-board adoption at Apple.
ABI stability is the number one thing that prevents framework developers, for example, from adopting Swift.
So that's a really important thing, and that's one of the reasons it's always a really high priority.
Um, but Swift has been adopted by application developers and other things.
The doc is public.
Swift playgrounds app is public.
Um, the music app and iOS is, is publicly known.
So there, there are definitely some big, big adopters.
Um, more broadly though, the big problem is, is that I think I won't speak for everybody, but many, many people
People doing Objective-C development at Apple are chomping at the bit.
They want to be using Swift.
And so it's really a matter of just getting the technology problem solved and checking off the things that are holding people back.
It's not about people dragging their feet and not wanting to use it.
Yeah, that's really awesome.
From the outside, it's so hard to figure out, you know, is Apple internally like, ugh, really?
Or is Apple internally, like you said, like really excited?
And I'm sure that there's some of both, but that's really good to hear.
Yeah, and I think it's also changed over time.
When Swift first came out, of course, it was a huge surprise for most of the software team.
And so, you know, many people...
went through the usual phases of what I already know, Objective-C.
Why would I learn this new thing?
Objective-C is great.
And Objective-C is great.
So that's an objective statement, right?
But I think things have shifted over time.
And as Swift has matured, it's definitely become a lot more appealing.
One other technology problem that is hilarious but also really important is the Apple Framework Stack has to support 32-bit Mac apps.
And 32-bit Mac apps have this interesting challenge of they have what's called the classic Objective-C runtime, which doesn't support things like non-fragile instance variables and things like that.
And so at some point in time, the Swift team will need to make the Swift runtime work in that mode or figure out some other solution to adapt it.
Because until that happens, it won't be possible to use Swift in AppKit, for example.
Yeah.
That's fascinating.
So kind of taking a more broad view, could you name either your most proud accomplishment during your time at Apple that you can discuss publicly anyway, or if not your most proud, just the first one that jumps to mind?
Wow.
Yeah.
I don't know.
I've been really fortunate to work on so many really important projects.
And I mean, I think that between LVM and Swift, for example, it's really a hard call.
Swift, I think, impacts more people in terms of the number of people that actually know they're using it.
and want to learn it and things like that.
But I think the LLVM has been picked up and used so far across industry and it's kind of standardizing the world's compilers.
I think that that's probably more profound at this point.
So it's really, it's a hard call.
I mean, there are a ton of really, really great opportunities that I've had and it's been a lot of fun over many years now.
Also outside the open source pieces, working with the Xcode team and
Working with the other teams and developer tools has been really phenomenal.
I mean, there's so many great people at Apple and developer tools.
It's just been a joy.
So what do you expect to miss most about being at Apple?
And I'm going to let you expound on this, but I'm going to take it off the table and say you have to pick your second choice.
You're going to say you miss the people because, of course, you do, right?
Yes, that is actually what I would say.
Right.
So go ahead and tell us about all the great people you work with at Apple.
But besides that, what do you expect to miss most about Apple, the company, working
Well, so the great thing about Apple and the thing that I don't think that many people really get about Apple is it is really one of the few best places in the world where you can work hard, but also work on products that ship.
And that ship to millions of people so that your hard work ends up mattering, right?
There are a lot of places you can work hard.
There's a lot of places that you can work on interesting things.
But there's also a lot of places that end up not shipping a lot.
Or if they ship it, very few people actually use it.
And so Apple's really, really magical in that it combines being, you know, being able to work hard and do great things with it actually mattering.
And to me, that's the thing that is just so phenomenal about Apple.
So moving on to your new role at Tesla, do you think that Swift will still be a major part of your work life in some way?
Or will it basically be like something you do in the evenings and weekends?
Because we all know that Silicon Valley tech startups don't usually work people too hard.
So you're going to have tons of free time.
Yeah.
Yeah, so this jump I'm making is definitely do a cushy, easy job with no stress.
That's what I'm looking for here.
So I don't know.
We'll have to see.
I haven't started yet, and I think it's going to be a very challenging job.
And one of the reasons I'm excited about it is because I really want to throw myself into another hard technology problem.
And so I'm really excited about that.
I do expect to be involved with the design of Swift and helping...
helping with the core team and helping Swift evolution process and helping in a lot of that kind of respect.
But one of the things to keep in mind is that Swift is actually a really tiny slice of my job at Apple.
And so, you know, I had a very full schedule dealing with lots of other stuff.
And it was already kind of a nights and weekends process.
project that I was coding on it and contributing at the level that I was.
So I'm hoping that there won't be a big change, but honestly, I'll have to see.
Obviously, I care a lot about Swift, and I really want to get to its goal of world domination.
So...
We're sponsored tonight by Eero.
Go to Eero.com.
That's E-E-R-O.com and use code ATP when you order for free extra added shipping.
Wi-Fi is broken.
You probably have one Wi-Fi router with, if you're lucky, a bunch of antennas on it that look hideous.
And you're trying to cover your whole house with Wi-Fi, but it just doesn't reach every room.
It just doesn't reach everywhere because Wi-Fi is hard when you're just covering it from one point.
Eero solves this problem by having a router system where they have this little Eero unit.
It's nice, it's attractive, it's tastefully designed.
There's not a bunch of antenna sticking out of it.
And you can buy one of them or you can buy 10 of them or any number in between.
And you put them around your house and each one covers the area in Wi-Fi.
And they all talk to each other wirelessly.
So you don't have to run wires all over your house.
You can have your entire house blanketed in Wi-Fi with Eero.
And they talk to each other over this mesh network.
So it's even faster than previous.
If you ever use like an extender or anything else, extenders are very slow.
It's even faster than that by a lot.
And Eero is true enterprise grade quality and performance.
They have everything you need from encryption features to things like parental controls.
And they're actually updating it over time.
They've done over 12 updates since launch with more to come to add features.
They have an app for very easy setup and they have incredible customer support if you need it.
They recommend one Eero per 1,000 square feet, so the typical home will have two or three of them.
They've got a three-pack as a pretty reasonable starting point for almost everybody.
There's a 30-day money-back guarantee if you don't like it, or if you just buy too many, you want to return a couple of them if you end up not needing as many as you bought.
Check it out.
The reviews are stellar.
They back this up.
Go to Eero.com.
That's E-E-R-O.com.
And use code ATP when you order for free extra-outed shipping.
Thank you very much to Eero for sponsoring our show.
Oh.
You know, obviously Swift is open source.
I don't know if you're aware of that, Chris, but how do you feel like it's been going so far?
And I'm assuming similar to John, you know, I'm going to take away the obvious answer of it's going well, but maybe to kind of cue conversation, what's been really surprising about going open source?
And you can get as specific or as broad as you'd like to be, but I got to imagine that
that you guys had a bunch of expectations about what going open source would be like.
And I would imagine some of them were accurate and some of them weren't.
So how do you feel like the Swift open source project has been going?
Yeah, so I think that to summarize, it's not just going well, it's going far better than we ever anticipated.
And that caused problems.
So for context, I and many of the other people on the team had quite a bit of open source experience.
So LLVM and Clang, for example, were open source.
They are vibrant and amazing communities with...
Hundreds of contributors and dozens of companies all collaborating in public and doing really amazing stuff.
Even some of the most staunch competitors, AMD and Intel and AMD and NVIDIA or these kinds of companies that really don't get along on the business side of things.
But the engineers were great at working engineer to engineer and solving problems and staying focused on making things better.
So with Swift, we assumed that it would be very similar to that.
But what we found is that there was a major difference between launching Swift and launching something like Clang, for example, which is that when Swift launches open source, which was December 3rd, just over a year ago, it already had, I don't know, a million users.
And where Clang started and everybody yawned and didn't really care and grew slowly...
Swift Open Source started and was amazingly fast-moving, changing, tons of people, hundreds of patches on the first day.
It was totally crazy, and we didn't really know what to do.
And so, I mean, I am, like, super impressed with the Swift Open Source community and all the people involved and the energy.
I mean, it's hard to believe how great everything is.
But it really did create problems because we had to figure out things like how we're going to stay up on in terms of the patch volume.
Okay, we're getting hundreds and hundreds of emails a day to the Swift evolution mailing list.
What are we going to do about that?
How do we balance Apple's goals for pushing Swift forward with the goals of the community, which are somewhat more chaotic and less directed?
And I think that over the last year, we've learned a lot.
And you can see that reflected in terms of
how the project's being managed and how things are being done.
But it's always been super important to be not just open source, but I guess if you look at an open source project, there's three kind of easy levels to look at it.
The first basic requirement that you have to satisfy to be open source is to make your code available.
right?
And so you can produce tarballs periodically, and that's technically open source.
You can allow contributions.
And if you do that through pull requests or patches or whatever, then people can engage with it and make the code better.
There's open community.
So not only do you accept a patch, but you actually discuss things and talk about things in public.
And then there's open design.
And with Swift, we went all the way.
And I think it was totally the right thing to do because we really wanted to benefit from all the smart people in the world.
And it was and still is amazing.
But it's also very challenging.
Yeah, I can imagine.
So building upon the open sourcing of Swift.
It was very surprising to me and I think a lot of the community that Apple chose to upload the entire commit history.
It wasn't just a here's day one initial commit and it's, you know, 11 gazillion files and 80 gazillion lines of code.
Was that planned from the start that you guys would upload the entire history?
I wouldn't say it was planned from the start that we'd upload the entire history, but it was kind of assumed from the start that it would be open source at some point.
Interesting.
And if you look at Apple's history, I think that's, in the tool space, I think that's fairly straightforward.
LLVM wasn't started at Apple, but almost everything Apple does ends up going public in the LLVM space.
Clang was started at Apple, and Clang was contributed by Apple to the LVM project, and that included its full revision history.
Other projects like LDB and libc++ and compiler RT and all these other smaller projects were started at Apple and contributed to the open source project.
So with Swift, it was kind of assumed that that would happen at some point.
the real question was when is the right time for that to happen?
And if you remember the days of Swift 1.0, Swift 1.0 to 2.0 in particular was a super chaotic, super learning as we went and trying to keep up with the community and trying to keep up with the pace and the challenges that people were facing and trying to get key pieces like the air handling model and protocol extensions and all that kind of stuff that had always been planned.
But
didn't make it into Swift 1.0.
And so really focusing on that was a priority.
And so we decided that open sourcing Swift at 1.0, for example, would be really actually bad for the Swift community because there are major pieces of language that weren't there.
And we would have to spend a lot of time community building and try and explain to people the difference between what was not there but should be there and what is, you know, there and known broken.
And we had to do a lot of that when Swift was eventually open sourced and developed.
last year right after Swift 2.0, but it was a much better place and the team could actually handle the load of doing the community.
And we didn't expect the kind of response that we got, but we knew that building a vibrant open source community is a lot of work and it's not something to be underestimated.
And we want to make sure that Swift 2 was out the door and it wasn't kind of a resource contention between do we finish Swift 2 or do we start open source?
Yeah.
And that's why it was announced to be open source by the end of the year, because that meant that we could start working on the open source infrastructure project, bringing up all the other stuff that it takes to make something open source after Swift 2 is complete.
So my recollection of Swift 3 in the planning stages was that ABI compatibility was somewhere in the list of...
I don't know if you want to call them goals, but somewhere in the list of items that were in contention for a Swift three.
And at some point along the development process of Swift three, ABI compatibility got postponed.
Um, and given what you just said about the importance of ABI compatibility for the framework people inside Apple or whatever, um,
What can you say about that?
Did you learn lessons from ABI compatibility being planned for Swift 3?
Or do you think like it was never really a hard and fast goal and you totally made the right call to delay it?
Or are you disappointed that it didn't make it?
Well, I think many of those things.
I mean, we're disappointed that it got delayed, but it was totally the right thing.
I think that there's a couple of things to learn from that, one of which is software schedule planning is hard.
Breaking news.
Yeah, so that's definitely still a thing.
There's also that we didn't anticipate the... So the original plan that you're referring to was announced before Swift was open source.
Sorry, it was announced the same time Swift was open source.
And so we had no idea that the community would descend on Swift and suddenly have all these new demands and consume so much time and energy that kind of took away from programming to do the community building piece.
So that was part of it.
Another part of it is that ABI stability is super important, but it's not as important as people think it is for application developers.
It's really important to Apple.
But what we realized in the Swift 3 timeframe is that the thing app developers would benefit from the most was actually source stability.
So who actually wants their application to be broken when they get a new version of Xcode?
Yeah.
really nobody, right?
And so kind of halfway through the release, we pivoted and source stability became the goal.
And so I'm really excited that when Swift 3.1 or Swift 4 comes out, that it's still going to be able to build Swift 3 code.
And even if there are minor changes that need to be made for one reason or another,
that you can upgrade and you have great compatibility with your old code and you don't have to start the migrator before you can do anything.
So it's going to be a great improvement for people's lives.
All right, so moving on a little bit to this branch topic here of server-side Swift, Swift on Linux, things like this.
Is Swift on the server something that... I know it's possible, and there's seemingly some early efforts now to get that going.
Do you see this as a major...
goal for Swift as the language and not in any kind of official capacity but just like you as a person who likes and uses Swift and has a strong role in the community like is server side Swift a thing that you want to be like a major thing to compete with things like Python and Rails and stuff on the server or is it intended more to be kind of like a specialized thing that is probably not going to be in widespread use by like web and back end programmers
So I think that everybody involved with the project wants it to be the way to do server development.
And I think that to understand that, you have to understand we're just kind of entering phase two of Swift's world domination plan.
Yeah.
So this will probably sound insane, but maybe in a few years it will sound less insane.
But the way I look at it and the way that many other people at Apple look at it is that we want Swift to be the next big thing, right?
We want it to be more popular than Java was or is.
We want it to be more popular than Python.
We want it to be maybe even more popular than C someday, right?
That would be a stretch, but that would be great, right?
And so...
If that's the problem to solve, how do you solve that problem?
Well, open source is a huge piece of that, right?
Without open source, it's not going to be available on other people's platforms.
It's not going to be used in education and teaching.
That's just not going to happen.
And so open source is a major piece of that.
If you go back farther before that, Swift world domination doesn't happen unless Swift gains relevance.
And I think Swift has nailed the relevance side of things with the iOS and Apple platform development side of the story where maybe not Marco, but most other people are switching to Swift very quickly and seem very happy using it.
Actually, I started using it today.
Okay, good call.
I switched today in honor of this interview.
I wrote my first Swift today.
An entire extension in Overcast 3.0 is written in Swift.
Wow.
See, fantastic.
Look at you go.
I'm proud of you.
It is a good day.
Yeah, and more will be coming.
Although there's a lot of Objective-C there, so I'm probably a long way away from it being all Swift.
Yeah, well, that's okay.
Swift loves Objective-C.
Exactly.
So the way I look at it is that the first step of Swift world domination is...
getting to relevance.
And for a language to get to relevance, it needs a killer app, right?
It needs a reason why people would want to use it.
And for Swift, that's clearly iOS and Mac and other Apple platform development.
Second, it needs to be open source.
Third, it needs to go beyond, right?
And the next step, the frontier of where it makes sense to expand out to, or if you're a real-time strategy game player, the natural expansion is a place where the language actually only needs a few things added to it to be good.
Yeah.
And so I think server development is really that next step because server development is very similar to app development in terms of the kinds of code that you need to write.
It's very similar in terms of many of the frameworks.
The major missing piece is that it needs to run on Linux and other pertinent server development platforms.
And there's then the whole library ecosystem that needs to be built out.
And so I think that what we're in right now is we're in a really exciting phase where those platforms are being built, those frameworks and different pieces of infrastructure are coming together.
And that's really the idea behind the Swift server working group that's an official part of swift.org is getting all the people working in the space to talk to each other.
And I'm very excited about that.
Going beyond that, though, with the goal of being more relevant than Java, for example, if we're going to pick on Java, the dream of Swift is to scale all the way from scripting language all the way down to low-level systems programming.
Like you could write a kernel in it or you write some firmware in it.
I think the scripting side of it is maybe more straightforward when the Swift community and the core team have time to deal with it because there you're talking about integrating regular expressions, integrating multi-line string literals, and integrating other features like that that people love from scripting languages.
And those are big projects, but those are kind of well-known, I guess.
And they will fit and drop right into the existing system that Swift provides.
Systems programming is, I think, the big next frontier.
And I think that's where Swift can really distinguish itself from Java or other programs.
other competitive languages because among other widely used languages out there, there's really nothing that can unseat C or C++.
Rust, for example, is an interesting language, but it hasn't gotten a lot of adoption yet.
And I think that Swift is more interesting than Rust and some of the higher level application domains.
But we'll see.
Rust is a great language as well.
And so I'm really interested to see the Swift for systems programming work get going.
And I think that'll be a couple of years out before it really comes together.
But once it does, I think that Swift can really be the next big thing.
And I'm excited about that.
So just stepping back a second to the server role of it, you know, possibly taking over there.
Because, like, you know, I would love, like, you know, here I am using PHP and Objective-C, these two languages that are fairly old.
And, I mean, PHP is way more hated than Objective-C.
But, you know, these are the two languages I use for various historical and practical reasons.
On the server, a lot of what makes a language succeed or fail on servers and in web development is
is not necessarily how good of a language it is, but how healthy and universal and developed the frameworks around it are for things like web development, how practical and easy it is to deploy and run on servers.
So Swift being its own good language, that alone I don't think is enough to get it to get traction on the server.
Do you think...
Is it necessary for the Swift team, like the core group who's running Swift, whether that's Apple or the community of contributors with Apple or whatever else, is it important for them to develop and kind of make official an official set of server and web frameworks and libraries and tools?
Or do you think it's sufficient to kind of take the risk to let the community do that but at the risk of fragmentation and maybe nothing ever taking off?
Well, so that's an interesting question.
And keep in mind that I don't have a lot of practical experience building server apps.
So this is... You're not missing much.
My opinion based on talking to other smart people.
So the approach the Swift project's taking is it's looking to standardize
what's colloquially but not correctly known as server foundation kind of technologies.
So it will not be named server foundation, but that kind of an idea.
And so take the encryption, the network transport, the HTTP kinds of things that
that everybody needs for server technologies, um, and standardize that as part of the Swift project, but at least in the short term, not look to standardize a specific web framework because there are half a dozen different, completely different approaches that are interesting and different, different kind of demands.
And I don't think there's a clear winner yet.
Um,
It's possible that after the first few rounds shake out, then there will be an equivalent, you know, Ruby on Rails kind of dominant pattern and framework that emerges.
And if so, then maybe that would make sense.
But I don't think Swift needs for there to be a winner at the high level.
As far as what can the Swift core language and language and compiler folks do about this, I think there's really two things.
One of which is the Swift package manager.
I think the package manager is really key to scaling out the ecosystem and getting people to work
um together with the common ecosystem it's also the best and i think only way to build swift code on linux and and other platforms i don't mean to single out linux it's just it's the biggest server development one um so i think that's a big piece i think the other piece that will be really amazing is when the concurrency model comes up because i think that's one of the reasons that makes um go particularly compelling for server development is it has really
well-developed story there, along with all the libraries that go together for server and cloud development.
And so when the pieces of the concurrency models start coming up, which will probably, the first pieces will ship in Swift 5, is my guess, that will make Swift an even more compelling kind of answer for that kind of space.
But I don't think we need a server language feature, if that's what you're asking.
So going to the other extreme from the server side and scripting to getting back to systems programming, one thing I've seen related to this, and I think this all stems from this quote from the original Apple Swift book that Swift was designed to scale from Hello World to an entire operating system, that the world domination plan was there from the beginning, right?
Yep, absolutely.
In the first paragraph of the thing.
When I talk to people now about Swift as a systems language,
uh often what i hear is people relating the ways that it is not ready to be a systems language yet which is you know what you just talked about but then deciding based on that that because it's not ready to be a systems language now it never will and then they dismiss it like in other words like that may have been the plan but clearly for reasons x y and z i you still have to use c for this therefore swift is just a way to write apps for ios and mac os and
uh how i mean i'm not quite sure what you can do about that but do you think about um how how to change perception as the language gets older and it's old age now it's up to 3.0 like that it starts to you know that that nobody puts swift in a corner like that that people think they know people think they know what swift is and they say oh it's this language that does this thing and that your plans for world domination may be thwarted by the idea that people are pigeonholing language because it's been around for a few years and i think they know it
I think that you're onto something.
I think that's a real problem.
I don't think systems programming is the place where that's a problem yet, though, because I don't think it's reasonable for me as a crazy man going around saying, Swift will someday do systems programming really well.
You should remember that.
I don't think that's a good way to spend time at the moment.
Um, when it does that, then the question becomes, how do you make that, um, make people aware of that?
And how do you get, get people to change their prior misconception?
But at that point in time, you can have a very practical, look, you can do this and this is so great.
And now you get all the advantages to see, but it's safe.
And you could point to specific reasons why it's better.
Um,
So I'm not too worried about it in the space of systems programming, but I think there is a practical problem today, which is Swift is open source.
The Apple development community knows Swift very well, but pretty much everybody else doesn't.
And if you go to a random, say, Linux developer, just to continue talking about Linux, they all perceive Swift as being an Apple thing and only relevant to Apple platforms, and they don't even learn about it.
right and so i think that there is an interesting challenge there and probably the best way to do that is for the existing communities to keep just growing and as this swift on server community grows and more and more people are successful building and deploying server apps certain swift i hope that naturally more and more people will become aware of that effort will
We'll then find out about Swift, maybe try it out, find out that it's actually really great.
And if it's not really great, let us know so that people can fix whatever the problems are and then just kind of grow out.
But I'm actually perfectly okay with it growing a little bit slower than it has been.
So John asked about the span between basically low-level systems programming and high-level applications programming.
I'm also curious that it seems like the Swift team slash Apple have presented Swift as not only spanning that wide range, which seems impossible.
but also spanning a wide range of skill levels of programmers.
So there's the Swift Playgrounds app on iPad where you have total novices writing Swift as their first language, all the way up to people writing systems-level things and complicated apps who are very experienced programmers.
Is it possible for a language to do all of these things well?
And if so, do you think Swift has achieved that?
So I do think it's possible.
I think it has achieved it for the things that it's doing so far.
And I think the challenge is that as new capabilities get added, that it doesn't jeopardize that.
But knowing the folks involved and the source compatibility guarantees and everything else like that, I'm pretty sure that won't be a problem going forward.
Here's the way I look at it.
Swift, you're unlikely to run to anybody that says that Swift is a simple language.
Right.
Swift is a complicated language.
It's not simple in the sense that scheme is simple, for example.
It's also not simple in terms of when you talk to an Objective-C developer, they'll often claim that Objective-C is simple, ignoring all the C parts.
I would never claim that for the record.
Right.
So C itself is a very complicated, weird language.
It's just that people don't typically use the weird parts.
Right.
And so they perceive C as being very simple.
Right.
So the way I project this onto Swift is that the secret to Swift in being easy to learn, easy to use as a teaching vehicle, but also powerful enough to solve the problems that need to be solved is that the complexity inherent in the language needs to be progressively disclosed.
So imagine if someday Swift had inline assembly support, for example.
Only really low-level systems people or really bit-twiddling assembly programmers would use this feature.
Everybody else would ignore it, and it would not increase the apparent complexity of the language to people who didn't know what it was.
For a feature like that, the most important thing is to make the syntax clear so that when you run up into it, you discover somebody else's code, you know that you don't know what it does.
Right.
And so you say, oh, that's interesting.
I don't know what that is.
And then you can do a search and find out, find the Stack Overflow article, whatever it is to say, explain what this is to me.
And then you can say, oh, okay, I get it.
And I either care or I don't.
But at that point in time, you can then dive in and learn more information.
Assembly is never something that a Swift Playgrounds person working through Learn to Code 3 would ever want to know about.
And I think that is really one of the secrets to Swift's success in terms of getting people on board and being really approachable for people at all levels is...
that just like in Python, you can start with just print hello world.
You could do the exact same thing in Swift.
And with Swift, you don't need the slash end on your string.
It's really just print hello world.
And from there, you can then introduce new concepts.
You can grow it out over time.
And this really allows people to understand either the syntax of language or the conceptual programming things that they're learning as they go.
And the design of Swift is really geared around that.
And so what that means, if you project on a system's programming features, comparing Swift to Rust, for example, I think it's very likely that Swift will get features for memory ownership control, which will allow really, really high performance.
It will allow solving performance problems with Arc, for example.
But unlike Rust, we can't make that be a core part of the type system that everybody has to use.
It has to be something that sufficiently smart programmers, when they're solving a specific performance problem, end up using.
Or an embedded kernel programmer might want to use, but an application developer can completely ignore.
And so that's really the challenge is it's deploying similar type system mechanics and other low level language geekery to the problem, but do so in a way that is tasteful and allows most normal people to just completely ignore it.
Everything you just said kind of reminds me of a saying I once heard that you're free to adopt for Swift if you would like, which is make easy things easy and make hard things possible.
We're sponsored tonight by Audible with an unmatched selection of audiobooks, original audio shows, news, comedy, and more.
Get a free 30-day trial at audible.com slash ATP.
If you want to listen to it, Audible has it.
You can listen to audiobooks from virtually every genre, anytime, anywhere.
You can play Audible's audiobooks on phones, tablets, computers, even Kindles and iPods if you still have them.
Okay, so let's get started.
because Audible offers their great listen guarantee.
If you start an audiobook and don't like it, you can exchange it for another one for free.
So check it out for yourself.
You can see and listen.
When you begin your free 30-day trial, you get your first audiobook for free, and there's no stress and no obligation because you can cancel your Audible membership at any time.
So with audiobooks and spoken word audio product, you will find what you're looking for.
Get a free 30-day trial by signing up at audible.com slash ATP.
That's audible.com slash ATP.
Thanks to Audible for sponsoring our show.
So, Chris, you brought up just a second ago how simple Python's Hello World is.
And one of the things I've wondered about Swift is it seems to some degree like it's kind of the what do you call it?
kind of via objective c but but my day job was as a c sharp guy and i see to my eyes anyway and i hope you don't find this insulting but i i see a lot of c sharp i see a lot of c sharp in swift and i've heard javascript people again i hope that's not insulting say oh i see some javascript in here and i presume that john could say that that he sees pearl in it i presume marco could say that he sees php in it again hopefully that's not insulting i see go in it i don't see any php in it okay fair enough
You get what I'm driving at, though.
And so I guess what I'm asking, Chris, is obviously there was a huge Objective-C influence in Swift.
But was there any one or maybe just a couple of other languages that you feel really, really inspired Swift?
Or do you really think it's the melting pot language that one would always hope to create?
Yeah.
I think it really is a melting pot because we weren't, so the goal of Swift isn't to ape some other language.
The goal of Swift is to just be great, right?
Right, right.
And so you can take, I think that Swift looks, or I and the other people in the core team, the other people working on Swift have looked at many, many other languages.
If you're a Haskell nerd, there's tons of Haskell concepts built in.
Protocols really are just like a very similar Haskell construct, for example.
Yeah.
And so it's really about taking the best ideas from where we can get and assembling them together.
And one of the major goals of Swift is for it to be familiar feeling, right?
Because if it's familiar feeling, that makes it easier for people to pick up and they're not fighting unnecessary barriers that just get in the way of adoption.
Yeah.
And so it being familiar is actually success in that way.
And it's not a result of Swift trying to be Go or C Sharp or whatever.
It's about taking the best ideas from them and assembling them together.
And I think that you could probably pick a language and there's some good idea that came from them, including...
uh you know d or dart or go or whatever i mean swift does really draw from many many different sources and it's really hard to um to really tease them all out so the question that casey wrote for me to ask you right now is how do you know that was me that's definitely you is
Why should I give a shit about Swift right now?
And I think I'm going to modify this a little bit.
That was written for you, my friend.
But yes, that is how it was written.
Definitely by you, right?
I figure that's not quite John's style.
No.
But as somebody who is just dipping a toe in Swift as of 12 hours ago and has waited this long, Objective-C, faithful slash holdouts slash lazy people who don't like learning new things very quickly –
What's kind of like the sales pitch for adopting Swift now?
I guess two different answers, one of which is you don't have to adopt Swift, right?
And I don't think Objective-C is going to go away anytime soon.
Apple still supports C and C++, and it doesn't have any specific benefit.
There's no obvious benefit of dropping Objective-C, as well as obviously they have a ton of Objective-C code themselves.
So I don't think that there's any reason you have to adopt Swift
Swift just tries to be a better answer so that you'll want to adopt it.
And in terms of why, Swift in its name kind of connotes a whole bunch of different things, including performance, but really to me the most important aspect of it is programmer productivity.
The idea that Swift is really optimizing for is not letting you pound out the code as fast as possible.
It really is designed and optimized for
As a programmer, you can spend the least amount of time to get to a working program as fast as possible.
And so getting to a working program includes the time it takes to debug something, includes the time it takes to iterate and develop and fight the type system and all the other things that you have to do.
But that time you spend having to fight the type system or figure out optionals or things like that,
pays itself back because your program works more often.
And so you're actually not spending time chasing down dangling pointer bugs or in the case of Objective-C, you get an unrecognized selector error, whatever those kinds of bugs are.
And Swift tries to help you by the language guiding you and helping design things.
Swift also has a lot of things that just make common things easier.
So you can switch on a string, for example, and then match the different cases.
You can use enums, which are a super enums are just from the language geekery world of just algebraic data types that are in tons of different functional languages.
They're not novel by any means, but they're so useful, and they solve so many problems just out of the box.
And just having them at your fingertips is great.
So there's a lot of things about Swift, and it probably depends on who you are, what your experiences are.
One of the problems I've seen with people moving from Objective-C to Swift initially is that they tend to write Swift code just like they wrote Objective-C.
And while that's a really good way to maybe migrate an application over or to get familiar with Swift, it really means that you're missing a lot of the value in Swift.
And I think that that's okay.
It means that an Objective-C programmer going to Swift first starts out by saying, I don't see what the big deal is.
And only after they spend some time in it do they start to realize that
Um, they, they are more productive.
They do feel better.
They reach for things that they otherwise wouldn't have.
And, um, I think it's really interesting to talk to people that have done, for example, a year of Swift programming, but then have to go back to objective C. And to me, that's, that's the really interesting thing.
So, so what was your experience?
It felt absolutely archaic.
And granted, I like to think of myself as a nice guy.
And so I'd probably say something like that, even if it wasn't true.
But the reality of the situation is, it felt just so old.
It just felt old.
And I don't know, I wish I could quantify that better.
But it just felt like I was back in time in a way that didn't feel good.
And in some ways, it was kind of nice.
So...
I do like optionals.
I understand why they're a thing.
I am all in on it.
But at the same time, there are times when I have to do a guard letter, whatever the case may be, that I really would just like to move on with my life.
And so not having to worry, being able to be a little more cavalier was kind of nice.
But the reality of the situation is, as you've said earlier, is that that's a potential hazard down the road.
And that's why I like the way that you and the team have set up the type system in Swift.
But gosh, going back to Objective-C is so frustrating for me because it just feels like I'm going back in time, like I'm going backwards.
And I think the challenge that Swift faces is because its focus is on building programs that work and that can be maintained and all the other things that we care about for large-scale software, it's maybe not the best solution for I want to pound out a quick script, use it once, and then throw it away.
Because in that case, you don't care about maintenance.
You can fit all the code in your head.
You don't care about good documentation or the other things that Swift encourages.
And that's a case where having a dynamic type system can be really liberating.
And so maybe that'll be a challenge for some people.
But I think that as Swift gains ecosystem and gains libraries,
its other advantages will be so great that hopefully it will be a good solution for those kinds of tools as well, those kinds of scripts as well.
So a minute ago, you mentioned how Objective-C programmers, people like me who are new to Swift, tend to write Swift like Objective-C.
And that's a concern I've had.
And it's one of the reasons that I have procrastinated adopting Swift up till now.
Because...
I have a pretty good grasp on Objective-C now, and I write Objective-C code that I know is basically idiomatic and soundly designed.
I write code in the style of what I think Apple's code would look like based on the little bit of headers and stuff that we see.
I feel like I write good Objective-C code that is kind of correct and idiomatically sound.
With Swift, I assumed that the idioms would not yet be developed for a while and established for a while.
And so I didn't want to write a bunch of bad Swift code or incorrect or weird Swift code, investing heavily in it so early on.
Do you think that it's at a point now where the idioms are starting to get worked out enough that that's less of a concern now?
Yeah.
Yeah, I do.
So I think it's definitely fair to say that in the Swift 1, the Swift 2 timeframes, Swift as a language was changing really rapidly.
And I could see why you'd feel like you're on uneven footing and not really sure what the language is, much less what the idioms are.
Swift 3 really is quite well baked out.
And so I expect that going forward, the new things are going to be additive.
They're not going to be
changing the existing patterns.
And so I think the Swift community in general has gone through the same kind of thing that you're feeling there, where it's not really clear the one right way to solve the problem.
And maybe there are different good ways to do it with different trade-offs that weren't clear to people.
But I think people are starting to understand that now.
There are a few style books that are being written by people that I've heard about.
And so when those come out, those will hopefully be good and those will be a good resource.
But another thing to keep in mind is that Swift is opinionated, I guess, is the way to say it.
So it really does encourage you to do the right thing where it can.
And so, for example, if you use var for everything, the Swift compiler will say, hey, you marked this as a var, but it could be a let.
And that's just its subtle way of, and let me fix it for you, right?
And that's just its subtle way of encouraging you to use immutable values, which is a very small thing, but it's just kind of pushing you in the way that it
it leads to better code.
And immutability for a local variable doesn't matter that much, except that it communicates something more to the person who has to read and maintain your code.
And so I think that Swift really does kind of encourage you down the right lines in some ways.
But on the other hand, in other places where you're saying, hey, should something be a class or should it be a struct, the tradeoffs are more nuanced, and it's a harder thing, and the Swift compiler can't just know what problem it is that you want to solve, and so it can't help you with that.
So you mentioned Swift Style Guides before.
As a creator of a language, how much influence do you feel like you want to have over things like style?
Things that really are...
you know it's not it's not features it's not technical it's just like uh you know what you we all know the different style things like oh you know you should only have one exit at the bottom or you should exit early or i mean like there are things you can do uh even things like spacing and brace style for crying out loud or you know or just the sort of idioms of like this little three line sequence is how you do this transformation on this data structure um you mentioned you know language features can influence that so obviously as language designer and participating in that process you can effectively
uh guide the community style wise in one direction or another but eventually you come to the stuff that's just plain opinion and style and several other languages have had fairly concrete styles set forth early on by the creators we want to go like knrc uh style type things how much do you care about being able to influence the
I guess the personal preference or the aesthetic, uh, portions of style that are outside the things that you can influence as part of language design.
Um, so as with any programmer that has a pulse, I have my preferred style.
Um,
And so clearly that's the right way.
Naturally.
Naturally.
Well, so I guess more seriously, the language itself does influence some of the things you mentioned.
So for example, it's my personal opinion that the style where you have a single entry and a single exit from every function, I think that leads to really difficult to maintain and read code.
And that's one of the things that led to the guard statement existing.
The guard really does encourage you to use early exits.
So you handle the exceptional cases and they don't have to worry about them.
So that's an example of where the language design is kind of encouraging you to have multiple returns from a function.
Other more subjective things like the number of spaces.
I personally am a fan of two-space indents.
I know some people are staunchly four.
Other people are staunchly eight.
Some people think 80 columns is the right answer.
I mean, all these things are...
There are actually really good arguments on all sides.
Some people argue that you should use three space indent because then you certainly can't have tabs in your file.
Wow.
So this is where it comes down to you have to pick your battles, right?
And people will disagree for a long time.
Yeah.
You can make arguments on both sides, but where we've come down is that it's just more practical to let people write code they like to look at.
And that comes at a cost of if you switch between teams or you pick up somebody else's package, then maybe it's indented the wrong way.
But I don't think that really actually...
actively hurts the comprehensive comprehensibility of the code.
That's merely annoying.
And having something like go format, which rigorously enforces the one true way, I think would have been nice.
It was just wasn't a priority early on.
And it also just wasn't a battle that we were willing to tackle.
And I don't know.
We'll see.
I think this is still also an open question in terms of what other tooling gets built and what other things come into the fray, because it would be great to have better tooling around this.
It just hasn't been built out yet.
And it's a great opportunity for open source as well.
i was thinking about the sort of doomsday scenario where like one of these these swift style guide books comes out and like it makes some like blanket recommendation that like you should you know always use protocols for this and you should never use classes for that or whatever and it becomes wildly popular and accepted as like the bible of how you write swift programming and you're just somewhere shaking your head and going no you got it all wrong
But I guess, you know, we'll cross that bridge when we come to it.
I mean, I think at this point, the language design itself and the community has had enough influence that that's not likely to happen.
But, I mean, I guess what I was getting at is, do you feel like that you want to write a Swift style guide?
Like, if you had unlimited time?
No, I don't think that would be a good use of my time.
But if I had unlimited time, maybe.
I don't know.
It's hard to answer that theoretical question.
But I also, to your concern about, somebody came out with a style book that was so wrong that it would cause me to, like...
You know, be really unhappy.
I actually have a ton of faith in the Swift community because if something came out that was so weird, I don't think that the community overall would accept it.
The community has, again, just kind of blown me away with how clueful they are and how many great people have gotten involved with Swift and the Swift evolution side of things.
And it's been really amazing to see these people, you know, they go through their own personal experiences
on the swift mailing list where um you know initially they're saying hi i had this idea what do you think and the response is no that's a terrible idea for this this is this reason but then they come back and they're like hey how about how about this do you ever think about this and it was like oh well that's interesting that almost worked but it didn't work because of that and then they come back and they say hey well what about this and
We said, well, we actually tried that and we had that for a while and then had to back out and change it this other way because we didn't even think about this other thing.
And then the next day, they're the ones saying, this is the way it needs to go.
And everybody says, you're right, we should do that.
And it's really hard for people that haven't been involved in the overall design of anything as complicated as Swift to be able to discern the difference between something that is the way it is,
out of an intentional decision process or the way it is as an act, an accident of history.
And so as now that the design process is public, I think that it becomes a lot easier for people to, to tell that.
And it's very easy for people to kind of
I understand that difference.
The one big debate that I haven't actually seen is why is the funk keyword the funk keyword?
And that's one that luckily we're now beyond the Swift 3 source compatibility threshold.
So we just can't have that discussion anymore.
I think that would be great.
darn one of the best things that the swift open source uh thing what uh the whole evolution process has is like the list of questions like the asked and answers questions like this is a commonly asked question and we've dealt with it before and you're probably going to want to ask it too so here's here's how it was asked before and here's what the answer is not that everybody's going to go and see that but i love that that exists
Well, and it's also hilarious that that started out as the commonly proposed list.
And then at some point it became the commonly rejected list.
Yeah, right.
Because if it's commonly proposed, obviously it's not getting through.
And so you have to go to the rejected list.
If you're thinking about asking to change funk to FN, you know.
I know you talked about this before, but it's worth touching on again because many people have asked me to ask you this.
A Swift and a Rust style memory model, you phrased it before as...
an add-on feature for people who know that they need that type of thing but that it would not like that swift wouldn't become a language in which all memory is managed that way instead this would be a special purpose feature for particular roles what what roles uh do you think it's suited for and why why is it not the right memory model for all of swift
Well, so here's the way I look at Swift in terms of memory management today.
So Swift is using Arc.
It's not using GC.
If you want to talk about the tray-offs there, I'm happy to do that.
That's its own rat hole we can fall into.
Arc, I think, is overall an amazing default for Swift because it gives you deterministic destruction.
It gives you relatively predictable performance.
And the Arc optimizer is able to eliminate most of the reference counting operations that happen.
The problem that I see with ARC as of today, or say Swift 3, is that it is not a very controllable model.
And so if, for example, you have an inner loop, and it turns out the ARC optimizer is doing a bunch of retains and releases, and you know that they're not necessary because you know the objects are alive, there's nothing that you can really do to solve that problem.
unless you're willing to drop down to something like the unsafe operations that Swift gives you for manipulating references to objects.
And so it's really kind of dissatisfying to me to have a really safe, great memory model that for performance reasons, you have to drop down to unsafety.
This is a huge cliff, and it's also a huge complexity cliff that you have to drop into to solve that problem, and that's not really great.
So the promise, the dream, is to instead say, hey, well, if you are a sufficiently advanced programmer and you know how this stuff works, well, we can give you a new option.
Instead of dropping down to unsafe constructs, you can actually just use more static type information
in annotations in your code and so you add a few annotations say hey compiler this is okay the compiler can then validate those type annotations and check to make sure they're correct so it's still memory safe it's still guaranteed to be okay but you're paying for it in terms of more of this annotation in the code and it's more more heavyweight in terms of coding but what you get out of that is the guarantee that no arc operations are happening so
Once you get to that model, then it becomes really interesting because you can say, hey, well, in this inner loop, I'm going, I found in my profiler that it really does matter for performance.
And the Arc optimizer is doing the wrong thing.
Well, I can add a few local annotations.
And now the code is fast.
It's guaranteed to be fast.
And the clients of my code don't have to know about it, right?
This is an implementation detail.
And I think this will really bring us to the best of both worlds where you could have memory safety.
You can have a progressively disclosed complexity system where most people don't have to know about it or think about it.
But you can get to really low-level performance guarantees that otherwise aren't possible.
And once we do this, I have a feeling there'll be certain communities of people that will only want to work in this model.
And these are the communities that like Rust predominantly.
So if you're writing a kernel, for example, maybe you don't want to have a reference count in your object at all.
And maybe you just want to have, you know, you say, I will always use these annotations in my code pervasively.
And if that happens, then there's a couple of options that we can investigate.
And we could say, hey, well, if you mark this class with some attribute, then that prevents the compiler from ever doing reference counting.
And if it would ever do that, it just raises an error.
Or we could even theoretically have a language dialect mode that said, hey, produce an error any time it did an arc operation.
I don't like language dialects.
And so we'd have to find a way to handle that.
Maybe it would be a warning and then they would upgrade it to an error or something like that.
But I can imagine doing something like that.
And once we do that, then I think you get to a really interesting mode where those systems programming type people that otherwise would be using C or C++ can now use Swift.
And that means they only have to learn one language.
That means that they could use the same tool set that, you know, the IDE and everything else that,
works great with Swift.
It means that they can scale and use the same language for different layers of their stack, because many applications have very low-level pieces and very high-level pieces, and having them written in different languages is really kind of gross.
I mean, I think we've seen this in the Objective-C community where one of the best and most annoying things about Objective-C is that it has C in it, right?
And so this has been hugely important for Objective-C in practice because if you run into a performance problem with obviously message send, you can always rewrite that algorithm in C.
And that's really, really, really important for Objective-C being successful and, you know, both in the days of Next on 16 megahertz processors, but also today for the low-level code that people are writing.
But it also means that that's one of the problems that makes it so that Objective-C and C are so tightly intertwined.
And so you can't actually take the C part out of Objective-C without producing a different language.
Yeah.
We're all waiting for Swift in the web browser because it's your only escape.
Speaking of applications that have to have one language at the higher levels and a different language at the lower one, that's a tough one.
Well, that I think is a frontier that is probably the biggest payoff because replacing JavaScript would be such an amazing service to the world.
You just mentioned Dart before.
It's been tried.
Yeah, but it's been tried, and that's where I'm putting my hope on the ASM.js, the WebAssembly, those kinds of efforts where it's enabling languages like Swift, and Swift compiles through LLVM.
WebAssembly and ASM.js both have LLVM backends in principle, so they could wire up Swift to one of those and go to town with it.
If those end up winning and they become big, big things, then maybe that'll be good enough.
But I don't really know.
I don't have my crystal ball doesn't go out to the point where JavaScript is not in web browsers.
Yeah, that's the difficult part.
It's not the language mechanics.
It's the getting something that can understand that in front of as many people as possible.
Well, it's also very interesting to me.
So, again, I'm not a web developer and I'm definitely not an expert in the space.
But to me, it seems that the trajectory of JavaScript has changed.
basically made it into an intermediate language.
It's not something that developers are writing as much directly as they used to.
And so I see TypeScript and a lot of other languages that now compile down to JavaScript.
And, you know, they're really using JavaScript like a bit code representation, not a source language that people are thinking about as much anymore.
And so I wonder if in five years...
you know, the natural conclusion of that is that JavaScript is just an Asm.js type of thing, or maybe WebAssembly does take over.
But again, I'm not the expert.
I don't know where that direction will go.
I know that some people love JavaScript.
So we'll see.
On the topic of using languages other than JavaScript to write JavaScript, I have to say, having done that several times, that the tooling, boy, the tooling is not quite where you'd want it to be in terms of being able to
write and debug and profile in the preferred language and not in the compiled down to JavaScript type language.
But yeah, maybe that'll be like stage 17 in the Swift world domination plan.
Well, and I think that's always been true for preprocessors.
So, I mean, even in C, if you do crazy things, the macro preprocessor in C,
You get debugging those things that are so horrible.
And that's one of the reasons that we've been careful about not adding a macro system to Swift early.
It just brings lots of interesting trade-offs in terms of the debugging and developing and designing experience.
One last thing on ABI compatibility.
According to the timelines that I've heard sketched out, ABI stability could be a thing before async or concurrency stuff lands in Swift.
Are there any...
Is there any dependencies or chicken-egg things involving there?
In other words, do you have to nail down some aspects of your concurrency model before you can commit to ABI stability, or are they totally orthogonal?
I think they're totally orthogonal.
I think the memory ownership model has more of an impact on ABI stability because there's some very low-level things like how the...
the getters and setters are co-generated for a property, for example, that end up getting impacted by the ownership model.
That's one of the reasons that the Swift team is actually actively designing and working on a proposal for the memory ownership stuff right now.
It's not so that it can be a Swift 4 feature.
It's so that the ABI stability work can be done in light of the ultimate model for the memory ownership support.
And I think concurrency is not going to be something that impacts ABI stability at all.
But we'll see.
And if so, then the sufficiently smart programmers that work on Swift will figure it out, and I'm sure it will be great.
I think it's also an interesting question of whether ABI stability will be done for Swift 4 because it's a huge amount of work.
The work is well underway, of course.
But it's also not clear to me that's really the...
the right or the most important thing for the swift community and one of the things that ted has been a huge champion for and i think he's right about is that the most important thing right now for the swift community is making the compiler more reliable making the error messages better making compile times faster and making it scale better to large projects and
We'll see how the rest of the Swift 4 schedule goes, but I wouldn't be surprised if at some point they decide that focusing on that is more important than nailing ABI stability in Swift 4.
So you just mentioned Ted.
That's Ted Kremenich, who's now the lead of the Swift project.
Is that right?
Yeah, he's the project lead.
So Ted has been managing the Swift and Clang projects before that for a number of years.
He's been at Apple for 10 years now.
He's a Stanford PhD graduate.
He built almost single-handedly the first Clangstack analyzer.
Yeah, that's Ted.
So as a – I love that I'm saying this now.
As a Swift developer –
you know should i be like you know as we saw when you announced that you were leaving apple that we saw some of the people the community asking like should we be worried about swift's future is swift in good hands now i mean you know it seems like most of us didn't know ted at least didn't know his name or weren't familiar with his contributions uh it does seem like he's been doing quite a bit there anyway um should we be worried um i don't think you should be worried at all i think swift is in amazing hands as is
I mean, all the things that I am leaving behind at Apple in quotes are in really good hands.
And that's one of the only reason I was comfortable in moving on.
In the case of Ted, Ted is a rock star.
He has been running the Swift team and managing them for years.
I mean, four or five years now, um, the, the roles that we had was that Ted owned and ran his team and then reported to me.
And so I would mess around and, you know, cause trouble by, you know, trying to get people to do the exciting, important thing that I thought, and maybe it didn't align with the actually important thing.
And therefore I'd introduced chaos into the world.
Yeah.
But Ted was always the stable rudder and the one that was really focused on getting the important things done.
And he has a number of really exceptional engineers in the team, people on the core team like Doug Greger, John McCall, Joe Groff, Dave Abrahams.
These are all just amazingly brilliant people.
And also the team includes a bunch of other engineers that are...
Equally dedicated and also just totally amazing people to work with.
So the Swift team is, I think, one of Apple's biggest assets.
It's crazy how brilliant and dedicated they are to the project and how excited they are to get to world domination one step at a time.
Coming back to kind of a more broad thing, let's say that, and this is not meant to be a tongue-in-cheek reference to your next job.
This is just in general.
You're at home, your kids are in bed, your wife is out or something like that, and you want to just write some code.
You can't use Swift and you can't use Objective-C.
What are you writing code in?
And I know that's often dependent on what project you're accomplishing, but what's interesting to you these days that isn't Swift and isn't Objective-C?
Yeah.
Oh, well, so I mean, I have a ton of different interests.
I mean, I really love building ray tracers, for example, and I've done a bunch of stuff with that.
And I guess if I couldn't use Swift for that, then I would probably have to use C++.
I was going to call that, but I wanted to give you a chance to not say C++.
This is what I remind people when they mention, you know what LLVM is written in, right?
Write that much C++ and not have your answer be C+++.
And do you know how much angst and personal suffering it causes to have to be writing C++ all day and building a beautiful world for other people?
It's just so unfair.
Yeah.
That's where you toil down in the mines.
Yeah.
Yeah.
It's a pain and suffering that's worth it for the bigger victory.
Well, that's where Swift comes from.
Years having to use C++.
I can do the same stuff but not feel this much pain.
That's exactly right.
I mean, there's a lot of suffering that led to Swift needing to happen.
So, but, but it also, it really depends.
I mean, maybe if I was doing, you know, if I was a crazy person, I'd use Pearl for something.
I don't know if I'm that insane.
Well done.
Well done.
You'd never be able to read it though.
Nobody could.
Hey, if it's throwaway code, then you never need to read it, right?
Poor John.
I'll just wait for my ProSix grammars to land gently in Swift.
That is a great example of...
Perl really has nailed the string processing thing, even in Perl 5.
And I think Perl 6 is even better.
And Swift has a lot to learn from it.
And that's something where Swift 4 is really learning from Perl.
So I think that's great.
Please don't give him any ammunition.
This is terrible.
I was enjoying this interview so much until this very moment.
Look at it this way.
Once this happens, John will have no excuse.
Oh, he will find one.
Nothing is so perfect that it can't be complained about.
Oh, my goodness.
This is a perennial topic on the Swift mailing list.
It's about dynamic features in Swift.
Things that are, quote-unquote, more dynamic in Objective-C and less so in Swift.
In the Swift community, there's a lot of angst about...
When, if ever, will Swift allow me to essentially, you know, like what you said before, you can write Fortran in any language.
You can write Objective-C in any language.
People will try to write their code in Swift, but using models from Objective-C that require things like, you know...
You know, sending messages to objects that you know will receive them, but the compiler can't guarantee or, you know, having big heterogeneous collections where you're just like, no, everything's ID and it'll be fine.
I don't even know how to frame this, but I think that the main question has been.
Are dynamic features possible in Swift?
And are they coming in Swift?
Or is there some kind of philosophical divide where the most dynamic stuff that people really want will never be forthcoming, not for technical reasons, but just for philosophical and safety reasons?
Sure.
So I've been pretty outspoken about this on the Swift evolution list, so hopefully this isn't a huge surprise.
But I don't think there's any tension between...
dynamic features and Swift.
A lot of people want to make hay and argue about how it would be impossible to do responders or pick your feature in Swift.
And the worst case scenario, frantic blog posts I've seen are things that
are along lines of someday apple rewrite all of its frameworks in swift and then it will be impossible to write responder chains and then bad things will happen and then we'll be back in the days of msc or some other bad thing right oh god don't even bring that up
Exactly.
And so this is kind of quite the slope that the discussion ends up being.
I think this blew up most recently, right before WWDC this year.
And it was really interesting to watch the blog posts that people were flinging around because everybody had a different idea of what dynamic meant.
None of them really...
And Apple's not going to counter blog somebody and like denounce somebody's blog on somebody's post.
And it's kind of bad for him to do that.
But I thought it was very interesting and odd that none of those people actually came to the Swift evolution list, which is the right place to do that and asked about it.
They all just wanted to make these inflamed blog posts for various kinds.
So if you get to my opinion, my opinion is that none of those are in tension with Swift's current design.
It's just a matter of prioritization.
And the major problem that Swift has is, again, there's so much work to do.
There's
concurrency model, there's actors, there's systems programming, there's scripting, there's lots of little things that go in, there's better things to support static analysis, introducing type state into the language, there's pre and post conditions.
There's so many things that will be bricks in the house of Swift that we want to build that need to happen that it doesn't really make sense to spend a lot of time building dynamic features
so that Apple could theoretically someday do something, right?
The Swift team is much more focused on the practical necessities of solving the real world problems here and now in front of people.
And dynamic features, like many other things, will just kind of flop in place when the team has time to design and roll them out.
And so you will be able to someday, or I expect that you will be able to reflect over all the methods that a class has, for example.
Today, even the Swift compiler is generating all the metadata so you can reflect over all the data members and your values.
We just don't have an API wrapped around that.
But that metadata is what the Xcode memory heap viewer uses, for example.
And so there's a lot of that kind of stuff being put in place, but
It just hasn't had time to fully bake out yet.
And when it does come in, I think it's going to be really exciting and we'll open more doors for new kinds of patterns that people can do.
And a lot of those will be familiar to Objective-C programmers, but they'll also be super useful for things that people really haven't done in Objective-C.
So I don't see a lot of tension there, though.
It's just a prioritization question.
I think where people are coming from is in terms of prioritization, because if you're used to doing things with certain sort of design patterns, broadly speaking, in Objective-C, and you want to come and implement those same patterns in Swift and you find that you can't.
because you're lacking some feature it feels like there's a barrier up and that's that's getting back to you know writing writing your swift in objective c style and that's more of a barrier they retreat back to objective c because i can write it the way i wanted to write it right and it works in objective c when i try to write it that way and swift it doesn't work for me your choice is to change the way you write it to be better fit for what swift has or to go back to objective c um so
I don't agree with that, though, because Swift does support all the features for dynamic dispatch and method lookup and everything else that Objective-C does.
It just requires you to use the Objective-C subset of the language because it exposes it through the runtime.
Right.
That's the tension because they're like, oh, I want to write in pure Swift, like as if there's something special and magical about not using Objective-C runtime.
You know what I mean?
You do get a medal for that.
Yeah.
i guess it makes some people feel good um i mean there are i i can't really counter that but i just don't think that it the it's actually fair to say you have to fall back to writing objective c code yeah no no i'm just i'm trying to i didn't write one of these blog posts so to be fair i'm
I'm trying to express what I saw in that because that was a lot of the concern was like they want to do it.
They want to do it like the new way and the right way.
And part of doing that is not, you know, at objective seeing everything.
They feel like, oh, that feels like a compromise in the old way.
So they are setting their own goalposts for themselves arbitrarily to try to enter into this new world.
And, you know, they...
they want to jump in with both feet or not at all.
And, and some of them might end up, uh, bailing.
But I think this, I mean, the, the way, the way I look at that is, um, I look at that as an area where the language is not fully baked out.
It's not, uh, fully serving their needs.
And I think that's really unfortunate.
Right.
And I'm not going to say that.
I think that that's not a good thing.
I want there to be an awesome reflection model.
I want there to be awesome features for sending messages.
Um, like they're used to, I just want to be developed and designed in the right way.
and at the same time they're being annoyed that they can't do those things there are a lot of other people being annoyed about compile times right yeah no i know and and what what we have to do is balance between you know just picking two random things where does the engineering effort go and um and that's never a black and white thing there's never a right answer it's all based on
gut and judgment and guesses, listening to the community, talking to people.
And that's one of the reasons why I think the Swift team is really phenomenal is that it really cares.
It really cares about what people are doing.
The various people read the blog posts or people on Twitter.
The engagement between the Swift team and the community is really high because people care.
And there's no management dictated Apple that says that, you know, this engineer should be on Twitter all the time talking to people.
That's certainly not the case.
That's because of passion from the developer and it's because they really care.
And I think that's the thing that is so amazing about the Swift team is just how important it is in terms of customer service and understanding what people are working through.
And that insight is what guides the priority decisions and guides the trade-offs that have to be made all the time because nothing really is as clear as you'd like it to be.
So building on that, when all of us were going back and forth and I was –
Tangentially involved with this.
We're going back and forth about, oh, Swift isn't dynamic.
It must be dynamic.
Is it fair to say that that does eventually make its way inside of Apple?
Just that you guys are aware of it, that that's talked about in some way, shape or form?
It's nice to know, and I suspect that it does, but it's nice to know that when the community gets perturbed, whether or not that feeling is justified, that at least somebody inside Apple has heard it.
Whether or not they can respond to it, at least they've heard it.
So when we all get our pants all twisted up, does that make it in?
Absolutely.
I mean, there are a ton of people at Apple that care about what's happening in the developer community and elsewhere, right?
And that's one of the things about Apple's approach in terms of not commenting on things that can be frustrating because you don't know.
But again, there's so many people at Apple that really do care and that saw it.
And, you know, again, I wish those people that were really worried about it would come to Swift Evolution and ask because then we could have a...
Discussion about it, but that wasn't happening for some reason.
But certainly there was a ton of people that saw the blogs.
And I'm sure there are tons of engineers at Apple that feel the same way and wish the priorities were different.
And I think that the engineering community inside of Apple reflects quite closely to the engineering community outside of Apple as well.
And I hope that's not surprising.
Apple has many different engineers with different feelings and different opinions.
And I think that's a really good thing.
If it were a super monoculture or something like that, that would probably be very unhealthy.
Taking a little bit of a turn.
So I started writing Swift almost exactly a year ago now.
And the project that I'm doing at work, we're using RX Swift and quote unquote reactive programming.
And I'm curious, have you looked into that at all?
And do you have any particular thoughts on it?
Does it seem barbaric to you?
Does it seem clever?
Does it just seem like an odd choice?
What is your take on this whole RX thing?
Yeah, so I've definitely seen it.
I have no real world usage experience.
Sure, sure.
Most of my opinion is based on reading blogs and reading people talking about how awesome it is while not talking about the problems.
From what I gather, it seems like it is a way of letting you write a lot less code.
and code that often works better the first time.
And I can see how that's super appealing.
It also seems like it'd be really challenging to debug it and maintain it.
And so I don't know between the two, between the pros and cons, how it balances out.
Um, um, if I were writing a lot of high level apps, I would probably try it out on an app or two and see if I liked it.
But, um,
But aside from that, I don't really have a good insight either way if it's the right thing to do or not.
Sure.
Sure.
Absolutely.
You mentioned a second ago that you see some problems and you mentioned debugging.
Is there anything else that jumps out at you as being a big concern or is it just that it's so different?
I mean, I'm not afraid of different things.
I think that it's more of... I mean, the questions I'd raise, and this is out of ignorance, not out of fear, but what is the community doing?
Is there a support line?
Is the...
Is it changing and evolving in a way that is good or bad?
And these are just things I don't know because I haven't used it.
But I have nothing against the Rx community at all, and I've seen a lot of really cool things they've done, and I've read many of the positive posts in Rx and React Native and many of the other things where people are using reactive techniques.
And Reactive Cocoa has also been around for quite a while, and I think that's a really interesting application that maybe became a lot easier when Swift came out than doing an Objective-C.
Yeah, absolutely.
So I think that it's great that Swift can support different kinds of programming models like that because if a awesome new right answer to some problem comes out, you'd hope that your system can support it and can make it really elegant and beautiful.
Yeah.
I feel kind of like this is fighting the last war instead of the current war, but you mentioned Garbage Collection versus Ark a bunch of times, and obviously that ship has sailed, but I would love for you to give a reasonable summary of...
what the trade-offs were there because objective c had garbage collection as you mentioned um sort of yeah well you know it was there um and eventually objective c dropped the garbage collection and got arc and of course swift doesn't have garbage collection at all can you talk about the trade-offs there and why swift is the way it is
Would you like a comparison of Arc against the garbage collector Objective-C had or garbage collection in theory?
You could pick garbage collection in a language perhaps not as burdened as Objective-C with C backwards compatibility.
But that's worth mentioning as well, I think.
So Objective-C had a system based on Lobato.
Lobato had a bunch of implementation concerns and other things that I think don't reflect...
That don't obviously reflect onto the ultimate garbage collector that you'd ever want to have.
And so I don't think the comparing against that is interesting.
But let me turn around.
So why do you think garbage collection is interesting?
What is compelling about garbage collection beyond ARC?
Well, the idea that memory management is completely out of the hands of the programmer and that some magical fairy behind the scenes will make it all good for you.
And, you know, obviously what you're giving up is what you mentioned before that, you know, even with Arc, you lack some amount of control that you'll need to have a language that becomes a system programming language.
Obviously, you give that up with a garbage collection because you're not going to be doing anything.
A systems program language with a garbage collector behind it, although I think Microsoft has some projects to do that, that singularity project where they were trying to build a whole OS off of garbage collection.
I'm not quite sure how that's going.
Right, but even if you ignore the systems programming side of things, because I think it's fair to say a lot of people don't care about that.
So garbage collection is proven in the application space.
for java for example right um and pearl but do do reference counting come on uh oh that's right it's python that uses reference counting plus cycle collector um so but let me ask you again so you said it means you don't have to think about memory is that true
Well, that's the pitch.
The pitch is that the programmer doesn't have to think about it.
They have to think about it when the garbage collector... I understand the pitch, but is it true?
When the garbage collector starts doing things you don't want, then all of a sudden you do have to think about it, but then there's almost nothing you can do about it.
So here's the way I look at it.
And as you said, the ship has somewhat sailed.
I am totally convinced the arc is the right way to go up front.
It is better in a whole bunch of different ways.
It gives you deterministic behavior.
So you don't get, you know, it doesn't have the unpredictable stutter problem that people like to bash on GCs.
The stutter problem to me isn't,
Really the issue, even though that's what GC haters will bring up all the time, it's more about being able to reason about when the memory goes away.
And the most important aspect of that is that Arc gets rid of finalizers.
So if you use a garbage collected language, you use finalizers.
Finalizers are the thing that gets run when your object gets destroyed.
Finalizers have so many problems that our entire...
there's entire bodies of work talking about how to work around problems with finalizers.
For example, the finalizer gets around on the wrong thread.
It has to get run multiple times.
The object can get resurrected while the finalizer is running.
It happens non-deterministically later.
You can't count on it, and so you can't use it for resource management for database handles and things like that, for example.
There are so many problems with finalizers that Arc just defines a way by having deterministic destruction.
Beyond that,
ARC... Another common thing... There are two arguments that people make against ARC in favor of a trace and garbage collector.
One of which is that ARC adds overhead because you have retainer release operations that run.
And that is true.
The other is that you have to...
Think about cycles in Arc because it doesn't automatically collect cycles.
And that is also true.
And the rebuttal I'd give to people is that those problems are also true in garbage collection, just in different ways.
So in a garbage collector, for example, people don't think about it, but garbage collection injects additional code into your application just like Arc does.
And so there are many different garbage collection algorithms.
Not all of them are the same.
But the most modern garbage collectors that use a nursery for short lifetime objects and then promote them out,
that are generational, use something called a write barrier.
And a write barrier is every time you store to a property of an object, say, you have to run additional code.
Garbage collectors also need the ability to stop all the threads, or at least to be able to stop threads at some point in time.
And they need to be able to do so within a specific time bound because they don't want the garbage collector to take forever.
The artifact of that is that
Typical garbage collectors in Java, for example, will introduce what's called a safe point into loops.
And so now in your loops, extra code is being run because of the garbage collector.
And on more aggressive garbage collection algorithms, for example, I was reading a blog post recently about Go's tricolor algorithm.
They're touting the advantage of you get really low latency and you get the ability to
guarantee response times in a more fine-grained level than most garbage collectors.
But to do that, they use this tricolor algorithm, which dramatically lowers throughput.
And it dramatically lowers throughput because they're doing almost exactly the same kinds of operations that ARC is doing.
The problem that it then introduces, though, is that these operations that the garbage collector is introducing are sometimes but not nearly as well optimizable as the ARC overhead that the ARC optimizer applies to.
And furthermore, there's no kind of out on it.
So with ARC, I think and hope that the ownership model will give people the ability to take control of those operations.
And if it becomes a problem in practice, or if they're just that kind of person, they can take full control over the lifetime of their objects and then know the arc will never happen.
In the garbage collector, you don't have that.
So the performance side of things, I think, is still...
up in the air because Arc certainly does introduce overhead.
Some of that's unavoidable, at least without lots of annotations in your code.
But also I think that Arc is not done yet.
A ton of energy has been poured into research for garbage collection, particularly since Java has come up.
There have been hundreds of papers written in the academic circles, tons of work in Hotspot and other Java implementations to do
different tweaks and different tunings and different new kinds of algorithms and garbage collection.
And that work really hasn't been done for Arc yet.
And so I think that there's still a big future ahead.
On the programming side of things, the cycle side of things, I think it's also a really interesting question of how much should people think about memory?
When I was baiting you a little bit, you said that the great thing about garbage collection is that you don't have to think about memory.
But of course, we know that's not true, right?
Because if you have a reference to some big object graph that you didn't mean to keep around, maybe it's in your undo stack, then you will, quote unquote, leak that memory, right?
And that's true of a garbage collector.
That's true of ARC as well.
It's just any automatic memory management approach has that problem.
Um, and so that, that is a really interesting thing that there's this question of, if you're building a large scale system, do you want people to quote unquote, never think about memory?
Do you want them to think about memory all the time?
Like they did in objective C classic retain and release manual, retain and release.
Um,
or do you want something in the middle?
And I think the arc strikes a really interesting balance, either whether it's in Objective-C or in Swift, where I look at manual retainer release as being a very imperative style of memory management, or malloc and free, all these things, where you're telling the code line by line, this is where you should do a reference count operation, this is where you should release the memory, and
This is what you should do at this point in time.
Arc then takes that model and bubbles it up a big step, and it makes it be a very declarative model.
So instead of telling the compiler that this is the place you should do a retain, you instead say, this is an owning relationship.
And the cool thing about that to me is that not only does that get rid of the mechanics of maintaining reference counting and define away tons of bugs by doing that, it also means that it is now explicit in your code what your intention was.
And that's something that people who maintain your code benefit from.
And so by saying that I have a weak pointer to the parent object of my thing, that's a really important relationship to know about.
And as you're looking at the code, you're maintaining the code.
Having that be explicit is very valuable.
Because that talks about the relationship between values.
And to me, again, with the goal of being able to write large-scale applications in Swift, I think that's really useful.
I also don't think it's hugely burdensome, though it is definitely part of the learning curve of learning how Swift works that has to be balanced in there as well.
And so, I don't know.
I mean, I look at it as their Arc has clear advantages in terms of allowing Swift to scale down to systems that can't tolerate having a garbage collector.
For example, if you want to write firmware in Swift.
I think it does provide a better programming model where programmers think just a little bit about memory.
And I think that, you know, going forward, it provides a really high performance model that you can get better than garbage collection in almost every way.
So I think that in terms of trade-offs, it's the right one to push forward.
The other, I guess, third piece that garbage collection is really bad about is
kind of a showstopper for Swift, which is interoperability with C code.
So if you've ever worked with Java or with other similar garbage collected languages, one of the major advantages the garbage collectors give you is that they move objects and they need to do that so they can compact those objects so that they can then efficiently do allocations.
But the problem is that once you start moving objects around, if you're interfacing with C code, you can't have some random C code having a pointer to your object and have it move because then you get a dangling pointer.
And so once you get down that line, you end up with things like JNI, the Java native interface, where you have to...
explicitly pin things you have to maintain them it's very complicated it's really buggy and arc completely defines this away by um just saying that okay something's in memory it's it has predictable lifetime you can reason about it it
Swift provides tools for dealing with unsafe pointers and things like that.
And that makes the interoperability with existing C code, but also with Objective-C and maybe someday C++ code, really simple, really natural, and really efficient.
And I think that's a huge advantage that Arc provides that really would be impossible to do with a garbage collector.
So that's my opinion.
I mean, I think reasonable people disagree, obviously, but it's something that does come up now and then.
Or it used to come up anyway.
I'm convinced.
I think you should use ARC for Swift.
Get on that.
Yeah, there we go.
Chris, thank you so very, very, very much for coming on the show.
Obviously, we are not an interview show, as the listeners have discovered over the last hour or two.
But to take your time on what is presumably a very busy time of your life and spend it with us three knuckleheads.
I really appreciate it.
And it was very kind of you to do.
And hopefully this won't be the last time that we'll hear you on a show or maybe even this show.
We'll see.
So thank you, Chris.
I really appreciate it.
Yeah, well, thank you for having me.
I've had fun, even though I'm terrified and probably made a fool out of myself.
Not at all.
Trust me, that's normal.
I'm still trying to get over that.
Plus, that's our job.
All right.
Thanks a lot to our three sponsors this week, Eero, Squarespace, and Audible.
And we will see you next week.
Now the show is over They didn't even mean to begin Cause it was accidental Oh, it was accidental John didn't do any research Marco and Casey wouldn't let him Cause it was accidental Oh, it was accidental And you can find the show notes at atp.fm
And if you're into Twitter, you can follow them at C-A-S-E-Y-L-I-S-S.
So that's Casey Liss, M-A-R-C-O-A-R-M-N-T, Marco Arment, S-I-R-A-C, USA Syracuse.
It's accidental.
Accidental.
They didn't mean to.
Accidental.
Accidental.
We didn't talk about woodworking stuff.
Yeah, making splinters is fun.
What kind of wood was that table made out of?
It's walnut.
That's got to be tough.
That's a lot of cutting.
That's pretty hard wood, right?
Yeah, I mean, it takes time, but it's fun.
It's one of these areas where you can learn a lot about it over time and keep going deeper and deeper in different spaces, and you never know everything.
So it's a lot of fun to dive into woodworking.
It's also very different than sitting in front of a computer all day.
You actually get to make something with your hands, and you get to build.
Much higher chance for dismemberment.
that that is true that is true so like i think it's interesting when programmers have like incredibly analog hobbies it's also hilarious because the woodworking community is going through this whole cnc thing they're turning it into a very programmed thing and people always say well why don't you get into cnc and do blah blah blah i'm like
But that's exactly what I'm escaping.
I don't want to have to program my.
I love it.
You can't even escape like the community arguments over standards.
So you just cut down a tree and you throw it into your workshop and then out comes the table.
Yeah.
Well, so that's the funny thing about people is that people are all the same.
They just don't want to notice and agree to that.
Oh, my goodness.
You know, you get to very different communities and they think they're all different, but they're actually the same at root.
So Chris, you're obviously changing careers.
Well, not careers necessarily, but changing employers.
Would you consider yourself a car person?
Well, so that's a funny question.
I mean, I obviously need a car.
Cars are really important.
But I'm what I consider to be an un-car person.
I want to accelerate the path to cars being appliances that solve people's problems.
And I'm personally not the kind of guy who loves doing oil changes and
fiddling around with them I just want something that is reliable that works ideally drives me to where I want to go and I don't have to think about it it's just you know solving my problems it's not something I have to care for feed and maintain so that's kind of the way I look at cars can you drive a stick I did drive a stick before I got my Tesla a few years ago so yeah
It all comes clear now.
I mean, really, from the point of view, it kind of sounds like you want to make cars boring in a good way, really.
And that's a notable goal.
And I think I can see why you went to Tesla.
However, it is kind of funny that Tesla is, in my opinion, clearly the most exciting car company that the world has known for quite some time.
And so to go there while having such an almost nonchalant opinion about cars is interesting to me.
Yeah, well, I admit that I never considered going to work at a car company before.
But that's because I always considered car companies to be, you know, not in need of the kinds of skills that I bring.
But autopilot, I think, is a really exciting and really big problem.
And it kind of fits with my desire to solve nearly impossible problems and take on new things.
And so I'm really excited about it.
so i'm a little curious on that note we've talked on this show before about you know whether we think that that full self-driving cars you know basically when and whether we think those will exist like in what kind of time frame are we talking a decade our lifetimes ever because you know it's one thing to make something that can work on clearly marked highways it's another thing that can make something work where john lives where there's where there's ice all over the roads for most of the year and so like
There's no more lane markings.
There's barely any flat road surfaces.
Or you have all these different ambiguities that you have in real world roads.
Do you think, you know, again, obviously, this is not any kind of official capacity as an about-to-be Tesla employee.
Do you think, big picture, that we will see completely self-driving cars capable of driving on effectively all roads within, say, the next decade?
And if not, maybe within our lifetimes?
Uh, yeah, I, I think that it's very possible within the next decade and hopefully that's a long, a long, a long view, but keep in mind, the goal is to drive better than a human and significantly better than a human.
And, um, I think one of the things that gives me confidence in this, um, is that it's not an even playing field because the autonomous cars have more sensors than humans do.
They have a radar, for example, and that means that they're capable of doing things that humans just physically can't.
And there's a huge technology problem.
There's huge software problems.
This is not an overnight kind of a thing that you wake up and solve immediately.
But I have confidence it could be solved, certainly within a decade.
Well, the good news is it's not going to take a lot to be better than your average driver from Massachusetts because that's a pretty low bar.
No, because they know how to navigate these intersections that have like seven different exits, all at different angles, some of which are one way, none of which are marked.
So the humans can figure that out.
It's going to be tough for the sensors.
Tell you one thing, I will drive in Manhattan without any problems.
I would never drive in Boston.
Oh, amen, brother.
I completely agree.
All right, so to bring this back around, Chris, you made mention way early in the episode that you like yellow cars.
What?
Yeah, yeah.
One of my favorite cars was a yellow Mini Cooper with black hood stripes on it.
Nice.
And a Mini Cooper convertible.
It was totally awesome.
It doesn't get you in the carpool lane, but it was a beautiful car.
In his defense, like yellow, like I've seen that kind of category of color, like yellow, orange, maybe teal, or even like a pink, like the kind of like bright, almost neonish colors can work really well.
They often don't.
But when they work well, they look pretty good.
I could totally see that.
The only flaw I see in this plan is that Tesla does not currently offer either yellow paint as an option or custom paint colors as an option.
Well, so now you've broken into the real secret they want to hire a compiler guy.
That's why.
Would you have gotten your Tesla in yellow if you could have?
Yes, absolutely.
It would look like a giant banana.
What are you doing?
yeah i haven't really fully thought this through john i don't i don't know if you could that car can pull we're talking about a model s right yeah yeah yeah no i would yellow doesn't seem right for that we can do some photoshop mock-ups let's workshop it a little bit we'll see maybe if you got black stripes down the middle yeah i admit this is a case where details matter so yeah
No, I mean, if there's any way for you to get a PET feature implemented in the model line, that seems like a pretty good one to do.
At least, I would ask, I'm sure, I know you're probably not going to be working on the Bluetooth UI, but I'm sure you could probably put in a word with the right people to please improve Bluetooth audio.
but otherwise uh if you can make a yellow one i think that would be you know in addition to you know potentially saving thousands of lives a year uh with autopilot software you know getting getting improved bluetooth and a yellow option would be pretty impressive well yellow would make your car more visible to other drivers other human drivers who need bright colors to know that you're there since you don't have any engine sound
And I have to say, this is the most effort I've ever done to win over one Swift programmer.
So I'm not sure if this is a scalable approach.
Yeah, this is a bad strategy for Swift adoption.
You should seek other means instead of coming on everybody's podcast and talking to them individually.
Oh my God, that's amazing.