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