205: People Don't Use the Weird Parts


00:00:00   So, let's start with some follow-up. Why did Chris Latner decide to leave Apple?

00:00:05   Well, last week we talked about this, and we tried to list all the reasons we could

00:00:09   think of why he might be leaving. And I think we covered most of the major threads of speculation,

00:00:15   and we didn't really get a lot of listener feedback about it. Anybody who did reply was

00:00:17   mostly voting for one of the things we talked about.

00:00:19   But here's the thing on this topic. Unless there's some kind of, like, secret doomsday

00:00:25   thing about Apple that only Chris knows, it's not actually that important that we figure

00:00:29   out why he left Apple or what was in his heart of hearts, aside from just us being busybodies

00:00:34   and just wanting to know gossip type stuff. And second, pragmatically speaking, this is

00:00:40   just not the type of thing that people who leave Apple talk about. Or if they do talk

00:00:44   about it, it's like years and years later after no one cares anymore, or it's not a

00:00:48   big deal. So even if there was some deep, dark reason, it's not like we would know about

00:00:53   it until years from now. And honestly, the straightforward, boring explanation is probably

00:00:57   the right one anyway. So, you know, I don't know. What do you think, Chris?

00:01:00   That sounds about right to me, Jon.

00:01:04   Would you ever buy an electric car in white?

00:01:08   You are such a jerk. Why are you so mean to me, Marco?

00:01:13   No, no, no. I'm a fan of red cars.

00:01:15   There you go.

00:01:16   Yellow if I could get them.

00:01:17   Yellow? That's bold. My goodness. All right. We obviously need to talk about what's happening

00:01:23   right now. So ATP is not an interview show, but in extraordinary circumstances, weird

00:01:30   things can happen. And so in today's episode, we have an extraordinary circumstance. Former

00:01:36   Apple employee Chris Ladner was nice enough to join us on the show. And so this is going

00:01:42   to be three people interviewing one person, which is, to say the least, a bit peculiar.

00:01:46   And it's something that we've never really done before. So this could be a little bit

00:01:50   of a rough ride, but we're going to try to make our best of it. And I'll just say right

00:01:55   up front, thank you so much, Chris, for coming on the show, and we definitely appreciate

00:01:59   it. To kind of kick all this off, would you mind giving us like a nickel tour of who is

00:02:03   Chris Ladner?

00:02:04   Chris Ladner Okay. Well, I can try. I'm a programmer. I

00:02:09   love coding. I have for a long time. I'm most widely known for starting LLVM and getting

00:02:16   it off the ground and handing it off to other smarter people.

00:02:20   I started Clang, which is a C, C++ Objective-C compiler, and likewise got it to the point

00:02:25   where it was thriving and then let other smarter people run it, and then started Swift and

00:02:31   got Swift going.

00:02:33   And it recently got past 3.0, and it has an amazing community, and it has a great team

00:02:38   of people running it, and now I'm ready to jump to the next thing.

00:02:42   And so I guess the short version of what I'd like to do

00:02:46   is tackle really hard problems and do things

00:02:49   that most people think are impossible.

00:02:52   So we're going to go back in time a little bit.

00:02:54   And I hope that you could tell us

00:02:57   how you ended up coming to Apple.

00:02:59   Like, if you can remember back that far,

00:03:02   LLVM you started before you were at Apple.

00:03:04   So how did you end up at Apple?

00:03:06   Yeah, that's a great question.

00:03:07   So I started working at LLVM at the University of Illinois.

00:03:10   It was a research project, and it really was hoped for and designed to be fully general

00:03:20   and production quality and all those great things that you'd want as a graduate student

00:03:25   for people to use your code, but it also wasn't.

00:03:28   It had a lot of the great architectural ideas, maybe, but it wasn't fully baked.

00:03:33   It wouldn't solve all the world's problems.

00:03:39   By the time I got to graduate, the question was,

00:03:42   what do I do next?

00:03:43   And of course, my dream was to continue pushing it forward

00:03:46   and build it out to be something real.

00:03:47   And to do that, I would have to go to a place

00:03:50   that would allow me to work on it.

00:03:51   And I was really fortunate to have built some relationships

00:03:54   with folks at Apple, and they took a chance on me.

00:03:56   And I jumped to Apple and started building out LVM

00:03:59   as my job.

00:04:01   It was totally a dream of mine.

00:04:03   So that's how I got to Apple.

00:04:04   - Did you graduate?

00:04:05   Did you get your degree and then go to Apple?

00:04:06   - Yeah, yeah.

00:04:08   - Well, that was nice.

00:04:09   Otherwise, how do you ever get a job?

00:04:11   Yeah, you can't get a job with that degree.

00:04:12   We all know that.

00:04:12   No.

00:04:13   Yeah, clearly.

00:04:14   So how would you explain LLVM to somebody who doesn't

00:04:18   know stuff about compilers?

00:04:19   Because we all just rattle off LLVM compiler building toolkit

00:04:23   or whatever.

00:04:23   But how would you explain that to someone-- because not

00:04:26   all of our listeners are programmers-- who

00:04:28   isn't intimately familiar with how a compiler works.

00:04:30   Sure.

00:04:31   So first, we start with what is a compiler.

00:04:34   A compiler is the thing that takes the code that a programmer

00:04:37   and turns it into something the machine can understand.

00:04:41   And so there's lots of different kinds of computers

00:04:43   with lots of different kinds of processors.

00:04:46   Most programmers don't want to have to think about that

00:04:48   or know about that, and they want to program and think

00:04:51   at a much higher level than what the actual processor can do.

00:04:55   And so the compiler's job is to transform

00:04:57   what the human wrote to something

00:05:00   the machine can understand.

00:05:02   Then LVM is a modular system for building

00:05:06   different kinds of compilers because there's lots of different reasons why people would

00:05:10   want to use compiler technology.

00:05:12   And I think LLVM was most successful over the years because it was built as reusable

00:05:16   components kind of like a framework, and then the framework can be used to solve lots of

00:05:22   different problems.

00:05:23   And one of the fun things about LLVM is that it was eventually over the years used to solve

00:05:28   problems that we had never even imagined, which is really exciting.

00:05:32   One example of the type of problem is, I remember from past WWDCs, the idea that the Xcode IDE,

00:05:39   the GUI that programmers use to make their applications, that very often in that GUI

00:05:45   you need to do things that have an understanding of the code.

00:05:48   But when the compiler is this big monolithic thing, the best you can kind of do is compile

00:05:52   everything in the background and spit out some stuff.

00:05:54   But when it's a modular toolkit, you can take those pieces and just use the part that understands

00:05:59   like the syntax tree or whatever and integrate them.

00:06:02   Was that the first use of LLVM as something other than a straight-up compiler that you

00:06:09   just point to your code and produces output?

00:06:12   In other words, integrating it into applications, or was there some use before that?

00:06:16   Well, I think the first use in production was in the OpenGL stack, which ended up shipping

00:06:22   in a late software update for Tiger, as well as in Leopard, which is 10.4 and 10.5.

00:06:31   There it was used in a completely invisible way to basically repack data and upload it

00:06:37   to the GPU.

00:06:38   And so when you're making OpenGL calls to say GL vertex 3F or whatever the low-level

00:06:46   GL call is, those vertices need to be transformed into a very specific data format that the

00:06:52   can understand. And you have a whole bunch of different kinds of calls that can be used

00:06:55   to produce vertex or other geometry data. But you also have a matrix of different kinds

00:07:01   of GPUs you need to support, and they all have different formats and different capabilities

00:07:05   and requirements. And so LVM was used to generate very small chunks of code to do that, and

00:07:10   it was part of the 64-bit bring-up and the leopard timeframe. And so that was probably

00:07:15   the first completely invisible use of it that used and proved a lot of the kind of code

00:07:21   generation technologies. So forgive me one more LLVM related things we're going to go from what

00:07:26   is a compiler all the way down to nitty-gritty stuff here. My vague recollection of what you

00:07:31   just described, the whole video driver thing, was that there were files on disk in the shipping OS

00:07:37   that were basically LLVM bytecode, like these little bc files, and they would get slurped up

00:07:43   and converted to machine code appropriate for the GPU and then is that am I right about that? Yeah,

00:07:49   Yeah, you're absolutely right. And so basically the way to look at it is the bitcode files,

00:07:54   the LLVM that shipped with the OS were little snippets of code that then at runtime were

00:08:00   recombined and optimized across. And so that was kind of the library of primitives that

00:08:05   the OpenGL runtime used to assemble what it was trying to do.

00:08:09   **Matt Stauffer:** All right. So my question about this, and maybe you kind of alluded to it with

00:08:12   either a slip of the tongue or a revealing understanding is, what is the difference

00:08:16   between LLVM bytecode and what Apple currently brands as bitcode?

00:08:20   Oh, well, are you asking for a historical question? Is this a historical question?

00:08:24   It's a technical and historical, because I'm confused by the branding and I'm also confused

00:08:29   by the tech. So LLVM prior to LLVM 2.0, and these version numbers are the open source version

00:08:37   numbers not related to the Apple version numbers, and they're confusingly different for not very

00:08:41   very interesting reasons.

00:08:43   But before 2.0, it used a really horrible encoding

00:08:47   in binary that was branded bytecode

00:08:50   because that's what Java used.

00:08:52   It had a whole bunch of problems in that it wasn't extensible.

00:08:55   It was fragile.

00:08:58   LLVM was changing.

00:08:59   It didn't have compatibility.

00:09:01   And so in the LLVM 2.0 time frame, which, gosh,

00:09:06   is probably, I don't know, 10 years ago or more--

00:09:10   It's been a long time ago now.

00:09:14   I redesigned the whole thing, and it now

00:09:16   uses this quote unquote "bitcode" format.

00:09:18   And used bitcode as a term for two reasons, one of which

00:09:21   was it was different than bytecode,

00:09:23   and so the two could live side by side in the directory tree

00:09:26   for a while.

00:09:26   And the second reason is that the encoding

00:09:29   is a bitstream format instead of a bytestream.

00:09:31   But that's the origin of the term bitcode.

00:09:35   You can find documentation on this file format.

00:09:37   It's actually a very general encoding format

00:09:40   that you can use for XML type purposes.

00:09:43   It's a self-describing file format.

00:09:45   And multiple different things can be encoded in bitcode.

00:09:48   Yeah, there was definitely some confusion about that.

00:09:50   Because when Apple presented it, when

00:09:52   they presented it as the requirement was like the watch

00:09:54   apps have to be in bitcode, Marco, you would know this.

00:09:56   Watch is required.

00:09:58   iOS is still optional.

00:09:59   Yep, and then TV is required.

00:10:01   And they would have you put your stuff in bitcode.

00:10:04   And there was a lot of speculation

00:10:06   early on about what that meant, like in terms of,

00:10:10   does that mean that what you're uploading

00:10:12   is not a finished binary and therefore it's like

00:10:15   this machine agnostics can be targeted at any CPU

00:10:18   and the more prosaic version, like it doesn't mean

00:10:22   it's CPU agnostic, all it means is that Apple

00:10:24   has slightly more freedom to like change instructions

00:10:27   on the CPUs they do target.

00:10:30   How would you characterize the, what advantage are there

00:10:34   of compiling something to bit code

00:10:37   and then uploading it somewhere versus sending someone

00:10:39   a binary?

00:10:40   Sure.

00:10:41   There's a couple of different advantages for that,

00:10:43   one of which is that the compiler keeps getting better.

00:10:46   And so if the compiler learns a new optimization,

00:10:48   it can be applied to existing applications

00:10:51   without app developers having to re-upload their app.

00:10:54   So that's one small thing.

00:10:56   Other things are that Apple does periodically

00:10:59   add new instructions to its CPUs.

00:11:01   One example of this historically was

00:11:04   the hilariously named Swift chip that it launched,

00:11:09   which was the first designed in-house 32-bit ARM chip.

00:11:14   This was the iPhone 5, if I recall.

00:11:17   That's right.

00:11:19   So in this chip, they added an integer divide instruction.

00:11:22   And all the chips before that didn't have the ability

00:11:24   to do an integer divide in hardware.

00:11:26   You had to actually open code it,

00:11:27   and there was a library function to do that.

00:11:29   And so that and a few other instructions they added

00:11:33   were a pretty big deal and used pervasively.

00:11:36   And the only way to tackle that and handle that and use it

00:11:39   effectively was to introduce an entire new slice.

00:11:42   And so if you're an app developer back then,

00:11:44   you had the V7 slice, which was all the older ships,

00:11:48   and then you had a V7s slice, s for Swift,

00:11:51   which was the slice that included the integer divide.

00:11:56   Now, this is a pain for app developers.

00:11:58   It's a pain for Apple.

00:11:59   Everybody has to convince all the developers

00:12:01   to take it seriously.

00:12:02   and if app developers don't support it,

00:12:04   then the new hardware doesn't benefit from it.

00:12:06   And so Bitcode allows that kind of thing

00:12:09   to go completely away.

00:12:10   So with Bitcode, Apple can just recompile the applications

00:12:13   in the store and say, "Ha ha, this device has

00:12:17   an integer divide instruction."

00:12:18   And it works perfectly with the thinning kind

00:12:20   of architecture they have for deploying resources

00:12:23   to specific device types.

00:12:25   And it all kind of plugs together.

00:12:27   Bitcode is not a magic solution though.

00:12:32   You can't take a 32-bit app, for example,

00:12:34   and run it on a 64-bit device.

00:12:36   That kind of portability isn't something

00:12:38   that bitcode can give you, notably

00:12:40   because that is something that's visible in C.

00:12:43   And so as you're writing C code, you

00:12:45   can write if def pointer size equals 32.

00:12:49   And that's something that bitcode can't abstract over.

00:12:51   And so it's useful for very specific low-level kinds

00:12:56   of enhancements, but it isn't a panacea that makes everything

00:13:00   magically portable.

00:13:01   the same thing I would assume for architecture changes,

00:13:04   especially if there was an endian difference,

00:13:05   'cause endianness is visible from the C world,

00:13:07   so you can't target different endianness.

00:13:09   - Yep, yeah.

00:13:10   So it's not something that magically solves

00:13:12   all portability problems, but it is very useful

00:13:14   for specific problems that Apple's faced in the past.

00:13:17   - And going back to the Slice thing,

00:13:19   that's like terminology, like the Mako format,

00:13:21   where you get to put different architectures

00:13:23   worth of executables, or is that a different?

00:13:25   - Yeah, I think that's technology

00:13:26   that goes all the way back to Next,

00:13:28   when Next supported really heterogeneous

00:13:30   different architectures like PA-RISC and Spark and PowerPC and Intel, all back in the next

00:13:37   days.

00:13:38   It allows you to compile your application with multiple slices, they call them.

00:13:44   And then there's a tool called LiPo, which sticks them together.

00:13:48   At runtime, the OS picks the slice that best matches your CPU in practice.

00:13:53   And so an app developer can support many different kinds of architectures, and then the OS just

00:13:58   does the right thing.

00:13:59   So in today's world, it's very common to build an iOS

00:14:03   app, for example, for both ARM 64 and ARM 32.

00:14:07   And the way that works in the simplest case

00:14:11   is it's just two different binaries

00:14:13   that are stuck together, and then the OS

00:14:15   picks the right one to run.

00:14:17   All right.

00:14:17   I could go on for this forever, but I

00:14:19   don't want to get too far down with this rat hole.

00:14:21   It's just there's some pent up questions about bitcode

00:14:24   and bytecode, but now I feel satisfied

00:14:26   that we can move on to broader topics.

00:14:28   (upbeat music)

00:14:30   We're sponsored tonight by Squarespace.

00:14:32   Go to squarespace.com and use code ATP

00:14:34   to get 10% off your first purchase.

00:14:37   It's the new year.

00:14:38   You might have a new project,

00:14:39   you might have a new goal you wanna reach,

00:14:41   and that might involve making a website.

00:14:43   Make your next move with a beautiful website

00:14:46   from Squarespace.

00:14:47   Squarespace sites are so incredibly easy to make

00:14:50   and they're incredibly beautiful

00:14:52   and the tools are very powerful.

00:14:54   This is a great combination

00:14:55   that I personally have never seen before

00:14:58   in the web building space until Squarespace.

00:15:00   The amount of power you get with these tools

00:15:02   is just incredible.

00:15:03   You can make so many different kinds of sites

00:15:05   with so little effort, nothing else comes close.

00:15:09   Your sites look professionally designed

00:15:11   regardless of your skill level with no coding required,

00:15:14   although if you wanna jump in and alter some of the code,

00:15:16   you actually can.

00:15:17   But you don't have to and it probably isn't a good use

00:15:19   of your time because Squarespace is such a great platform

00:15:23   right out of the box.

00:15:24   whether you're making a website for you

00:15:26   or for somebody else.

00:15:28   If you make it for somebody else,

00:15:29   Squarespace is the place you wanna do that

00:15:31   because you show them how to use Squarespace

00:15:33   and then you're done.

00:15:35   They're not coming to you anymore.

00:15:36   Squarespace will support it if they need help

00:15:38   and they'll be able to figure things out on their own

00:15:39   because it's just so much easier to use

00:15:41   than whatever CMS you were gonna install on their server.

00:15:43   So check it out today.

00:15:44   Go to squarespace.com, use code ATP

00:15:47   to get 10% off your first purchase

00:15:49   when you decide to sign up.

00:15:51   Whether you're making a site for you or somebody else,

00:15:53   Make your next move with Squarespace.

00:15:56   - So Chris, how was your transition from coding

00:16:02   to being a manager?

00:16:03   Because from an outsider's point of view,

00:16:05   it looked like, you know, you had arrived at Apple,

00:16:07   you were working heavily on LLVM,

00:16:09   like you had said earlier, but over time,

00:16:11   I mean, even just looking at the resume on your website,

00:16:13   it seems pretty clear that you were doing

00:16:15   a lot more managing lately than perhaps coding,

00:16:19   or maybe you just worked around the clock,

00:16:20   that wouldn't surprise me either,

00:16:21   But how did you feel about your transition

00:16:25   from being just a code monkey to being a manager?

00:16:29   And I ask in part because at my phase of my career,

00:16:31   I am still a code monkey, but I think it's not too far away

00:16:34   that I might become a manager.

00:16:36   And so I'm curious to hear, you know,

00:16:38   from one code monkey to another,

00:16:40   how did that transition go and what did you learn from it?

00:16:43   - Yeah, that's kind of interesting.

00:16:44   So I don't think it is a hard transition.

00:16:48   I'm still writing code.

00:16:49   I still love writing code.

00:16:50   That's something that I think is a key part of my identity.

00:16:54   But on the other hand, it is very strange.

00:16:58   So I started managing people at Apple really pretty early on,

00:17:03   maybe a year or so after I joined,

00:17:05   I started managing two or three people

00:17:08   because I was kind of the best person

00:17:10   to manage the nascent LLVM effort at the time.

00:17:14   And initially it was mostly just being a tech lead.

00:17:20   And so if you've ever driven a project where you have coworkers that don't report to you,

00:17:26   but you're kind of guiding them and helping make technical decisions, that's where it

00:17:31   started.

00:17:32   Over time, my team grew and eventually ended up picking up and running kind of a second-level

00:17:38   manager role where you're managing other managers, and each step along the way it introduces

00:17:44   new challenges.

00:17:45   And along the way, I told myself that managing is something that I had to do because I was

00:17:53   the best qualified to do it and I didn't want anybody else to.

00:17:56   And that coding was my real joy and passion.

00:17:59   And I think that coding really is my joy and passion.

00:18:02   But along the way, looking back, I've realized that I am actually pretty good at managing.

00:18:07   And I really do like building teams.

00:18:09   I like working with people.

00:18:11   And I've never considered myself to be a people person, which is, you know, it's

00:18:15   just very, very odd for me to even think about that.

00:18:18   But I actually do understand how people work and can, you know, really care about getting

00:18:24   the most out of people and working with them to make them successful.

00:18:27   And so it's been kind of a transition over time, but I've always hung on to coding.

00:18:33   And even though I have a full-time management job, I code like crazy on nights and weekends.

00:18:38   I'm not the kind of guy that likes to sit around idle, and so I've always just been

00:18:44   busy.

00:18:45   So, I mean, you can get into as much of this history as you want to, Chris, but how did

00:18:49   you get Swift to happen inside Apple?

00:18:52   Because, from the outside, it's mysterious to us how big important projects come to be.

00:19:00   Like, you know, you name the headlining things that have come out of Apple.

00:19:03   We hear that Apple does a lot of things that don't see the light of day.

00:19:07   How did you get probably one of the biggest things ever to come out of Apple, an entirely

00:19:11   new language created in-house?

00:19:13   How did you get that to happen and not just be some little thing that was off to the side

00:19:17   that fizzled off and disappeared?

00:19:18   Sure.

00:19:19   Well, so I can tell you about Swift, but I don't think you should project this onto every

00:19:23   other project at Apple because I'm sure they're all different.

00:19:26   So I can just talk about my experiences.

00:19:29   So Swift started in 2010.

00:19:35   The timing is suspicious because it's right after a blogger wrote something about how

00:19:39   Apple needed a new programming language.

00:19:42   I'm not a blogger.

00:19:44   Oh, okay.

00:19:45   Ars Technica wasn't a thing.

00:19:47   That's not a blog.

00:19:48   That was a prestigious website.

00:19:50   It still is.

00:19:51   Okay, okay.

00:19:52   I stand corrected.

00:19:53   So I don't remember if I read it exactly then and that was a causal link to starting working

00:20:01   Swift or if it was just because I had just finished up Clang C++ support and we launched

00:20:07   Clang C++. And of course, if you write C++ code, you know how ugly and horrible it is.

00:20:13   But if you implement C++, it's a whole other level of challenge. And so getting that first

00:20:19   release out was a major accomplishment for the entire team. And it was a major,

00:20:24   major effort for a ton of people involved. And as is typical, you get something over the finish

00:20:30   line and of course it wasn't fully finished, it's a lot of long ways to go, but a lot of

00:20:33   the intellectually interesting, to me at least, pieces were done. That's when I started

00:20:39   thinking about, "Okay, well, what comes next?" And then implementing other people's stuff,

00:20:45   like for example, the C, the C++, the Objective-C standards and languages. But there were things

00:20:53   that we weren't happy with and things I wasn't happy with.

00:20:56   And so Swift started out as just a,

00:20:58   let's see what could be done, right?

00:21:01   Let's see what a much simpler language

00:21:03   that doesn't need a preprocessor,

00:21:05   doesn't need trigraphs,

00:21:06   doesn't need all the weird things

00:21:09   that have accumulated into C and C++ over the years.

00:21:12   Let's see what we can do

00:21:13   and just try to build something nicer.

00:21:16   Initially, it was really just me messing around

00:21:21   and nobody knew about it

00:21:23   because it wasn't anything to know about.

00:21:25   but eventually it got a little bit more serious

00:21:28   and said, hey, well, after playing around a little bit,

00:21:31   I think that this actually could make sense.

00:21:33   And so I started talking to my management,

00:21:36   started talking to some of the engineers

00:21:39   that were working on Clang,

00:21:40   and they seemed excited about it.

00:21:41   We got a couple people working on it part-time,

00:21:45   and I convinced my manager that it was interesting enough

00:21:47   that we could have a couple of people work on it.

00:21:52   Now, this wasn't a major commitment.

00:21:54   This was a, okay, well, let's see what there is here.

00:21:58   And that started a kind of internal demo schedule

00:22:01   and other things where we set milestones in place

00:22:04   and tried to justify the investment

00:22:07   that was being put into it.

00:22:08   Eventually got to the point where there was an,

00:22:12   it was far enough along that it was

00:22:14   posing strategic questions.

00:22:16   So the strategic questions were the form,

00:22:19   okay, we have Objective-C.

00:22:20   Objective-C is a great language.

00:22:22   it is probably directly responsible

00:22:26   for the iPhone being successful

00:22:29   because it's really high performance,

00:22:32   it allows you to get your job done,

00:22:34   it supports high-level frameworks in a beautiful way.

00:22:37   There's a ton of stuff to love about Objective-C.

00:22:39   And while there are a few things that are ugly about it,

00:22:41   some @ signs and semicolons and other stuff like that,

00:22:44   we can make Objective-C better.

00:22:46   And so the question was always,

00:22:49   why not just make Objective-C better?

00:22:51   Why don't we just keep evolving Objective-C,

00:22:54   and why do we wanna face potential disruption

00:22:56   in terms of moving the entire development community

00:22:59   to something new?

00:23:00   And we kicked that around for a long time.

00:23:02   We talked about both sides, and we came to realize

00:23:05   that yes, we can and should make Objective-C better,

00:23:08   and we continue to invest in Objective-C.

00:23:10   We did things like Arc, for example,

00:23:13   which is a major effort, but--

00:23:15   - We got DOTS.

00:23:17   - Oh, well, so DOTS syntax predated this.

00:23:19   - Aw.

00:23:20   - Yeah, dot syntax.

00:23:22   So the Objective-C 2 features and the block syntax

00:23:25   were all kind of prior to this.

00:23:26   I worked on blocks, but it wasn't in this timeframe.

00:23:31   And so we were talking about, okay, well,

00:23:34   can we just make Objective-C better

00:23:35   and can we feature creep it to the language that we want

00:23:37   for the fullness of time?

00:23:38   Because if we can, that'd be much less disruptive

00:23:40   to the community.

00:23:42   And we decided that, yeah, we can move Objective-C

00:23:45   a lot closer to what we want.

00:23:46   So we can get automatic memory management

00:23:48   with Arc, for example.

00:23:49   But we can't ever take away the problems

00:23:52   that lead to Objective-C being unsafe.

00:23:55   And the fundamental problem was Objective-C

00:23:57   was built on top of C.

00:23:58   And C inherently has pointers,

00:24:02   it has uninitialized variables, it has array overflows,

00:24:05   it has all these problems that even if you have full control

00:24:09   of your compiler and tool stack, you just can't fix.

00:24:12   To fix dangling pointers,

00:24:14   you would have to fix lifetime issues,

00:24:16   and C doesn't have a framework to reason about that.

00:24:19   and retrofitting that into a compatible way into the system

00:24:21   just wouldn't really work.

00:24:23   If you took away C from Objective-C,

00:24:25   you couldn't use C arrays on the stack, for example.

00:24:28   And if you couldn't do that,

00:24:30   there's entire classes of applications

00:24:32   where the performance just wouldn't be acceptable.

00:24:35   And so we went around and around and around,

00:24:37   and we said, okay, the only way that this can make sense

00:24:42   in terms of the cost of the destruction to the community

00:24:45   is if we make it a safe programming language,

00:24:47   which means not safe as in you can have no bugs,

00:24:50   but safe in terms of memory safety,

00:24:53   while also providing high performance

00:24:55   and moving the programming model forward.

00:24:58   And so that was really kind of the ideas

00:25:00   that came together to make Swift being worth the investment

00:25:05   and being worth being disruptive to the community.

00:25:09   So a lot of these kinds of pitches and ideas

00:25:11   were being held in very small, small meetings.

00:25:16   small meetings, and coming out of WWDC 2013 is when we in the executive team decided,

00:25:24   "Okay, let's really commit to this." And that's coming out of WWDC 2013 is when the

00:25:29   developer tools team came to know about it and really started working hard on it.

00:25:34   And Swift is a huge, huge effort by hundreds of people, and that's when all the work on

00:25:41   and bring up the debugger and the IDE support

00:25:43   and playgrounds and all the other things

00:25:46   that the charge into Swift 1.0

00:25:48   really started coming together and make happen.

00:25:50   So that's kind of how Swift came to be.

00:25:53   It was again, one step after another,

00:25:56   building small things, explaining to people

00:25:59   why it made sense, why it was worth it.

00:26:01   And then also I think that a major important aspect

00:26:04   of Swift being, I guess, worth taking a risk on

00:26:09   was that we told people that we would not guarantee

00:26:13   source compatibility in 1.0.

00:26:14   And that was really interesting because

00:26:19   that actually was a big relief for people

00:26:21   because internally that meant that

00:26:23   it didn't have to be perfect when it launched.

00:26:26   It meant that we could learn, we could adapt,

00:26:29   and that as long as we were clear with the community

00:26:31   about that, that that would allow us

00:26:33   to get to ultimate greatness

00:26:35   and learn from actual usage and practice.

00:26:38   And I think that was a really key piece to SWIFT coming

00:26:42   and actually making it to the market.

00:26:44   - So strategically speaking, when you were doing

00:26:47   like the work to improve Objective-C,

00:26:50   did you have in mind the ability to potentially leverage

00:26:55   some of that work for SWIFT?

00:26:57   Like, I'm trying to think of like the strategy

00:26:58   of how you get it done.

00:26:59   Like part of it is personal relationships

00:27:01   and like knowing the right people.

00:27:03   Part of it is persuasion.

00:27:04   You have to persuade them with your technical arguments

00:27:06   and your business arguments and stuff like that.

00:27:07   But then part of it was part of it also laying the groundwork

00:27:12   with efforts and technologies that have multiple uses.

00:27:16   Yeah, absolutely.

00:27:17   So one great example of that is Arc.

00:27:20   It was really clear to me that if we were to get to memory

00:27:22   safety, we had to have automatic memory management.

00:27:25   And I don't know if you want to go down the GC versus Arc

00:27:28   rabbit hole or not, but Arc seemed like obviously

00:27:31   the right model to me and to some other people.

00:27:35   And so we said, OK, we need to get to an automatic memory

00:27:39   management model.

00:27:41   Objective C isn't, because Objective C at the time

00:27:43   had the object garbage collector, which

00:27:46   had numerous problems.

00:27:48   And so we had to get Objective C to be memory managed.

00:27:52   And so that's why Arc became a thing.

00:27:56   It became a really high priority.

00:27:57   And I think that it's a great example of something

00:28:00   that by itself had a huge amount of value to the Objective C

00:28:03   community.

00:28:04   And then after that, we had similar other efforts,

00:28:07   like modules, for example.

00:28:09   That was a huge thing that both improved build time,

00:28:11   but was also absolutely essential to enabling Swift code

00:28:16   to eventually just say import UIKit and get everything.

00:28:19   And so there's a number of things

00:28:20   that rolled out over the years.

00:28:22   And it was really funny at the time

00:28:23   because the Objective-C developers externally

00:28:26   and even internally to Apple always accused the compiler

00:28:29   and languages team of taking Objective-C on this random walk

00:28:33   and they didn't know how it all fit together.

00:28:34   And where's the strategy,

00:28:36   and why are you guys working on this,

00:28:38   and why aren't you working on some other syntactic sugar

00:28:40   for the thing I want?

00:28:41   And of course we could never tell them,

00:28:43   but there was a good reason.

00:28:45   And so another example of that is

00:28:47   the object to see literals feature.

00:28:49   I think we introduced that in 2013, if I recall,

00:28:53   for array literals and other things like that.

00:28:57   That was an interesting feature

00:28:59   that it was a relatively small amount of engineering work that brought the ObjectC language much

00:29:07   closer to Swift in terms of having arrays and dictionary literals as part of the language.

00:29:14   But the real reason for doing it is that it was a small amount of work that moved ObjectC

00:29:18   forward, which allowed the compiler and language team to focus on Swift.

00:29:23   Swift was a very large amount of work and that was appeasing the community and solving

00:29:31   real problems, but buying time to actually pour into the multi-year project of making

00:29:36   the Swift language happen.

00:29:37   That's when you pull out the syntactic sugar. Programmers love it. It takes ten minutes

00:29:41   to implement. Here you go. Everyone applauds when they see the slide. Yay!

00:29:45   I mean, in all fairness, that was a really big deal. Anyway, so kind of building on the

00:29:50   the Apple internal reaction thing.

00:29:53   This language in its development

00:29:56   and then its public release

00:29:59   is probably a fairly unique language

00:30:01   in the context in which it was released.

00:30:03   You have this massive company,

00:30:05   I mean nobody probably had more object-to-see programmers

00:30:08   than Apple does,

00:30:09   and so you have this massive company

00:30:11   with tons of internal programmers

00:30:12   and a massive internal code base

00:30:14   that is using this other language.

00:30:16   You have this entire community of iOS and Mac developers,

00:30:21   and then you have the entire world watching every move

00:30:24   Apple makes and putting it under very heavy scrutiny.

00:30:27   So the release of this language in this context

00:30:30   is probably not only very high pressure,

00:30:32   but also unique in that you knew that you were gonna face

00:30:37   a lot of people up front.

00:30:40   Most languages probably start out with a few people

00:30:42   using them in some random corner of the internet,

00:30:44   and eventually maybe it slowly takes off,

00:30:47   this was not that way.

00:30:48   And so what considerations I guess went into that,

00:30:52   and also how were you able to convince people

00:30:56   even inside of Apple to use Swift,

00:31:00   and how was that going?

00:31:02   - So I guess there's different answers to that

00:31:07   for different phases.

00:31:10   we had no idea that the reaction would be as strong

00:31:15   and as positive as it was, and so I think we were blown away

00:31:17   and caught unaware in some ways.

00:31:22   But in other ways, I think we did the right thing.

00:31:25   So for example, if you look at Swift over time,

00:31:29   Swift one and Swift two are as similar to Objective-C

00:31:33   as we can make them.

00:31:34   So if you look at the way that selectors are named,

00:31:37   for example. It was very, there's a very direct correlation. If you look at the way Swift

00:31:44   1 was explained to people, it was explained to people as, it's just like Objective-C,

00:31:51   you can use all your same patterns, you can use all the same frameworks, you can continue

00:31:54   doing object-oriented programming, you can do all these things, but it also has some

00:31:59   cool new things, like enums and pattern matching and these other things. And so it's great

00:32:04   because it's just cleaned up syntax for what you already know, plus it has some new cool stuff that

00:32:08   you can play with. And then you fast forward a year or two and the Swift community was really

00:32:14   taking off. It was people were understanding what Swift was about. Swift open source has

00:32:20   also enabled this. And Swift 3 is really about Swift becoming its own language that was really

00:32:25   true to itself and stands by itself. And that's where you see the method call syntax, for example,

00:32:32   being radically changed, and a lot of things just kind of coming together

00:32:37   and really focusing and polishing the language.

00:32:42   In terms of the rise of the external community and people using it,

00:32:48   that was really, really hard for us because...

00:32:52   So my experience had been with LLVM and with Clang.

00:32:55   Clang as a C and C++ compiler in Objective-C

00:32:58   was completely different than Swift

00:33:00   because when we open source and launched Clang, which was at Apple, everybody

00:33:08   yawned, we open sourced it very early on and people said, okay, you're nuts.

00:33:14   Nobody can build a C plus plus compiler.

00:33:16   That's, that's not a thing.

00:33:17   Why are you even messing around with this?

00:33:19   And, you know, we got one contributor to the project and we had no users.

00:33:24   And then we got, you know, a month later we might get another contributor, another

00:33:28   person part-time setting in patches.

00:33:30   And it was a very slow growth that was ultimately really great because it was relatively low

00:33:37   pressure with Swift.

00:33:39   And with the way it was launched, it was completely different because it went from nobody knowing

00:33:44   about it to everybody knowing about it overnight, literally.

00:33:48   And there being so much excitement, so many people that were nervous and had bad reactions,

00:33:54   other people that were super excited, but a lot of people that were suddenly hitting

00:33:57   bugs and having challenges and problems and why did you do this and why didn't you do that?

00:34:02   And some of that was misguided just because they didn't know Swift yet, but other aspects were

00:34:09   really spot on. And that was when we really started learning about how people were using

00:34:14   and started iterating and moving Swift. And Swift between the WWDC launch and Swift 1.0

00:34:19   release changed dramatically. And that was a really, really hard time for the entire team

00:34:26   because we really wanted to get it as close as we could to what we wanted, but we had a very short

00:34:32   amount of time to do so. And I think that's been true for Swift 2 and Swift 3 as well, where we have

00:34:39   really high goals for the team and really high goals for what we want to get done. And that makes

00:34:44   it a lot of pressure and a lot of stress, but it's, I think, worth it to serve and see the

00:34:52   the community around Swift grow and see people use it

00:34:56   and see people learn it and it's been a lot of fun.

00:34:59   - So I'm curious, I know when Swift first came out

00:35:02   it was hard to get a lot of adoption inside of Apple

00:35:05   for various tooling reasons among maybe

00:35:09   whatever else was going on.

00:35:11   How is internal adoption going today?

00:35:13   Are we seeing meaningful adoption now

00:35:15   or is it mostly iOS programmers who are using it

00:35:16   and not anybody inside?

00:35:18   The Swift team itself has specific goals they need to achieve

00:35:23   before there can be truly across-the-board adoption at Apple.

00:35:28   ABI stability is the number one thing that prevents framework developers,

00:35:31   for example, from adopting Swift.

00:35:34   So that's a really important thing,

00:35:35   and that's one of the reasons it's always a really high priority.

00:35:38   But Swift has been adopted by application developers and other things.

00:35:42   The dock is public.

00:35:44   Swift Playgrounds app is public.

00:35:46   The music app in iOS is publicly known, so there are definitely some big adopters.

00:35:52   More broadly though, the big problem is that I think, I won't speak for everybody, but

00:35:57   many, many people doing Objective-C development at Apple are chomping at the bit.

00:36:02   They want to be using Swift, and so it's really a matter of just getting the technology

00:36:06   problem solved and checking off the things that are holding people back.

00:36:10   It's not about people dragging their feet and not wanting to use it.

00:36:15   - Makes sense.

00:36:16   - Yeah, that's really awesome.

00:36:17   From the outside, it's so hard to figure out,

00:36:20   is Apple internally like, ugh, really?

00:36:23   Or is Apple internally, like you said, really excited?

00:36:26   And I'm sure that there's some of both,

00:36:27   but that's really good to hear.

00:36:29   - Yeah, and I think it's also changed over time.

00:36:31   When Swift first came out, of course,

00:36:33   it was a huge surprise for most of the software team.

00:36:36   And so many people went through the usual phases

00:36:41   of, but I already know Objective-C,

00:36:43   why would I learn this new thing?

00:36:44   Objective-C is great.

00:36:45   and Objective-C is great.

00:36:47   So that's an objective statement, right?

00:36:50   But I think things have shifted over time,

00:36:53   and as Swift has matured,

00:36:55   it's definitely become a lot more appealing.

00:36:58   One other technology problem that is hilarious,

00:37:01   but also really important is the Apple framework stack

00:37:05   has to support 32-bit Mac apps.

00:37:08   And 32-bit Mac apps have this interesting challenge of,

00:37:11   they have what's called the classic Objective-C runtime,

00:37:14   which doesn't support things like non-fragile instance variables and things like that.

00:37:19   And so at some point in time, the Swift team will need to make the Swift runtime work in

00:37:23   that mode or figure out some other solution to adapt it, because until that happens, it

00:37:29   won't be possible to use Swift in AppKit, for example.

00:37:32   Huh.

00:37:33   That's fascinating.

00:37:35   So kind of taking a more broad view, could you name either your most proud accomplishment

00:37:43   during your time at Apple that you can discuss publicly anyway, or if not, you're most proud,

00:37:47   just the first one that jumps to mind?

00:37:49   Tim Cynova Wow. I don't know. I've been really

00:37:53   fortunate to work on so many really important projects. And I think that between LLVM and Swift,

00:38:01   for example, it's really a hard call. Swift, I think, impacts more people in terms of the number

00:38:09   of people that actually know they're using it and want to learn it and things like that.

00:38:14   But I think the LLVM has been picked up and used so far across the industry and it's kind of

00:38:19   standardizing the world's compilers. I think that that's probably more profound at this point.

00:38:24   So it's really, it's a hard call. I mean, there are a ton of really,

00:38:30   really great opportunities that I've had and it's been a lot of fun over many years now.

00:38:36   Also, outside the open source pieces, working with the Xcode team and working with the other

00:38:41   teams and developer tools has been really phenomenal.

00:38:43   I mean, there's so many great people at Apple and in developer tools, it's just been a joy.

00:38:49   So what do you expect to miss most about being at Apple?

00:38:52   And I'm going to let you expound on this, but I'm going to take it off the table and

00:38:56   say you have to pick your second choice.

00:38:57   You're going to say you miss the people because of course you do, right?

00:39:00   Yes, that is actually what I would say.

00:39:02   Right.

00:39:03   So go ahead and tell us about all the great people

00:39:06   you work with at Apple, but besides that,

00:39:07   what do you expect to miss most about Apple,

00:39:09   the company you're working with?

00:39:10   - Well, so the great thing about Apple,

00:39:12   and the thing that I don't think that many people

00:39:15   really get about Apple, is that it is really

00:39:19   one of the few best places in the world

00:39:22   where you can work hard, but also work on products that ship

00:39:27   and that ship to millions of people,

00:39:30   so that your hard work ends up mattering.

00:39:33   There are a lot of places you can work hard.

00:39:35   There's a lot of places that you can work on interesting things, but there's also

00:39:41   a lot of places that end up not shipping a lot.

00:39:44   Or if they ship it, very few people actually use it.

00:39:47   And so Apple's really magical in that it combines being able to work hard and do great

00:39:54   things with it actually mattering.

00:39:56   And to me, that's the thing that is just so phenomenal about Apple.

00:40:01   - So moving on to your new role at Tesla,

00:40:05   do you think that Swift will still be a major part

00:40:09   of your work life in some way?

00:40:11   Or will it basically be something you do

00:40:14   in the evenings and weekends?

00:40:15   'Cause we all know that Silicon Valley tech startups

00:40:17   don't usually work people too hard,

00:40:19   so you're gonna have tons of free time, right?

00:40:21   - Yeah, so this jump I'm making is definitely do a cushy,

00:40:24   easy job with no stress.

00:40:27   That's what I'm looking for here.

00:40:28   (laughs)

00:40:30   So I don't know, we'll have to see.

00:40:33   I haven't started yet,

00:40:35   and I think it's gonna be a very challenging job,

00:40:37   and one of the reasons I'm excited about it

00:40:38   is 'cause I really wanna throw myself

00:40:40   into another hard technology problem,

00:40:43   and so I'm really excited about that.

00:40:45   I do expect to be involved with the design of Swift

00:40:48   and helping with the core team

00:40:50   and helping the Swift evolution process

00:40:52   and helping in a lot of that kind of respect.

00:40:54   But one of the things to keep in mind

00:40:55   is that Swift is actually a really tiny slice

00:40:59   of my job at Apple.

00:41:01   And so, you know, I had a very full schedule

00:41:05   dealing with lots of other stuff,

00:41:07   and it was already kind of a nights and weekends project

00:41:11   that I was coding on it

00:41:12   and contributing at the level that I was.

00:41:14   So I'm hoping that there won't be a big change,

00:41:16   but honestly, I'll have to see.

00:41:18   Obviously, I care a lot about Swift

00:41:21   and I really want it to get to its goal of world domination.

00:41:25   So.

00:41:25   We're sponsored tonight by Eero.

00:41:28   Go to Eero.com, that's E-E-R-O.com

00:41:31   and use code ATP when you order

00:41:33   for free extra added shipping.

00:41:35   Wi-Fi is broken.

00:41:36   You probably have one Wi-Fi router with,

00:41:39   if you're lucky, a bunch of antennas on it

00:41:40   that look hideous and you're trying to cover

00:41:43   your whole house with Wi-Fi,

00:41:44   but it just doesn't reach every room.

00:41:46   It just doesn't reach everywhere

00:41:47   because Wi-Fi is hard when you're just covering it

00:41:49   from one point.

00:41:51   Eero solves this problem by having a router system

00:41:54   where they have this little Eero unit,

00:41:56   it's nice, it's attractive, it's tastefully designed,

00:41:58   there's not a bunch of maintenance sticking out of it,

00:42:00   and you can buy one of them, or you can buy 10 of them,

00:42:03   or any number in between,

00:42:04   and you put them around your house,

00:42:06   and each one covers the area in WiFi,

00:42:09   and they all talk to each other wirelessly,

00:42:11   so you don't have to run wires all over your house,

00:42:13   you can have your entire house blanketed in WiFi with Eero,

00:42:17   and they talk to each other over this mesh network,

00:42:19   so it's even faster than previous,

00:42:21   if you ever use an extender or anything else,

00:42:22   extenders are very slow,

00:42:23   It's even faster than that by a lot.

00:42:26   And Eero is true enterprise-grade quality and performance.

00:42:29   They have everything you need from encryption features

00:42:31   to things like parental controls.

00:42:33   And they're actually updating it over time.

00:42:35   They've done over 12 updates since launch

00:42:37   with more to come to add features.

00:42:39   They have an app for very easy setup,

00:42:41   and they have incredible customer support if you need it.

00:42:44   They recommend one Eero per 1,000 square feet,

00:42:46   so the typical home will have two or three of them.

00:42:47   They got a three-pack as a pretty reasonable

00:42:50   starting point for almost everybody.

00:42:51   There's a 30-day money-back guarantee

00:42:53   If you don't like it, or if you just buy too many,

00:42:55   you wanna return a couple of them

00:42:56   if you end up not needing as many as you bought,

00:42:58   check it out, the reviews are stellar, they back this up.

00:43:02   Go to eero.com, that's E-E-R-O.com,

00:43:05   and use code ATP when you order

00:43:07   for free X-rated shipping.

00:43:09   Thank you very much to Eero for sponsoring our show.

00:43:11   (upbeat music)

00:43:16   - Obviously Swift is open source,

00:43:17   I don't know if you were aware of that, Chris.

00:43:19   - Oh, I read about that.

00:43:20   - Yeah, right, how do you feel like it's been going so far

00:43:22   And I'm assuming, similar to Jon, I'm going to take away the obvious answer of, "It's

00:43:27   going well."

00:43:28   But maybe to kind of cue conversation, what's been really surprising about going open source?

00:43:35   And you can get as specific or as broad as you'd like to be, but I've got to imagine

00:43:39   that you guys had a bunch of expectations about what going open source would be like,

00:43:43   and I would imagine some of them were accurate and some of them weren't.

00:43:45   So how do you feel like the Swift open source project has been going?

00:43:48   - Yeah, so I think that to summarize,

00:43:52   it's not just going well, it's going far better

00:43:54   than we ever anticipated, and that caused problems.

00:43:57   (laughing)

00:44:00   So for context, I and many of the other people in the team

00:44:04   had quite a bit of open source experience.

00:44:06   So LVM and Clang, for example, were open source.

00:44:08   They were, they are vibrant and amazing communities

00:44:14   with hundreds of contributors and dozens of companies all collaborating in public

00:44:20   and doing really amazing stuff, even some of the most staunch competitors,

00:44:24   you know, AMD and Intel and AMD and Nvidia or, you know, these kinds of

00:44:30   companies that really, you know, don't get along on the business side of things.

00:44:34   But the engineers were great at working engineer to engineer and solving problems

00:44:39   and staying focused on making things better.

00:44:42   So with Swift, we assumed that it would be very similar to that.

00:44:45   But what we found is that there was a major difference between launching Swift and launching

00:44:51   something like Clang, for example, which is that when Swift launches open source, which was December

00:44:57   3rd, just over a year ago, it already had, I don't know, a million users. And where Clang started and

00:45:07   everybody yawned and didn't really care and grew slowly. Swift open source started and was

00:45:14   amazingly fast moving, changing, tons of people, hundreds of patches on the first day. It was

00:45:20   totally crazy and we didn't really know what to do. And so, I mean, I am like super impressed with

00:45:27   the Swift open source community and all the people involved and the energy and just, I mean,

00:45:31   It's hard to believe how great everything is.

00:45:35   But it really did create problems because we had to figure out things

00:45:39   like how are we going to stay up in terms of the patch volume. Okay, we're getting hundreds

00:45:43   and hundreds of emails a day to the Swift Evolution mailing list. What are we going to do about that?

00:45:47   How do we balance Apple's goals

00:45:51   for pushing Swift forward with the goals of the community, which are somewhat more

00:45:55   chaotic and less directed. And I think that over the last

00:45:59   Last year we've learned a lot,

00:46:00   and you can see that reflect in terms of

00:46:03   how the project's being managed

00:46:05   and how things are being done.

00:46:07   But it's always been super important to be

00:46:09   not just open source, but

00:46:11   I guess if you look at an open source project,

00:46:15   there's three kind of easy levels to look at it.

00:46:18   The first basic requirement that you have to satisfy

00:46:22   to be open source is to make your code available, right?

00:46:25   And so you can produce tarballs periodically,

00:46:27   and that's technically open source.

00:46:29   You can allow contributions, and if you do that through pull requests or patches or whatever,

00:46:35   then people can engage with it and make the code better.

00:46:39   There's open community, so not only do you accept a patch, but you actually discuss things

00:46:45   and talk about things in public, and then there's open design.

00:46:49   And with Swift, we went all the way, and I think it was totally the right thing to do

00:46:53   because we really wanted to benefit from all the smart people in the world,

00:46:57   And it was, and still is, amazing,

00:47:00   but it's also very challenging.

00:47:02   - Yeah, I can imagine.

00:47:03   So building upon the open sourcing of Swift,

00:47:07   it was very surprising to me,

00:47:09   and I think a lot of the community,

00:47:10   that Apple chose to upload the entire commit history.

00:47:13   It wasn't just a, here's day one, initial commit,

00:47:16   and it's 11 gazillion files and 80 gazillion lines of code.

00:47:20   Was that planned from the start,

00:47:22   that you guys would upload the entire history?

00:47:25   - I wouldn't say it was planned from the start

00:47:26   that we'd upload the entire history,

00:47:27   but it was kind of assumed from the start

00:47:30   that it would be open source at some point.

00:47:33   - Interesting.

00:47:33   - And if you look at Apple's history,

00:47:35   I think that's, in the tool space,

00:47:39   I think that's fairly straightforward.

00:47:42   LLVM wasn't started at Apple,

00:47:46   but almost everything Apple does

00:47:49   ends up going public in the LLVM space.

00:47:52   Clang was started at Apple,

00:47:54   and Clang was contributed by Apple

00:47:55   to the LVM project,

00:47:57   and that included its full revision history.

00:48:01   Other projects like LDB and libc++ and compiler RT

00:48:05   and all these other smaller projects were started at Apple

00:48:09   and contributed to the open source project.

00:48:11   So with Swift, it was kind of assumed

00:48:13   that that would happen at some point.

00:48:15   The real question was,

00:48:17   when is the right time for that to happen?

00:48:19   And if you remember the days of Swift 1.0,

00:48:22   Swift 1.0 to 2.0 in particular

00:48:25   was a super chaotic, super learning as we went

00:48:29   and trying to keep up with the community

00:48:30   and trying to keep up with the pace

00:48:32   and the challenges that people were facing

00:48:34   and trying to get key pieces like the air handling model

00:48:37   and protocol extensions and all that kind of stuff

00:48:38   that had always been planned,

00:48:39   but didn't make it into Swift 1.0.

00:48:43   And so really focusing on that was the priority.

00:48:46   And so we decided that open sourcing Swift at 1.0,

00:48:49   for example, would be really actually bad

00:48:52   for the Swift community because there are major pieces

00:48:54   the language that weren't there.

00:48:56   We would have to spend a lot of time community building

00:49:00   and try and explain to people the difference between

00:49:02   what was not there but should be there

00:49:04   and what is there and known broken.

00:49:07   And we had to do a lot of that when Swift

00:49:10   was eventually open sourced in last year,

00:49:13   right after Swift 2.0.

00:49:15   But it was a much better place

00:49:16   and the team could actually handle the load

00:49:18   of doing the community.

00:49:20   And we didn't expect the kind of response that we got,

00:49:22   but we knew that building a vibrant open source community

00:49:25   is a lot of work and it's not something

00:49:27   to be underestimated.

00:49:28   And we wanted to make sure that Swift 2 was out the door

00:49:31   and it wasn't kind of a resource contention

00:49:34   between do we finish Swift 2 or do we start open source?

00:49:38   And that's why it was announced to be open source

00:49:42   by the end of the year,

00:49:42   because that meant that we could start working

00:49:44   on the open source infrastructure project,

00:49:46   bringing up all the other stuff that it takes

00:49:48   to make something open source after Swift 2 is complete.

00:49:52   So my recollection of the Swift 3 in the planning stages

00:49:56   was that ABI compatibility was somewhere in the list of,

00:50:01   I don't know if you wanna call them goals,

00:50:03   but somewhere in the list of items

00:50:05   that were in contention for Swift 3.

00:50:07   And at some point along the development process of Swift 3,

00:50:10   ABI compatibility got postponed.

00:50:13   And given what you just said about the importance

00:50:15   of ABI compatibility for the framework people

00:50:17   inside Apple or whatever, what can you say about that?

00:50:22   Did you learn lessons from ABI compatibility being planned for Swift 3, or do you think

00:50:28   it was never really a hard and fast goal and you totally made the right call to delay it,

00:50:32   or are you disappointed that it didn't make it?

00:50:34   Well, I think many of those things.

00:50:36   I mean, we're disappointed that it got delayed, but it was totally the right thing.

00:50:41   I think that there's a couple of things to learn from that, one of which is software

00:50:44   schedule planning is hard.

00:50:47   Breaking news.

00:50:49   - Yeah, so that's definitely still a thing.

00:50:53   There's also that we didn't anticipate the,

00:50:57   so the original plan that you're referring to

00:50:59   was announced before Swift was open source,

00:51:01   or sorry, it was announced the same time

00:51:03   Swift was open source.

00:51:04   And so we had no idea that the community

00:51:07   would descend on Swift and suddenly have

00:51:09   all these new demands and consume so much time

00:51:12   and energy that kind of took away from programming

00:51:16   to do the community building piece.

00:51:18   So that was part of it.

00:51:19   Another part of it is that ABI stability

00:51:22   is super important, but it's not as important

00:51:25   as people think it is for application developers.

00:51:28   It's really important to Apple.

00:51:29   But what we realized in the Swift 3 timeframe

00:51:33   is that the thing app developers would benefit

00:51:35   from the most was actually source stability.

00:51:39   So who actually wants their application

00:51:42   to be broken when they get a new version of Xcode?

00:51:44   Well, really nobody, right?

00:51:47   And so kind of halfway through the release,

00:51:49   we pivoted and source stability became the goal.

00:51:53   And so I'm really excited that when Swift 3.1

00:51:57   or Swift 4 comes out,

00:51:58   that it's still gonna be able to build Swift 3 code.

00:52:00   And even if there are minor changes that need to be made

00:52:04   for one reason or another, that you can upgrade

00:52:06   and you have great compatibility with your old code

00:52:10   and you don't have to start the migrator

00:52:12   before you can do anything.

00:52:13   So it's gonna be a great improvement for people's lives.

00:52:16   Alright, so moving on a little bit to kind of this

00:52:20   branch topic here of server-side Swift,

00:52:22   Swift on Linux, things like this.

00:52:26   Is Swift on the server something that,

00:52:29   I know it's possible, and there's like some,

00:52:33   seemingly some early efforts now to get that going.

00:52:35   Do you see this as like a major goal for Swift

00:52:39   as the language, and not in any kind of official capacity,

00:52:42   but just like you as a person who likes and uses Swift

00:52:45   and has a strong role in the community,

00:52:48   like is server-side Swift a thing that you wanna be

00:52:53   like a major thing to compete with things like Python

00:52:57   and Rails and stuff on the server?

00:52:58   Or is it intended more to be kind of like a specialized

00:53:02   thing that is probably not gonna be in widespread use

00:53:04   by like web and backend programmers?

00:53:07   - So I think that everybody involved with the project

00:53:11   wants it to be the way to do server development.

00:53:15   And I think that to understand that,

00:53:17   you have to understand we're just kind of entering

00:53:21   phase two of Swift's world domination plan.

00:53:24   (laughing)

00:53:26   So this will probably sound insane,

00:53:28   but maybe in a few years it will sound less insane.

00:53:32   But the way to look at, the way I look at it,

00:53:35   and the way that many other people at Apple look at it

00:53:37   is that we want Swift to be the next big thing, right?

00:53:41   We want it to be more popular than Java was, or is.

00:53:44   We want to be more popular than Python.

00:53:46   We want to be maybe even more popular than C someday.

00:53:49   That would be a stretch, but that would be great.

00:53:52   And so if that's the problem to solve,

00:53:54   how do you solve that problem?

00:53:56   Well, open source is a huge piece of that.

00:53:58   Without open source, it's not going to be available

00:54:00   on other people's platforms.

00:54:01   It's not gonna be used in education and teaching.

00:54:05   That's just not gonna happen.

00:54:06   And so open source is a major piece of that.

00:54:08   If you go back farther, before that,

00:54:10   Swift world domination doesn't happen

00:54:13   unless Swift gains relevance, right?

00:54:17   And I think Swift has nailed the relevance side of things

00:54:20   with the iOS and Apple platform development side

00:54:24   of the story where, you know, maybe not Marco,

00:54:27   but most other people are switching to Swift very quickly

00:54:31   and seem very happy using it.

00:54:33   - Actually, I started using it today.

00:54:35   - Okay, good call.

00:54:36   - I switched today in honor of this interview.

00:54:38   I wrote my first Swift today, an entire extension,

00:54:42   and Overcast 3.0 is written in Swift.

00:54:44   - Wow.

00:54:45   - See, fantastic. - Look at you go.

00:54:46   I'm proud of you.

00:54:47   - It is a good day.

00:54:48   - Yeah, and more will be coming,

00:54:51   although there's a lot of Objective-C there,

00:54:53   so I'm probably a long way away from it being all Swift.

00:54:56   - Yeah, well, that's okay.

00:54:58   Swift loves Objective-C.

00:54:59   - Exactly.

00:55:01   - So the way I look at it is that the first step

00:55:03   of Swift world domination is getting to relevance,

00:55:06   and for a language to get to relevance,

00:55:08   it needs a killer app, right?

00:55:10   It needs a reason why people would want to use it,

00:55:12   And for Swift, that's clearly iOS and Mac

00:55:15   and other Apple platform development.

00:55:17   Second, it needs to be open source.

00:55:20   Third, it needs to go beyond, right?

00:55:24   And the next step, the frontier of where it makes sense

00:55:28   to expand out to, or if you're a real-time strategy

00:55:30   game player, the natural expansion is a place

00:55:34   where the language is,

00:55:37   where the language actually only needs

00:55:41   few things added to it to be good. And so I think server development is really that

00:55:45   next step because server development is very similar to app development in terms of the

00:55:49   kinds of code that you need to write. It's very similar in terms of many of the frameworks.

00:55:54   The major missing piece is that it needs to run on Linux and other pertinent server development

00:56:00   platforms and there's then the whole library ecosystem that needs to be built out. And

00:56:06   so I think that what we're in right now is we're in a really exciting phase where those

00:56:10   platforms are being built, those frameworks and different pieces of infrastructure are

00:56:15   coming together, and that's really the idea behind the Swift server working group that's

00:56:20   an official part of Swift.org, is getting all the people working in the space to talk

00:56:24   to each other. And I'm very excited about that. Going beyond that, though, with the

00:56:31   goal of being more relevant than Java, for example, if we're going to pick on Java, the

00:56:38   The dream of Swift is to scale all the way from scripting language all the way down to

00:56:43   low-level systems programming.

00:56:44   You could write a kernel in it, or you write some firmware in it.

00:56:48   I think the scripting side of it is maybe more straightforward when the Swift community

00:56:55   and the core team have time to deal with it, because there you're talking about integrating

00:57:01   regular expressions, integrating multi-line string literals, and integrating other features

00:57:05   like that that people love from scripting languages. Those are big projects, but those

00:57:11   are kind of well-known, I guess, and they will fit and drop right into the existing

00:57:19   system that Swift provides. Systems programming is, I think, the big next

00:57:25   frontier. I think that's where Swift can really distinguish itself from Java or other

00:57:31   competitive languages because among other widely used languages out there,

00:57:36   there's really nothing that can unseat C or C++.

00:57:38   Rust, for example, is an interesting language,

00:57:43   but it hasn't gotten a lot of adoption yet.

00:57:44   And I think that Swift is more interesting than Rust in some of the higher level

00:57:49   application domains. But we'll see, Rust is a great language as well.

00:57:54   And so I'm really interested to see the Swift for systems programming work

00:58:00   work, get going, and I think that that'll be a couple

00:58:03   of years out before it really comes together,

00:58:05   but once it does, I think that Swift can be,

00:58:08   really be the next big thing, and I'm excited about that.

00:58:12   - So just stepping back a second to the server role

00:58:15   of it possibly taking over there, 'cause I would love,

00:58:19   here I am using PHP and Objective-C,

00:58:21   these two languages that are fairly old,

00:58:23   and I mean, PHP is way more hated than Objective-C,

00:58:26   but these are the two languages I use

00:58:30   for various historical and practical reasons.

00:58:32   On the server, a lot of what makes a language succeed

00:58:37   or fail on servers and in web development

00:58:41   is not necessarily how good of a language it is,

00:58:44   but how healthy and universal and developed

00:58:48   the frameworks around it are for things like web development,

00:58:51   how practical and easy it is to deploy and run on servers.

00:58:56   So, Swift being its own good language,

00:59:01   that alone I don't think is enough

00:59:03   to get traction on the server.

00:59:06   Do you think, is it necessary for the Swift team,

00:59:10   like the core group who's running Swift,

00:59:13   whether that's Apple or the community of contributors

00:59:16   with Apple or whatever else,

00:59:18   is it important for them to develop

00:59:20   and kind of make an official set of server and web

00:59:25   frameworks and libraries and tools?

00:59:28   Or do you think it's sufficient to kind of take the risk

00:59:32   to let the community do that,

00:59:33   but at the risk of fragmentation

00:59:35   and maybe nothing ever taking off?

00:59:36   - Well, so that's an interesting question,

00:59:39   and keep in mind that I don't have a lot of

00:59:41   practical experience building server apps, so this is--

00:59:44   - You're not missing much.

00:59:46   - My opinion based on talking to other smart people.

00:59:50   So the approach the Swift project's taking

00:59:53   is it's looking to standardize what's colloquially,

00:59:57   but not correctly known as server foundation

01:00:00   kind of technologies.

01:00:01   So it will not be named server foundation,

01:00:03   but that kind of an idea.

01:00:05   And so take the encryption, the network transport,

01:00:08   the HTTP kinds of things that everybody needs

01:00:12   for server technologies and standardize that

01:00:14   as part of the Swift project,

01:00:16   but at least in the short term,

01:00:17   not look to standardize a specific web framework.

01:00:20   Because there are half a dozen different,

01:00:22   completely different approaches that are interesting

01:00:24   in different kind of demands.

01:00:26   And I don't think there's a clear winner yet.

01:00:29   It's possible that after the first few rounds shake out,

01:00:33   then there will be an equivalent, you know,

01:00:35   Ruby on Rails kind of dominant pattern

01:00:37   and a framework that emerges.

01:00:41   And if so, then maybe that would make sense.

01:00:42   But I don't think Swift needs for there to be a winner

01:00:46   at the high level.

01:00:47   As far as what can the Swift core language

01:00:52   and language and compiler folks do about this.

01:00:55   I think there's really two things,

01:00:57   one of which is the Swift package manager.

01:00:59   I think the package manager is really key

01:01:01   to scaling out the ecosystem and getting people

01:01:05   to work together with the common ecosystem.

01:01:09   It's also the best and I think only way

01:01:11   to build Swift code on Linux and other platforms.

01:01:15   I don't mean to single out Linux.

01:01:16   It's just, it's the biggest server development one.

01:01:21   So I think that's a big piece.

01:01:22   I think the other piece that will be really amazing

01:01:24   is when the concurrency model comes up,

01:01:26   because I think that's one of the reasons that makes Go

01:01:30   particularly compelling for server development,

01:01:32   is it has a really well-developed story there,

01:01:34   along with all the libraries that go together

01:01:36   for server and cloud development.

01:01:38   And so when the pieces of the concurrency model

01:01:41   start coming up, which will probably,

01:01:42   the first pieces will ship in Swift 5, is my guess,

01:01:46   that will make Swift an even more compelling

01:01:48   kind of answer for that kind of space.

01:01:52   But I don't think we need a server language feature,

01:01:56   if that's what you're asking.

01:01:58   - So going to the other extreme from the server side

01:02:01   and scripting to getting back to systems programming,

01:02:04   one thing I've seen related to this,

01:02:07   and I think this all stems from this quote

01:02:10   from the original Apple Swift book

01:02:12   that Swift was designed to scale from Hello World

01:02:14   to an entire operating system,

01:02:15   like that the world domination plan

01:02:17   there from the beginning, right? In the first paragraph of the thing. When I talk to people now

01:02:24   about Swift as a systems language, often what I hear is people relating the ways that it is not

01:02:34   ready to be a systems language yet, which is what you just talked about, but then deciding based on

01:02:39   that that because it's not ready to be a systems language now, it never will, and then they dismiss

01:02:45   it. Like in other words, like that may have been the plan, but clearly for reasons X, Y, and Z,

01:02:51   you still have to use C for this. Therefore, Swift is just a way to write apps for iOS and macOS.

01:02:57   I mean, I'm not quite sure what you can do about that, but do you think about

01:03:02   how to change perception as the language gets older and it's old age, now it's up to 3.0.

01:03:09   Like that it starts to, you know, that nobody puts Swift in a corner. Like that

01:03:14   And people think they know what Swift is, and they say, "Oh, it's this language

01:03:18   that does this thing," and that your plans for world domination may be thwarted by the

01:03:22   idea that people are pigeonholing the language because it's been around for a few years

01:03:25   and they think they know it.

01:03:26   I think that you're onto something.

01:03:28   I think that's a real problem.

01:03:29   I don't think systems programming is the place where that's a problem yet, though,

01:03:32   because I don't think it's reasonable for me as a crazy man going around saying,

01:03:38   "Swift will someday do systems programming really well.

01:03:41   You should remember that."

01:03:42   I don't think that's a good way to spend time at the moment.

01:03:46   When it does that, then the question becomes,

01:03:48   how do you make people aware of that,

01:03:52   and how do you get people to change

01:03:55   their prior misconception?

01:03:56   But at that point in time, you can have a very practical,

01:03:59   look, you can do this, and this is so great,

01:04:00   and now you get all the advantages to C, but it's safe,

01:04:03   and you can point to specific reasons why it's better.

01:04:07   So I'm not too worried about it

01:04:09   in the space of systems programming,

01:04:11   But I think there is a practical problem today,

01:04:14   which is Swift is open source.

01:04:17   The Apple development community knows Swift very well,

01:04:21   but pretty much everybody else doesn't, right?

01:04:25   And if you go to a random, say Linux developer,

01:04:30   just to continue talking about Linux,

01:04:33   they all perceive Swift as being an Apple thing

01:04:36   and only relevant to Apple platforms,

01:04:38   and they don't even learn about it, right?

01:04:41   And so I think that there is an interesting challenge there,

01:04:45   and probably the best way to do that

01:04:47   is for the existing communities to keep just growing.

01:04:52   And as this Swift on Server community grows,

01:04:56   and more and more people are successful building and deploying

01:04:59   server apps in Swift, I hope that naturally more and more

01:05:02   people will become aware of that effort,

01:05:04   will then find out about Swift, maybe try it out,

01:05:08   find out that it's actually really great.

01:05:10   and if it's not really great, let us know

01:05:12   so that people can fix whatever the problems are

01:05:15   and then just kind of grow out.

01:05:17   But I'm actually perfectly okay with it growing

01:05:19   a little bit slower than it has been.

01:05:21   (laughing)

01:05:23   - So John asked about the span between basically

01:05:26   low-level systems programming

01:05:27   and high-level applications programming.

01:05:29   I'm also curious that it seems like the Swift team/Apple

01:05:33   have presented Swift as not only spanning that wide range,

01:05:37   which seems impossible,

01:05:39   but also spanning a wide range of skill levels

01:05:41   of programmers.

01:05:42   So there's the Swift Playgrounds app on iPad

01:05:45   where you have total novices writing Swift

01:05:47   as their first language,

01:05:48   all the way up to people writing systems level things

01:05:52   and complicated apps who are very experienced programmers.

01:05:56   Do you think, is it possible for a language

01:06:00   to do all of these things well?

01:06:02   And if so, do you think Swift has achieved that?

01:06:05   - So I do think it's possible.

01:06:08   I think it has achieved it for the things

01:06:10   that it's doing so far, and I think the challenge is

01:06:13   that as new capabilities get added

01:06:15   that it doesn't jeopardize that.

01:06:17   But knowing the folks involved

01:06:20   and the source compatibility guarantees

01:06:22   and everything else like that,

01:06:23   I'm pretty sure that won't be a problem going forward.

01:06:25   Here's the way I look at it.

01:06:27   Swift, you will never, or you're unlikely to run

01:06:30   to anybody that says that Swift is a simple language, right?

01:06:34   Swift is a complicated language.

01:06:36   It's not simple in the sense that scheme is simple, for example.

01:06:40   It's also not simple in terms of when you talk to an Objective-C developer, they'll

01:06:44   often claim that Objective-C is simple, ignoring all the C parts.

01:06:48   I would never claim that for the record.

01:06:50   Right?

01:06:51   So C itself is a very complicated, weird language.

01:06:55   It's just that people don't typically use the weird parts, right?

01:06:59   And so they perceive C as being very simple.

01:07:04   So the way I project this onto Swift is that the secret to Swift and being easy to learn,

01:07:11   easy to use as a teaching vehicle, but also powerful enough to solve the problems that

01:07:17   need to be solved is that the complexity inherent in the language needs to be progressively

01:07:21   disclosed.

01:07:23   So imagine if some day Swift had inline assembly support, for example.

01:07:27   Only really low-level systems people or really bit-twiddling assembly programmers would use

01:07:32   this feature, everybody else would ignore it, and it would not increase the apparent

01:07:36   complexity of the language to people who didn't know what it was.

01:07:39   For a feature like that, the most important thing is to make the syntax clear so that

01:07:43   when you run up into it, you discover somebody else's code, you know that you don't know

01:07:48   what it does.

01:07:51   And so you say, "Oh, that's interesting.

01:07:52   I don't know what that is."

01:07:53   And then you can do a search and find out, find the Stack Overflow article, whatever

01:07:58   it is, to say, "Explain what this is to me."

01:08:00   And then you can say, "Oh, okay, I get it, and I either care or I don't."

01:08:03   But at that point in time, you can then dive in and learn more information.

01:08:08   Assembly is never something that a Swift playgrounds person working through Learn to Code 3 would

01:08:12   ever want to know about.

01:08:16   And I think that is really one of the secrets to Swift's success in terms of getting people

01:08:21   on board and being really approachable for people at all levels is that, just like in

01:08:27   In Python, you can start with just print hello world.

01:08:29   You can do the exact same thing in Swift.

01:08:31   And with Swift, you don't need the slash end on your string.

01:08:34   It's really just print hello world.

01:08:37   And from there, you can then introduce new concepts.

01:08:39   You can grow it out over time.

01:08:41   And this really allows people to understand

01:08:44   either the syntax of language

01:08:46   or the conceptual programming things

01:08:49   that they're learning as they go.

01:08:50   And the design of Swift is really geared around that.

01:08:54   And so what that means,

01:08:55   if you project on a system's programming features,

01:08:58   comparing Swift to Rust, for example,

01:09:00   I think it's very likely that Swift will get features

01:09:03   for memory ownership control,

01:09:05   which will allow really, really high performance,

01:09:08   it will allow solving performance problems

01:09:10   with Arc, for example.

01:09:12   But unlike Rust, we can't make that be a core part

01:09:15   of the type system that everybody has to use.

01:09:17   It has to be something that sufficiently smart programmers,

01:09:21   when they're solving a specific performance problem,

01:09:24   end up using or an embedded kernel programmer might want to use, but an application developer

01:09:29   can completely ignore.

01:09:31   And so that's really the challenge is it's deploying similar type system mechanics and

01:09:36   other low-level language geekery to the problem, but do so in a way that is tasteful and allows

01:09:42   most normal people to just completely ignore it.

01:09:45   Everything you just said kind of reminds me of a saying I once heard that you're free

01:09:49   to adopt for Swift if you would like, which is make easy things easy and make hard things

01:09:53   possible.

01:09:54   We're sponsored tonight by Audible.

01:09:57   With an unmatched selection of audiobooks, original audio shows, news, comedy and more,

01:10:02   get a free 30 day trial at audible.com/ATP.

01:10:06   If you want to listen to what Audible has, you can listen to audiobooks from virtually

01:10:09   every genre anytime, anywhere.

01:10:12   You can play Audible's audiobooks on phones, tablets, computers, even kindles and iPods

01:10:16   if you still have them.

01:10:18   Audiobooks are great for flights, long road trips, or even your daily commute.

01:10:22   You might think you don't have time to read books,

01:10:24   but you'd be surprised how many audiobooks

01:10:26   you can hear each year,

01:10:27   even only listening to and from work every day,

01:10:29   'cause that time really adds up.

01:10:31   Audiobooks bring books to life.

01:10:33   Many of them are read by authors themselves,

01:10:35   which adds an extra dimension to the text.

01:10:37   And with Audible, you can take risks

01:10:39   and try new authors without regret,

01:10:41   because Audible offers their great listen guarantee.

01:10:44   If you start an audiobook and don't like it,

01:10:46   you can exchange it for another one for free.

01:10:49   So check it out for yourself.

01:10:50   You can see and listen.

01:10:52   When you begin your free 30 day trial,

01:10:54   you get your first audiobook for free,

01:10:56   and there's no stress and no obligation

01:10:57   'cause you can cancel your Audible membership at any time.

01:11:00   So with audiobooks and spoken word audio product,

01:11:03   you will find what you're looking for.

01:11:04   Get a free 30 day trial by signing up at audible.com/atp.

01:11:09   That's audible.com/atp.

01:11:12   Thanks to Audible for sponsoring our show.

01:11:14   - So Chris, you brought up just a second ago

01:11:21   how simple Python's hello world is.

01:11:23   And one of the things I've wondered about Swift

01:11:26   is it seems to some degree,

01:11:29   like it's kind of the, what do you call it?

01:11:31   The Rorschach test of languages in that I came to Swift

01:11:35   a sort of kind of via Objective-C,

01:11:37   but my day job was as a C# guy.

01:11:40   And I see, to my eyes anyway,

01:11:42   and I hope you don't find this insulting,

01:11:43   but I see a lot of C# in Swift.

01:11:47   And I've heard JavaScript people again,

01:11:48   I hope that's not insulting,

01:11:49   "Oh, I see some JavaScript in here."

01:11:51   And I presume that John could say that he sees Perl in it.

01:11:54   I presume Marco could say that he sees PHP in it.

01:11:56   And again, hopefully that's not insulting.

01:11:57   - I see Go in it.

01:11:58   I don't see any PHP in it.

01:12:00   - Okay, fair enough.

01:12:01   You get what I'm driving at, though.

01:12:02   And so, I guess what I'm asking, Chris,

01:12:05   is obviously there was a huge Objective-C influence in Swift,

01:12:08   but was there any one or maybe just a couple

01:12:11   of other languages that you feel

01:12:12   really, really inspired Swift?

01:12:14   Or do you really think it's the melting pot language

01:12:17   that one would always hope to create?

01:12:20   - I think it really is a melting pot,

01:12:21   because we weren't, so the goal of Swift

01:12:24   isn't to ape some other language.

01:12:26   The goal of Swift is to just be great, right?

01:12:28   - Right, right.

01:12:29   - And so you can take, I think that Swift looks,

01:12:33   or I and the other people in the core team,

01:12:35   the other people working on Swift

01:12:37   have looked at many, many other languages.

01:12:40   If you're a Haskell nerd,

01:12:41   there's tons of Haskell concepts built in.

01:12:44   and protocols really are just like a very similar

01:12:47   Haskell construct, for example.

01:12:49   And so it's really about taking the best ideas

01:12:53   from where we can get and assembling them together.

01:12:56   And one of the major goals of Swift

01:12:57   is for it to be familiar feeling, right?

01:13:00   Because if it's familiar feeling,

01:13:02   that makes it easier for people to pick up

01:13:04   and they're not fighting unnecessary barriers

01:13:08   to just get in the way of adoption.

01:13:10   And so it being familiar is actually success in that way.

01:13:15   And it's not a result of Swift trying to be Go or C# or whatever.

01:13:21   It's about taking the best ideas from them and assembling them together.

01:13:25   And I think that you could probably pick a language,

01:13:27   and there's some good idea that came from them,

01:13:30   including D or Dart or Go or whatever.

01:13:35   I mean, Swift does really draw from many, many different sources,

01:13:39   and it's really hard to really tease them all out.

01:13:44   - So the question that Casey wrote for me

01:13:46   to ask you right now is--

01:13:47   - Whoa, whoa, whoa, how do you know that was me?

01:13:50   - That's definitely you.

01:13:51   Is why should I give a shit about Swift right now?

01:13:55   And I think I'm gonna modify this a little bit.

01:13:57   (laughing)

01:13:58   - That was written for you, my friend.

01:14:00   But yes, that is how it was written.

01:14:01   - Definitely by you, right?

01:14:02   I figure that's not quite John's style.

01:14:04   - No.

01:14:05   But as somebody who was just dipping a toe in Swift

01:14:10   as of 12 hours ago, and has waited this long,

01:14:15   Objective-C faithful/holdouts/lazy people

01:14:18   who don't like learning new things very quickly,

01:14:20   what's kinda like the sales pitch for adopting Swift now?

01:14:24   - I guess two different answers,

01:14:27   one of which is you don't have to adopt Swift.

01:14:29   I don't think Objective-C's gonna go away anytime soon.

01:14:33   Apple still supports C and C++,

01:14:34   and it doesn't have any specific,

01:14:37   there's no obvious benefit of dropping Objective-C,

01:14:41   as well as obviously they have a ton

01:14:42   of Objective-C code themselves.

01:14:43   So I don't think that there's any reason

01:14:46   you have to adopt Swift.

01:14:48   Swift just tries to be a better answer

01:14:51   so that you'll want to adopt it.

01:14:53   And in terms of why,

01:14:55   Swift in its name kind of is,

01:14:58   connotes a whole bunch of different things,

01:15:00   including performance, but really to me,

01:15:02   the most important aspect of it is

01:15:04   programmer productivity.

01:15:06   The idea that Swift is really optimizing for

01:15:08   is not letting you pound out the code as fast as possible.

01:15:11   It really is designed and optimized for,

01:15:15   as a programmer, you can spend the least amount of time

01:15:17   to get to a working program as fast as possible.

01:15:21   And so getting to a working program

01:15:23   includes the time it takes to debug something,

01:15:25   includes the time it takes to iterate and develop

01:15:28   and fight the type system

01:15:29   and all the other things that you have to do.

01:15:31   but that time you spend having to fight the type system

01:15:35   or figuring out optionals or things like that

01:15:38   pays itself back because your program works more often.

01:15:41   And so you're actually not spending time

01:15:43   chasing down dangling pointer bugs,

01:15:45   or in the case of Objective-C,

01:15:49   you get an unrecognized selector error,

01:15:51   whatever those kinds of bugs are.

01:15:54   And Swift tries to help you by the language guiding you

01:15:57   and helping design things.

01:15:59   Swift also has a lot of things

01:16:00   that just make common things easier.

01:16:02   So you can switch on a string, for example,

01:16:04   and then match the different cases.

01:16:06   You can use enums, which are a super,

01:16:09   enums are just from the language geekery world,

01:16:12   they're just algebraic data types.

01:16:14   They're in tons of different functional languages.

01:16:17   They're not novel by any means, but they're so useful,

01:16:20   and they solve so many problems just out of the box,

01:16:22   and just having them at your fingertips is great.

01:16:25   So there's a lot of things about Swift,

01:16:27   and it probably depends on who you are,

01:16:29   what your experiences are.

01:16:31   One of the problems I've seen with people moving

01:16:32   from Objective-C to Swift initially

01:16:34   is that they tend to write Swift code

01:16:36   just like they wrote Objective-C.

01:16:38   And while that's a really good way

01:16:39   to maybe migrate an application over

01:16:42   or to get familiar with Swift,

01:16:44   it really means that you're missing

01:16:45   a lot of the value in Swift.

01:16:47   And I think that that's okay.

01:16:49   It just, it means that, you know,

01:16:51   an Objective-C program we're going to Swift

01:16:53   first starts out by saying,

01:16:55   I don't see what the big deal is.

01:16:56   And only after they spend some time in it

01:16:58   they start to realize they are more productive, they do feel better, they reach for things

01:17:03   that they otherwise wouldn't have. And I think it's really interesting to talk to people

01:17:08   that have done, for example, a year of Swift programming, but then have to go back to Objective-C.

01:17:13   And to me that's the really interesting thing. So what was your experience?

01:17:18   It felt absolutely archaic. And granted, I like to think of myself as a nice guy, and

01:17:23   so I'd probably say something like that even if it wasn't true, but the reality of the

01:17:26   situation is, it felt just so old. It just felt old. And I don't know, I wish I could

01:17:33   quantify that better, but it just felt like I was back in time in a way that didn't feel

01:17:39   good. And in some ways it was kind of nice. So I do like optionals. I understand why they're

01:17:46   a thing. I am all in on it. But at the same time, there are times when I have to do a

01:17:51   a guard lead or whatever the case may be that I really would just like to move on with my

01:17:55   life.

01:17:56   And so not having to worry, being able to be a little more cavalier was kind of nice,

01:18:02   but the reality of the situation is, as you've said earlier, is that that's a potential hazard

01:18:07   down the road.

01:18:08   And that's why I like the way that you and the team have set up the type system in Swift.

01:18:13   But gosh, going back to Objective-C is so frustrating for me because it just feels like

01:18:18   I'm going back in time, like I'm going backwards.

01:18:20   Yeah, and I think the challenge that Swift faces is because its focus is on building

01:18:27   programs that work and that can be maintained and all the other things that we care about

01:18:32   for large-scale software, it's maybe not the best solution for "I want to pound out a quick

01:18:40   script, use it once, and then throw it away."

01:18:42   Because in that case, you don't care about maintenance.

01:18:45   You can fit all the code in your head.

01:18:46   You don't care about good documentation or the other things that Swift encourages.

01:18:51   And that's a case where having a dynamic type system can be really liberating.

01:18:58   And so, you know, maybe that'll be a challenge for some people.

01:19:01   But I think that as Swift gains ecosystem and gains libraries, its other advantages

01:19:06   will be so great that hopefully it will be a good solution for those kinds of tools as

01:19:11   well, those kinds of scripts as well.

01:19:14   So a minute ago you mentioned how Objective-C programmers, people like me who are new to

01:19:19   Swift, tend to write Swift like Objective-C. And that's a concern I've had, and it's

01:19:25   one of the reasons that I have procrastinated adopting Swift up till now, because I have

01:19:31   a pretty good grasp on Objective-C now, and I write Objective-C code that I know is basically

01:19:39   idiomatic and soundly designed. Like I write code in the style of what I think Apple's

01:19:46   code would look like based on the little bit of, you know, headers and stuff that we see.

01:19:49   I feel like I write good objective C code that is kind of correct and idiomatic sound.

01:19:54   With Swift, you know, I assumed that the idioms would not yet be developed for a while and

01:20:01   established for a while. And so I didn't want to write a bunch of bad Swift code or

01:20:07   like incorrect or weird Swift code,

01:20:10   you know, investing heavily in it so early on.

01:20:13   Do you think that it's at a point now

01:20:15   where the idioms are starting to get worked out enough

01:20:18   that that's less of a concern now?

01:20:21   - Yeah, I do.

01:20:22   So I think it's definitely fair to say

01:20:24   that in the Swift one, the Swift two timeframes,

01:20:27   Swift as a language was changing really rapidly

01:20:29   and I could see why you'd feel like you're on uneven footing

01:20:33   and not really sure what the language is,

01:20:34   much less what the idioms are.

01:20:37   Swift 3 really is quite well baked out,

01:20:40   and so I expect that going forward,

01:20:41   the new things are gonna be additive.

01:20:43   They're not gonna be changing the existing patterns.

01:20:46   And so I think the Swift community in general

01:20:48   has gone through the same kind of thing

01:20:50   that you're feeling there where it's not really clear

01:20:53   the one right way to solve the problem,

01:20:55   and maybe there are different good ways to do it

01:20:58   with different trade-offs that weren't clear to people.

01:21:01   But I think people are starting to understand that now.

01:21:04   There are a few style books that are being written

01:21:06   by people that I've heard about.

01:21:08   And so when those come out, those will hopefully be good

01:21:10   and those will be a good resource.

01:21:12   But another thing to keep in mind is that Swift

01:21:17   is opinionated, I guess, is the way to say it.

01:21:20   So it really does encourage you to do the right thing

01:21:23   where it can.

01:21:24   And so for example, if you use var for everything,

01:21:28   the Swift compiler will say, hey, you mark this as a var,

01:21:33   but it could be a let.

01:21:34   and that's just its subtle way of,

01:21:36   and let me fix it for you, right?

01:21:38   And that's just its subtle way of encouraging you

01:21:40   to use immutable values, which is a very small thing,

01:21:44   but it's just kind of pushing you in the way

01:21:46   that it thinks leads to better code.

01:21:50   And immutability for a local variable

01:21:51   doesn't matter that much,

01:21:53   except that it communicates something more

01:21:54   to the person you asked to read and maintain your code.

01:21:57   And so I think that Swift really does kind of encourage you

01:22:00   down the right lines in some ways.

01:22:03   But on the other hand, in other places where you're saying,

01:22:05   hey, should something be a class or should it be a struct?

01:22:08   The trade-offs are more nuanced and it's a harder thing

01:22:10   and the Swift compiler can't just know what problem it is

01:22:13   that you wanna solve.

01:22:14   And so it can't help you with that.

01:22:16   - So you mentioned Swift style guides before.

01:22:19   As a creator of a language,

01:22:22   how much influence do you feel like you want to have

01:22:28   over things like style?

01:22:30   Things that really are,

01:22:33   It's not features, it's not technical, it's just like, you know, we all know different

01:22:37   style things like, oh, you know, you should only have one exit at the bottom, or you should

01:22:42   exit early, or I mean, like, there are things you can do, even things like spacing and brace

01:22:47   style for crying out loud, or, you know, or just the sort of idioms of like this little

01:22:51   three line sequence is how you do this transformation on this data structure.

01:22:55   You mentioned, you know, language features can influence that, so obviously as language

01:22:58   designer and participating in that process you can effectively guide the community style-wise

01:23:05   in one direction or another.

01:23:07   But eventually you come to the stuff that's just plain opinion and style.

01:23:11   And several other languages have had fairly concrete styles set forth early on by the

01:23:17   creators in order to go to like KNRC style type things.

01:23:21   How much do you care about being able to influence the, I guess the personal preference or the

01:23:27   aesthetic portions of style that are outside the things that you can influence as part

01:23:33   of language design.

01:23:35   So as with any programmer that has a pulse, I have my preferred style.

01:23:42   And so clearly that's the right way.

01:23:44   Naturally.

01:23:45   Naturally.

01:23:46   Well, so I guess more seriously, the language itself does influence some of the things you

01:23:51   mentioned.

01:23:52   So for example, it's my personal opinion that the style where you have a single entry

01:23:57   in a single exit from every function.

01:23:58   I think that leads to really difficult

01:24:00   to maintain and read code.

01:24:01   And that's one of the things that led

01:24:03   to the guard statement existing.

01:24:05   The guard really does encourage you to use early exits

01:24:08   so you handle the exceptional cases

01:24:09   and then you don't have to worry about them.

01:24:11   So that's an example of where the language design

01:24:14   is kind of encouraging you to, you know,

01:24:17   have multiple returns from a function.

01:24:19   Other more subjective things like the number of spaces.

01:24:22   I personally am a fan of two-space indents.

01:24:25   I know some people are staunchly forced,

01:24:27   Other people are staunchly eight.

01:24:28   Some people think 80 columns is the right answer, right?

01:24:30   I mean, all these things are,

01:24:32   there are actually really good arguments on all sides.

01:24:35   Some people argue that you should use three-space indent

01:24:38   because then you certainly can't have tabs in your file.

01:24:40   - Wow.

01:24:42   - So this is where it comes down to

01:24:45   you have to pick your battles, right?

01:24:47   And people will disagree for a long time,

01:24:50   and you can make arguments on both sides,

01:24:53   but where we've come down is that

01:24:56   it's just more practical to let people write code

01:24:59   they like to look at.

01:25:00   And that comes at a cost of if you switch between teams

01:25:03   or you pick up somebody else's package,

01:25:05   then maybe it's indented the wrong way.

01:25:07   But I don't think that really actually actively hurts

01:25:11   the comprehensibility of the code.

01:25:14   That's merely annoying.

01:25:15   And having something like Go format,

01:25:19   which rigorously enforces the one true way,

01:25:21   I think would have been nice.

01:25:23   It just wasn't a priority early on.

01:25:24   and it also just wasn't a battle that we were willing to tackle.

01:25:27   And I don't know, we'll see. I think this is still also an open question in terms of

01:25:32   what other tooling gets built and what other things come into the fray, because

01:25:37   it would be great to have better tooling around this. It just hasn't been built out yet,

01:25:42   and it's a great opportunity for open source as well.

01:25:44   I was thinking about the sort of doomsday scenario where one of these Swift style guide books comes

01:25:49   out and it makes some blanket recommendation that you should always use protocols for this

01:25:57   and you should never use classes for that or whatever. And it becomes wildly popular

01:26:00   and accepted as the Bible of how you write Swift programming and you're just somewhere

01:26:05   shaking your head and going "No! You got it all wrong!" But I guess we'll cross that bridge

01:26:10   when we come to it. I think at this point the language design itself and the community

01:26:14   has had enough influence that that's not likely to happen. But I guess what I was getting

01:26:17   at is do you feel like you want to write a Swift style guide? Like if you had unlimited

01:26:21   time?

01:26:22   No, I don't think that would be a good use of my time. But if I had unlimited time, maybe.

01:26:26   I don't know. It's hard to answer that theoretical question. But also, to your concern about

01:26:32   somebody came out with a style book that was so wrong that would cause me to be really

01:26:37   unhappy, I actually have a ton of faith in the Swift community because if something came

01:26:41   out that was so weird, I don't think that the community overall would accept it. The

01:26:47   The community has, again, just kind of blown me away with how

01:26:51   clueful they are and how many great people have gotten

01:26:54   involved with Swift and Swift evolution side of things.

01:26:57   And it's been really amazing to see these people,

01:27:00   they go through their own personal trajectory

01:27:04   on the Swift mailing list where,

01:27:06   initially they're saying, hi, I had this idea,

01:27:09   what do you think?

01:27:10   And the response is, no, that's a terrible idea

01:27:12   for this reason.

01:27:15   But then they come back and they're like,

01:27:16   "Hey, how about this?

01:27:17   "Did you ever think about this?"

01:27:18   And it was like, "Oh, well that's interesting.

01:27:20   "That almost worked, but it didn't work because of that."

01:27:22   And then they come back and they say,

01:27:23   "Hey, well what about this?"

01:27:24   And we say, "Well, we actually tried that

01:27:26   "and we had that for a while and then had to back out

01:27:28   "and change it this other way,

01:27:29   "because we didn't even think about this other thing."

01:27:31   And then the next day, they're the ones saying,

01:27:33   "This is the way it needs to go."

01:27:35   And everybody says, "You're right, you should do that."

01:27:38   And it's really hard for people

01:27:40   that haven't been involved in the overall design

01:27:43   of anything as complicated as Swift,

01:27:46   to be able to discern the difference

01:27:47   between something that is the way it is

01:27:51   out of an intentional decision process,

01:27:53   or the way it is as an accident of history.

01:27:57   And so as now that the design process is public,

01:28:00   I think that it becomes a lot easier for people to tell that

01:28:04   and it's very easy for people

01:28:06   to kind of understand that difference.

01:28:10   The one big debate that I haven't actually seen

01:28:12   is why is the func keyword the func keyword?

01:28:15   And that's one that luckily we're now beyond

01:28:18   the Swift 3 source compatibility threshold.

01:28:21   So we just can't have that discussion anymore.

01:28:23   I think that would be great.

01:28:24   - Darn.

01:28:26   - One of the best things that the Swift open source thing,

01:28:28   the whole evolution process has is that like the list

01:28:32   of questions, like the asked and answers questions,

01:28:34   like this is a commonly asked question

01:28:36   and we've dealt with it before

01:28:37   and you're probably gonna wanna ask it too.

01:28:38   So here's how it was asked before

01:28:40   and here's what the answer is.

01:28:42   Not that everybody's gonna go and see that,

01:28:44   but I love that that exists.

01:28:45   - Well, and it's also hilarious that that started out

01:28:47   as the commonly proposed list,

01:28:49   and then at some point it became the commonly rejected list.

01:28:52   - Yeah, right, 'cause if it's commonly proposed,

01:28:54   obviously it's not getting through,

01:28:56   and so you have to go to the commonly rejected list.

01:28:58   If you're thinking about asking to change func to fn,

01:29:01   I know you talked about this before,

01:29:04   but it's worth touching on again,

01:29:06   because many people have asked me to ask you this.

01:29:12   Swift and a Rust-style memory model.

01:29:14   You phrased it before as an add-on feature for people

01:29:19   who know that they need that type of thing,

01:29:21   but that it would not-- like, that Swift wouldn't become

01:29:24   a language in which all memory is managed that way.

01:29:26   Instead, this would be a special purpose

01:29:28   feature for particular roles.

01:29:29   What roles do you think it's suited for,

01:29:34   and why is it not the right memory model for all of Swift?

01:29:39   Well, so here's the way I look at Swift

01:29:42   in terms of memory management today.

01:29:43   So Swift is using Arc, it's not using GC.

01:29:46   If you want to talk about the trade-offs there,

01:29:47   I'm happy to do that.

01:29:49   That's its own rat hole we can fall into.

01:29:51   Arc, I think, is overall an amazing default for Swift

01:29:56   because it gives you deterministic destruction,

01:29:58   it gives you relatively predictable performance,

01:30:01   and the Arc optimizer is able to eliminate

01:30:04   most of the reference counting operations that happen.

01:30:08   The problem that I see with ARC as of today,

01:30:12   or say Swift 3, is that it is not a very controllable model.

01:30:17   And so if, for example, you have an inner loop

01:30:22   and it turns out the ARC optimizer

01:30:24   is doing a bunch of retains and releases,

01:30:26   and you know that they're not necessary

01:30:28   because you know the objects are alive,

01:30:30   there's nothing that you can really do

01:30:32   to solve that problem,

01:30:34   unless you're willing to drop down to something

01:30:36   like the unsafe operations that Swift gives you

01:30:38   for manipulating references to objects.

01:30:41   And so it's really kind of dissatisfying to me

01:30:44   to have a really safe, great memory model

01:30:47   that for performance reasons,

01:30:48   you have to drop down to unsafety, right?

01:30:50   This is a huge cliff,

01:30:52   and it's also a huge complexity cliff

01:30:54   that you have to drop into to solve that problem,

01:30:57   and that's not really great.

01:31:00   So the promise, the dream, is to instead say,

01:31:02   "Hey, well, if you are a sufficiently advanced programmer

01:31:05   and you know how this stuff works,

01:31:07   well, we can give you a new option.

01:31:09   Instead of dropping down to unsafe constructs,

01:31:12   you can actually just use more static type information

01:31:15   in annotations in your code.

01:31:17   And so you add a few annotations to say,

01:31:20   hey compiler, this is okay.

01:31:22   The compiler can then validate those type annotations

01:31:24   and check to make sure they're correct

01:31:26   so it's still memory safe, it's still guaranteed to be okay.

01:31:29   But you're paying for it in terms of more

01:31:31   of this annotation in the code

01:31:33   and it's more heavyweight in terms of coding.

01:31:36   But what you get out of that is the guarantee

01:31:38   that no ARC operations are happening.

01:31:41   Once you get to that model,

01:31:42   then it becomes really interesting because you can say,

01:31:44   "Hey, well, in this inner loop, I'm going,

01:31:46   I found in my profiler that it really does matter

01:31:48   for performance and the ARC optimizer

01:31:50   is doing the wrong thing.

01:31:51   Well, I can add a few local annotations

01:31:53   and now the code is fast, it's guaranteed to be fast,

01:31:56   and the clients of my code don't have to know about it."

01:31:59   Right, this is an implementation detail.

01:32:01   And I think this will really bring us

01:32:02   to the best of both worlds where you can have memory safety,

01:32:06   you can have a progressively disclosed complexity system

01:32:11   where most people don't have to know about it

01:32:12   or think about it, but you can get

01:32:14   to really low-level performance guarantees

01:32:17   that otherwise aren't possible.

01:32:18   And once we do this, I have a feeling

01:32:20   that there'll be certain communities of people

01:32:22   that will only wanna work in this model.

01:32:24   And these are the communities that like Rust predominantly.

01:32:28   So if you're writing a kernel, for example,

01:32:30   maybe you don't wanna have a reference count

01:32:31   your object at all.

01:32:33   And maybe you just want to have, you know,

01:32:36   you say I will always use these annotations

01:32:38   in my code pervasively.

01:32:39   And if that happens, then there's a couple of options

01:32:42   that we can investigate.

01:32:43   We could say, hey, well if you mark this class

01:32:45   with some attribute, then that prevents the compiler

01:32:49   from ever doing reference counting,

01:32:51   and if it would ever do that, it just raises an error.

01:32:53   Or we could even theoretically have a language dialect mode

01:32:56   that said, hey, produce an error

01:32:58   anytime it did an arc operation.

01:33:01   I don't like language dialects,

01:33:02   and so we'd have to find a way to handle that.

01:33:05   Maybe it would be a warning,

01:33:06   and then they would upgrade it to an error

01:33:08   or something like that,

01:33:08   but I could imagine doing something like that.

01:33:11   And once we do that,

01:33:12   then I think you get to a really interesting mode

01:33:14   where those systems programming type people

01:33:19   that otherwise would be using C or C++ can now use Swift,

01:33:22   and that means they only have to learn one language.

01:33:25   That means that they could use the same toolset,

01:33:27   that the IDE and everything else,

01:33:29   that works great with Swift.

01:33:32   It means that they can scale and use the same language

01:33:36   for different layers of their stack

01:33:38   because many applications have very low-level pieces

01:33:41   and very high-level pieces,

01:33:42   and having them written in different languages

01:33:45   is really kind of gross.

01:33:46   I mean, I think we've seen this

01:33:48   in the Objective-C community where one of the best

01:33:51   and most annoying things about Objective-C

01:33:52   is that it has C in it, right?

01:33:55   And so this has been hugely important

01:33:56   for Objective-C in practice

01:33:57   because if you run into a performance problem

01:34:00   with obviously message send,

01:34:01   you can always rewrite that algorithm in C.

01:34:04   And that's really, really, really important

01:34:06   for Objective-C being successful,

01:34:08   and both in the days of Next on 16 megahertz processors,

01:34:13   but also today for the low-level code

01:34:15   that people are writing.

01:34:17   But it also means that that's one of the problems

01:34:20   that makes it so that Objective-C

01:34:21   and C are so tightly intertwined,

01:34:22   and so you can't actually take the C part

01:34:25   out of Objective-C without producing a different language.

01:34:28   - Or waiting for Swift in the web browser,

01:34:30   'cause it's your only escape to begin of applications

01:34:31   that have to have one language at the higher levels

01:34:33   of a different language than the lower one.

01:34:35   That's a tough one.

01:34:36   - Well, that I think is a frontier

01:34:39   that is probably the biggest payoff

01:34:41   because replacing JavaScript would be such an amazing

01:34:44   service to the world.

01:34:45   (laughing)

01:34:49   - You just mentioned Dart before, it's been tried.

01:34:51   - Yeah, but it's been tried and that's where, you know,

01:34:54   I'm putting my hope on the ASM.js, the WebAssembly,

01:34:57   those kinds of efforts where it's enabling languages

01:35:01   like Swift and Swift compiles through LLVM.

01:35:05   WebAssembly and ASM.js both have LLVM backends

01:35:07   and principles so they could wire up Swift to one of those

01:35:10   and go to town with it.

01:35:11   If those end up winning and they become big things,

01:35:19   then maybe that'll be good enough.

01:35:20   But I don't really know.

01:35:21   I don't have, my crystal ball doesn't go out to the point

01:35:24   where JavaScript is not in web browsers.

01:35:26   - Yeah, that's the difficult part.

01:35:28   It's not the language mechanics.

01:35:29   It's the getting something that can understand that

01:35:32   in front of as many people as possible.

01:35:34   - Well, it's also very interesting to me.

01:35:36   So, and again, I'm not a web developer

01:35:37   and I'm definitely not an expert in the space,

01:35:40   but to me it seems that the trajectory of JavaScript

01:35:44   has basically made it into an intermediate language.

01:35:48   It's not something that developers are writing as much

01:35:50   directly as they used to.

01:35:52   And so I see TypeScript and a lot of other languages

01:35:54   that now compile down to JavaScript.

01:35:56   And they're really using JavaScript

01:35:59   like a bit code representation,

01:36:01   not a source language that people

01:36:03   are thinking about as much anymore.

01:36:05   And so I wonder if in five years,

01:36:07   the natural conclusion of that is that JavaScript

01:36:10   is just an asm.js type of thing,

01:36:12   or maybe WebAssembly does take over.

01:36:14   But again, I'm not the expert.

01:36:17   I don't know where that direction will go.

01:36:19   I know that some people love JavaScript.

01:36:21   So we'll see.

01:36:23   On the topic of using languages other than JavaScript

01:36:27   to write JavaScript, I have to say,

01:36:29   having done that several times, the tooling-- boy,

01:36:32   the tooling is not quite where you'd

01:36:34   want it to be in terms of being able to write and debug

01:36:38   and profile in the preferred language

01:36:41   and not in the compile down to JavaScript type language.

01:36:45   But yeah, maybe that'll be like stage 17 in the Swift world

01:36:48   domination plan.

01:36:49   - Well, and I think that's always been true

01:36:51   for preprocessors.

01:36:52   So, I mean, even in C, if you do crazy things

01:36:55   with the macro preprocessor in C,

01:36:57   you get debugging those things that are so horrible.

01:37:01   - Yeah.

01:37:02   - And that's one of the reasons that we've been careful

01:37:04   about not adding a macro system to Swift early.

01:37:08   It just brings lots of interesting trade-offs

01:37:09   in terms of the debugging and developing

01:37:11   and designing experience.

01:37:14   - So one last thing on ABI compatibility.

01:37:18   According to the timelines that I've heard sketched out,

01:37:22   ABI stability could be a thing before async or concurrency

01:37:29   stuff lands in Swift.

01:37:31   Is there any dependencies or chicken-egg things

01:37:34   involved in there?

01:37:36   In other words, do you have to nail down

01:37:39   some aspects of your concurrency model

01:37:41   before you can commit to ABI stability,

01:37:43   or are they totally orthogonal?

01:37:44   I think they're totally orthogonal.

01:37:46   I think the memory ownership model has more of an impact on ABI stability because there's

01:37:52   some very low-level things like how the getters and setters are code-generated for a property,

01:37:59   for example, that end up getting impacted by the ownership model.

01:38:04   That's one of the reasons that the Swift team is actually actively designing and working

01:38:10   on a proposal for the memory ownership stuff right now.

01:38:13   It's not so that it can be a Swift 4 feature.

01:38:16   so that the ABI stability work can be done

01:38:19   in light of the ultimate model

01:38:21   for the memory ownership support.

01:38:24   And I think concurrency is not going to be something

01:38:28   that impacts ABI stability at all, but we'll see.

01:38:31   And if so, then the sufficiently smart programmers

01:38:35   that work on Swift will figure it out

01:38:36   and I'm sure it will be great.

01:38:38   I think it's also an interesting question

01:38:40   of whether ABI stability will be done for Swift 4

01:38:44   because it's a huge amount of work.

01:38:48   The work is well underway, of course,

01:38:50   but it's also not clear to me that's really

01:38:52   the most important thing for the Swift community.

01:38:57   And one of the things that Ted has been a huge champion for,

01:39:01   and I think he's right about,

01:39:02   is that the most important thing right now

01:39:04   for the Swift community is making the compiler more reliable,

01:39:07   making the error messages better,

01:39:09   making compile times faster,

01:39:12   and making it scale better to large projects.

01:39:15   And we'll see how the rest of the Swift 4 schedule goes,

01:39:19   but I wouldn't be surprised if at some point

01:39:22   they decide that focusing on that is more important

01:39:24   than nailing ABI stability in Swift 4.

01:39:27   - So you just mentioned Ted, that's Ted Kremenek,

01:39:30   who is now the lead of the Swift project, is that right?

01:39:34   - Yeah, he's the project lead.

01:39:35   So Ted has been managing the Swift and Clang projects

01:39:40   before that for a number of years.

01:39:42   He's been at Apple for 10 years now.

01:39:43   He's a Stanford PhD graduate.

01:39:47   He built almost single-handedly

01:39:50   the first ClangStack analyzer.

01:39:52   Yeah, that's Ted.

01:39:53   - I love that I'm saying this now.

01:39:57   As a Swift developer,

01:39:58   as we saw when you announced that you were leaving Apple,

01:40:04   we saw some of the people in the community asking,

01:40:06   should we be worried about Swift's future?

01:40:08   Is Swift in good hands now?

01:40:10   It seems like most of us didn't know Ted,

01:40:12   or at least didn't know his name,

01:40:13   or weren't familiar with his contributions.

01:40:15   It does seem like he's been doing quite a bit there anyway.

01:40:19   Should we be worried?

01:40:21   - I don't think you should be worried at all.

01:40:22   I think Swift is in amazing hands, as is, I mean,

01:40:25   all the things that I am leaving behind at Apple in quotes

01:40:30   are in really good hands, and that's one of the only reasons

01:40:32   I was comfortable in moving on.

01:40:35   In the case of Ted, Ted is a rock star.

01:40:38   He has been running the Swift team and managing them for,

01:40:43   I mean, four or five years now.

01:40:46   The roles that we had was that Ted owned and ran his team

01:40:51   and then reported to me.

01:40:52   And so I would mess around and cause trouble

01:40:56   by trying to get people to do the exciting,

01:41:00   important thing that I thought,

01:41:01   and maybe it didn't align with the actually important thing,

01:41:04   and therefore I'd introduce chaos into the world.

01:41:07   But Ted was always the stable rudder and the one that was really focused on getting the

01:41:12   important things done.

01:41:14   And he has a number of really exceptional engineers on the team, people on the core

01:41:18   team like Doug Gregor, John McCall, Joe Groff, Dave Abrahams.

01:41:22   These are all just amazingly brilliant people.

01:41:26   And also the team includes a bunch of other engineers that are equally dedicated and also

01:41:32   just totally amazing people to work with.

01:41:34   So the Swift team is, I think, one of Apple's biggest assets.

01:41:38   It's crazy how brilliant and dedicated they are to the project and how excited they are

01:41:43   to get to world domination one step at a time.

01:41:47   Coming back to kind of a more broad thing, let's say that—and this is not meant to

01:41:51   be a tongue-in-cheek reference to your next job.

01:41:54   This is just in general.

01:41:55   You know, you're at home, your kids are in bed, your wife is out or something like that,

01:42:01   and you want to just write some code.

01:42:02   you can't use Swift and you can't use Objective-C,

01:42:05   what are you writing code in?

01:42:06   And I know that's often dependent

01:42:07   on what project you're accomplishing,

01:42:09   but what's interesting to you these days

01:42:10   that isn't Swift and isn't Objective-C?

01:42:12   - Oh, well, so I mean, I have a ton of different interests.

01:42:16   I mean, I really love building ray tracers, for example,

01:42:19   and I've done a bunch of stuff with that.

01:42:21   And I guess if I couldn't use Swift for that,

01:42:24   then I would probably have to use C++.

01:42:27   - No! - So sorry.

01:42:29   - I was gonna call that,

01:42:30   I wanted to give you a chance to not say C++.

01:42:32   This is what I remind people when they mention it.

01:42:36   You know what LLVM's written in, right?

01:42:38   You write that much C++ and not have your answer be C++.

01:42:43   And do you know how much angst and personal suffering it causes to have to be writing

01:42:46   C++ all day and building a beautiful world for other people is just so unfair?

01:42:51   Yeah.

01:42:52   That's where you toil down in the mines.

01:42:54   Yeah, yeah.

01:42:55   It's a pain and suffering that's worth it for the bigger victory.

01:42:58   Well, that's where Swift comes from.

01:42:59   having to use C++, I could do the same stuff but not feel this much pain.

01:43:03   That's exactly right. I mean, there's a lot of suffering that led to Swift needing to

01:43:08   happen. But it also, it really depends. I mean, maybe if I was a crazy person, I'd use

01:43:14   Perl for something. I don't know if I'm that insane.

01:43:19   Well done. Well done. You'd never be able to read it, though. Nobody could.

01:43:23   Hey, if it's throwaway code, then you never need to read it, right?

01:43:29   >> I'll just wait for my Perl 6 grammars to land gently in Swift.

01:43:37   >> That is a great example of Perl really has nailed the string processing thing, even

01:43:42   in Perl 5, and I think Perl 6 is even better, and Swift has a lot to learn from it, and

01:43:47   that's something where Swift 4 is really learning from Perl, so I think that's great.

01:43:54   >> Please don't give him any ammunition.

01:43:56   This is terrible.

01:43:57   this interview so much until this very moment. Look at it this way. Once this happens, John

01:44:01   will have no excuse. Oh, he will find one. Nothing is so perfect that it can't be complained

01:44:09   about. Oh my goodness. This is a perennial topic on the Swift mailing list. It's about

01:44:15   dynamic features in Swift. Things that are quote unquote more dynamic in Objective-C and less so

01:44:24   in Swift. In the Swift community, there's a lot of angst about when, if ever, will Swift allow me to

01:44:31   essentially, you know, like what you said before, you can write Fortran in any language,

01:44:34   you can write Objective-C in any language. People will try to write their code in Swift,

01:44:40   but using models from Objective-C that require things like, you know, sending messages to objects

01:44:49   that you know will receive them, but the compiler can't guarantee, or, you know, having big

01:44:53   big heterogeneous collections where you're just like, "No, everything's ID and it'll

01:44:55   be fine." I don't even know how to frame this, but I think that the main question has

01:45:02   been are dynamic features possible in Swift, and are they coming in Swift? Or is there

01:45:09   some kind of philosophical divide where the most dynamic stuff that people really want

01:45:15   will never be forthcoming, not for technical reasons, but just for philosophical and safety

01:45:19   reasons?

01:45:20   So I've been pretty outspoken about this on the Swift evolution list, so hopefully this

01:45:24   isn't a huge surprise.

01:45:26   I don't think there's any tension between dynamic features and Swift.

01:45:32   A lot of people want to make hay and argue about how it would be impossible to do responders

01:45:38   or pick your feature in Swift.

01:45:44   The worst-case scenario, frantic blog posts I've seen are things that are along the lines

01:45:50   of someday Apple will rewrite all of its frameworks in Swift and then it will be impossible to

01:45:55   write responder chains and then bad things will happen and then we'll be back in the

01:45:59   days of MFC or some other bad thing.

01:46:02   Right.

01:46:03   Oh, God.

01:46:04   Don't even bring that up.

01:46:05   Exactly.

01:46:06   And so this is kind of quite the slope that the discussion ends up being.

01:46:12   I think this blew up most recently right before WWDC this year.

01:46:17   And it was really interesting to watch the blog post that people were flinging around

01:46:22   because everybody had a different idea of what dynamic meant.

01:46:27   And none of them really – so Apple's not going to counterblog somebody and like denounce

01:46:37   somebody's blog on somebody's post.

01:46:39   And it's kind of bad for them to do that.

01:46:41   But I thought it was very interesting and odd that none of those people actually came

01:46:44   to the Swift Evolution List, which is the right place to do that, and asked about it.

01:46:48   They all just wanted to make these inflamed blog posts of various kinds.

01:46:52   So if you get to my opinion, my opinion is that none of those are in tension with Swift's

01:46:57   current design. It's just a matter of prioritization. And the major problem that Swift has is, again,

01:47:04   there's so much work to do. There's concurrency model, there's actors, there's systems programming,

01:47:10   scripting, there's lots of little things that go in, there's better things to

01:47:15   support static analysis, introducing type state into the language.

01:47:18   There's pre and post conditions.

01:47:21   There are so many things that will be bricks in the house of Swift that we

01:47:26   want to build that need to happen, that it doesn't really make sense to spend a

01:47:32   lot of time building dynamic features so that Apple could theoretically someday

01:47:37   do something, right?

01:47:38   the Swift team is much more focused on the practical necessities of solving the real-world problems here and now in front of people.

01:47:45   And dynamic features, like many other things, will just kind of flop in place when the team has time to design and roll them out.

01:47:53   And so you will be able to someday—or I expect that you will be able to reflect over all the methods that a class has, for example.

01:48:03   So today even the Swift compiler is generating all the metadata so you can reflect over all

01:48:08   the data members and your values.

01:48:11   We just don't have an API wrapped around that.

01:48:13   But that metadata is what the Xcode memory heap viewer uses, for example.

01:48:19   And so there's a lot of that kind of stuff being put in place, but just hasn't had time

01:48:23   to fully bake out yet.

01:48:25   And when it does come in, I think it's going to be really exciting and we'll open more

01:48:28   doors for new kinds of patterns that people can do.

01:48:31   A lot of those will be familiar to Objective-C programmers, but they'll also be super useful

01:48:35   for things that people really haven't done in Objective-C.

01:48:39   So I don't see a lot of tension there, though.

01:48:41   It's just a prioritization question.

01:48:43   I think where people are coming from is in terms of prioritization, because if you're

01:48:47   used to doing things with certain sort of design patterns, broadly speaking, in Objective-C,

01:48:53   and you want to come and implement those same patterns in Swift and you find that you can't

01:48:57   you're lacking some feature, it feels like there's a barrier up.

01:49:00   And that's getting back to writing your Swift in Objective-C style, and that's more of a

01:49:04   barrier.

01:49:05   They retreat back to Objective-C because I can write it the way I want to write it, and

01:49:08   it works in Objective-C.

01:49:10   When I try to write it that way in Swift, it doesn't work for me.

01:49:12   Your choice is to change the way you write it to be a better fit for what Swift has,

01:49:16   or to go back to Objective-C.

01:49:18   I don't agree with that, though, because Swift does support all the features for dynamic

01:49:24   dispatch and method lookup and everything else that Objective-C does, it just requires

01:49:29   you to use the Objective-C subset of the language because it exposes it through the runtime.

01:49:34   Right. That's the tension, because they're like, "Oh, I want to write it in pure Swift,

01:49:39   as if there's something special and magical about not using Objective-C runtime for you."

01:49:44   You know what I mean? You do get a medal for that. Yeah.

01:49:47   I guess it makes some people feel good. I mean, there are—I

01:49:53   I can't really counter that, but I just don't think that it's actually fair to say you have

01:49:58   to fall back to writing Objective-C code.

01:49:59   Yeah, no, no.

01:50:00   I'm just trying to—I didn't write one of these blog posts, so to be fair, I'm trying

01:50:04   to express what I saw in them, because that was a lot of the concern was like they want

01:50:07   to do it the new way and the right way, and part of doing that is not at Objective-C-ing

01:50:13   everything and be like, "Oh, that feels like a compromise in the old way."

01:50:16   So they are setting their own goalposts for themselves arbitrarily to try to enter into

01:50:22   this new world. They want to jump in with both feet or not at all, and some of them

01:50:28   might end up bailing. But I think the way I look at that is an area where the language

01:50:35   is not fully baked out. It's not fully serving their needs, and I think that's really unfortunate.

01:50:42   I'm not going to say that I think that's not a good thing. I want there to be an awesome

01:50:46   reflection model. I want there to be awesome features for sending messages like they're

01:50:51   I just want it to be developed and designed

01:50:53   in the right way.

01:50:54   And at the same time they're being annoyed

01:50:57   that they can't do those things,

01:50:59   there are a lot of other people being annoyed

01:51:00   about compile times, right?

01:51:02   - Yeah, no, I know.

01:51:03   - And what we have to do is balance between, you know,

01:51:08   just picking two random things,

01:51:09   where does the engineering effort go?

01:51:11   And that's never a black and white thing.

01:51:15   There's never a right answer.

01:51:16   It's all based on gut and judgment and guesses,

01:51:20   listening to the community, talking to people.

01:51:23   And that's one of the reasons why I think the Swift team

01:51:25   is really phenomenal is that it really cares.

01:51:28   It really cares about what people are doing.

01:51:30   It reads, you know, the various people read the blog posts,

01:51:33   there are people on Twitter that like the engagement

01:51:35   between the Swift team and the community is really high

01:51:38   because people care.

01:51:39   And there's no management dictated Apple that says that,

01:51:42   you know, this engineer should be on Twitter all the time

01:51:45   talking to people.

01:51:46   That's certainly not the case.

01:51:47   That's because of passion from the developer

01:51:49   and it's because they really care.

01:51:51   And I think that's the thing that is so amazing

01:51:53   about the Swift team, is just how important it is

01:51:57   in terms of customer service and understanding

01:52:01   what people are working through.

01:52:03   And that insight is what guides the priority decisions

01:52:06   and guides the trade-offs that have to be made all the time,

01:52:10   because nothing really is as clear as you'd like it to be.

01:52:14   - So building on that, when all of us were going

01:52:17   and forth, and I was tangentially involved with this, we were going back and forth about,

01:52:21   "Oh, Swift isn't dynamic, it must be dynamic." Is it fair to say that that does eventually

01:52:26   make its way inside of Apple? Just that you guys are aware of it, that that's talked

01:52:32   about in some way, shape, or form? Because it's nice to know, and I suspect that it

01:52:37   does, but it's nice to know that when the community gets perturbed, whether or not that

01:52:43   feeling is justified, that at least somebody inside Apple has heard it. Whether or not

01:52:47   they can respond to it, at least they've heard it. So when we all get our pants all twisted

01:52:54   up, does that make it in?

01:52:56   Tim Cynova Absolutely. I mean, there are a ton of people

01:53:00   that happily care about what's happening in the developer community and elsewhere, right?

01:53:04   And that's one of the things about Apple's approach in terms of not commenting on things

01:53:09   that can be frustrating because you don't know, but again, there's so many people at

01:53:14   Apple that really do care and that saw it. And, you know, again, I wish those people

01:53:21   that were really worried about it would come to Swift Evolution and ask because then we

01:53:25   could have a discussion about it, but that wasn't happening for some reason. But certainly

01:53:30   there was a ton of people that saw the blogs. And I'm sure there are tons of engineers at

01:53:34   Apple that feel the same way and wish the priorities were different. And I think that

01:53:38   The engineering community inside of Apple reflects quite closely to the engineering

01:53:43   community outside of Apple as well.

01:53:46   And I hope that's not surprising, right?

01:53:49   Apple has many different engineers with different feelings and different opinions, and I think

01:53:54   that's a really good thing.

01:53:56   If it were a super monoculture or something like that, that would probably be very unhealthy.

01:54:01   Mm-hmm.

01:54:02   Taking a little bit of a turn.

01:54:04   So I started writing Swift almost exactly a year ago now,

01:54:08   and the project that I'm doing at work,

01:54:10   we're using RxSwift and quote-unquote reactive programming.

01:54:14   And I'm curious, have you looked into that at all,

01:54:17   and do you have any particular thoughts on it?

01:54:19   Does it seem barbaric to you?

01:54:20   Does it seem clever?

01:54:21   Does it just seem like an odd choice?

01:54:23   What is your take on this whole Rx thing?

01:54:26   - Yeah, so I've definitely seen it.

01:54:29   I have no real-world usage experience.

01:54:32   - Sure, sure. - So most of my opinion

01:54:33   based on reading blogs and reading people talking about how awesome it is while not

01:54:38   talking about the problems. From what I gather, it seems like it is a way of letting you write

01:54:46   a lot less code and code that often works better the first time, and I can see how that's

01:54:51   super appealing. It also seems like it'd be really challenging to debug it and maintain

01:54:55   it, and so I don't know between the pros and cons how it balances out. If I were writing

01:55:02   a lot of high-level apps, I would probably try it out on an app or two and see if I liked

01:55:06   it.

01:55:07   But aside from that, I don't really have a good insight either way if it's the right

01:55:12   thing to do or not.

01:55:13   Sure, sure, absolutely.

01:55:15   You mentioned a second ago that you see some problems, and you mentioned debugging.

01:55:19   Is there anything else that jumps out at you as being a big concern, or is it just that

01:55:22   it's so different?

01:55:23   I mean, I'm not afraid of different things.

01:55:26   I think that it's more of – I mean, the questions I'd raise – and this is out

01:55:31   ignorance, not out of fear, but what is the community doing? Is there a support line?

01:55:37   Is it changing and evolving in a way that is good or bad? These are just things I don't know,

01:55:46   because I haven't used it. I have nothing against the Rx community at all, and I've seen a lot of

01:55:50   really cool things they've done. I've read many of the positive posts in Rx and in React Native,

01:55:57   and many of the other things where people are using reactive techniques.

01:56:01   Reactive Cocoa has also been around for quite a while.

01:56:04   I think that's a really interesting application that maybe became a lot easier when Swift

01:56:09   came out than doing an Objective-C.

01:56:11   Yeah, absolutely.

01:56:13   I think that it's great that Swift can support different kinds of programming models like

01:56:15   that because if an awesome new right answer to some problem comes out, you'd hope that

01:56:24   system can support it and can make it really elegant and beautiful.

01:56:29   I feel kind of like this is fighting, you know, the last war instead of the current

01:56:34   war, but you mentioned Garbage Collection vs. the Ark a bunch of times, and obviously

01:56:39   that ship has sailed, but I would love for you to give a reasonable summary of what the

01:56:46   trade-offs were there, because Objective-C had Garbage Collection, as you mentioned.

01:56:51   Sort of.

01:56:52   Yeah.

01:56:53   it was there. And eventually Objective-C dropped the garbage collection and got ARC, and of course

01:56:59   Swift doesn't have garbage collection at all. Can you talk about the trade-offs there and why

01:57:03   Swift is the way it is? Well, would you like a comparison of ARC against the garbage collection

01:57:09   Objective-C had, or garbage collection in theory? You could pick garbage collection in a language

01:57:15   perhaps not as burdened as Objective-C, with C backwards compatibility, but you know, that's worth

01:57:20   worth mentioning as well, I think.

01:57:21   - So I think that Objective-C had a system based on libauto.

01:57:24   Libauto had a bunch of implementation concerns

01:57:26   and other things that I think don't reflect,

01:57:30   that don't obviously reflect onto the ultimate

01:57:33   garbage collector that you'd ever wanna have.

01:57:35   And so I don't think that comparing against that

01:57:37   is interesting.

01:57:38   But let me turn around.

01:57:39   So why do you think garbage collection's interesting?

01:57:41   What is compelling about garbage collection beyond R?

01:57:45   - Well, the idea that memory management

01:57:48   is completely out of the hands of the programmer

01:57:50   and that some magical fairy behind the scenes

01:57:51   will make it all good for you.

01:57:54   And that, you know, obviously what you're giving up

01:57:56   is what you mentioned before, that, you know,

01:57:57   even with Arc, you lack some amount of control

01:58:00   that you'll need to have a language

01:58:02   that becomes a system programming language.

01:58:03   Obviously you give that up with garbage collection

01:58:05   because you're not gonna be doing

01:58:06   a system program language in a garbage collection

01:58:09   with a garbage collector behind it.

01:58:10   Although I think Microsoft has some projects to do that,

01:58:12   that Singularity project,

01:58:13   where they were trying to build a whole OS

01:58:15   off of garbage collection.

01:58:16   I'm not quite sure how that's going.

01:58:18   - Right, but even if you ignore

01:58:20   the systems programming side of things,

01:58:22   because I think it's fair to say

01:58:23   a lot of people don't care about that.

01:58:25   So garbage collection is proven in the application space

01:58:29   for Java, for example, right?

01:58:33   And Perl.

01:58:34   But do--

01:58:36   - Perl uses reference counting, come on.

01:58:39   - Oh, that's right.

01:58:40   It's Python that uses reference counting

01:58:41   plus cycle collector.

01:58:42   So, but let me ask you again.

01:58:45   So you said it means that you don't have to think

01:58:47   about memory.

01:58:48   Is that true?

01:58:49   - Well, that's the pitch.

01:58:50   The pitch is that the programmer

01:58:51   doesn't have to think about it.

01:58:52   They have to think about it when the garbage collector--

01:58:54   - I understand the pitch, but is it true?

01:58:57   - When the garbage collector starts doing things

01:58:58   you don't want, then all of a sudden

01:59:00   you do have to think about it,

01:59:01   but then there's almost nothing you can do about it.

01:59:03   - So here's the way I look at it,

01:59:06   and as you said, the ship has somewhat sailed.

01:59:09   I am totally convinced that ARK is the right way to go

01:59:12   up front.

01:59:13   It is better in a whole bunch of different ways.

01:59:15   It gives you deterministic behavior.

01:59:18   So you don't get, you know,

01:59:20   it doesn't have the unpredictable stutter problem

01:59:22   that people like to bash on GCs.

01:59:24   The stutter problem to me isn't really the issue,

01:59:29   even though that's what GC haters

01:59:31   will bring up all the time.

01:59:33   It's more about being able to reason

01:59:34   about when the memory goes away.

01:59:36   And the most important aspect of that

01:59:38   is that Arc gets rid of finalizers.

01:59:41   So if you use a garbage collected language,

01:59:43   you use finalizers.

01:59:44   Finalizers are the thing that gets run

01:59:46   when your object gets destroyed.

01:59:48   Finalizers have so many problems,

01:59:50   there are entire, there's entire bodies of work

01:59:54   talking about how to work around problems with finalizers.

01:59:56   For example, the finalizer gets run on the wrong thread,

01:59:59   it has to get run multiple times,

02:00:00   the object can get resurrected while the finalizer's running.

02:00:03   It happens non-deterministically later,

02:00:06   you can't count on it,

02:00:07   and so you can't use it for resource management

02:00:09   for database handles and things like that, for example.

02:00:13   There are so many problems with finalizers

02:00:15   that ARK just defines away by having deterministic destruction.

02:00:20   Beyond that, ARK, though, so the common,

02:00:25   another common thing, there are two arguments

02:00:29   that people make against ARK in favor

02:00:31   of a trace-in garbage collector,

02:00:33   one of which is that ARK adds overhead

02:00:35   because you have retain or release operations that run,

02:00:38   and that is true.

02:00:40   The other is that you have to think about cycles in ARK

02:00:45   because it doesn't automatically collect cycles,

02:00:47   and that is also true.

02:00:49   And the rebuttal I give to people is that

02:00:53   those problems are also true in garbage collection,

02:00:56   just in different ways.

02:00:58   So in a garbage collector, for example,

02:01:00   people don't think about it,

02:01:01   but garbage collection injects additional code

02:01:04   into your application just like Arc does.

02:01:06   And so there are many different

02:01:09   garbage collection algorithms,

02:01:10   not all of them are the same,

02:01:11   But the most modern garbage collectors

02:01:16   that use a nursery for short lifetime objects

02:01:20   and then promote them out that are generational

02:01:23   use something called a write barrier.

02:01:24   And a write barrier is every time you store

02:01:27   to a property of an object, say,

02:01:31   you have to run additional code.

02:01:33   Garbage collectors also need the ability

02:01:35   to stop all the threads, or at least to be able

02:01:37   to stop threads at some point in time.

02:01:39   And they need to be able to do so

02:01:40   within a specific time bound because they don't want the garbage collector to take forever.

02:01:45   The artifact of that is that typical garbage collectors in Java, for example, will introduce

02:01:50   what's called a safe point into loops. And so now, in your loops, extra code is being

02:01:56   run because of the garbage collector. And on more aggressive garbage collection algorithms,

02:02:01   for example, I was reading a blog post recently about Go's tricolor algorithm. They're touting

02:02:08   the advantage of you get really low latency and you get the ability to guarantee response

02:02:14   times in a more fine-grained level than most garbage collectors.

02:02:18   But to do that, they use this tricolor algorithm, which dramatically lowers throughput.

02:02:22   And it dramatically lowers throughput because they're doing almost exactly the same kinds

02:02:26   of operations that ARK is doing.

02:02:29   The problem that it then introduces, though, is that these operations that the garbage

02:02:33   introducing are sometimes, but not nearly as well optimizable as the ARC overhead that

02:02:39   the ARC optimizer applies to.

02:02:41   And furthermore, there's no kind of out on it.

02:02:43   So with ARC, I think and hope that the ownership model will give people the ability to take

02:02:47   control of those overheads, and if it becomes a problem in practice, or if they're just

02:02:52   that kind of person, they can take full control over the lifetime of their objects, and then

02:02:56   know that ARC will never happen.

02:02:57   In a garbage collector, you don't have that.

02:03:00   So the performance side of things, I think, is still up in the air because Arc certainly

02:03:06   does introduce overhead.

02:03:08   Some of that's unavoidable, at least without lots of annotations in your code.

02:03:15   But also I think that Arc is not done yet.

02:03:17   A ton of energy has been poured into research for garbage collection, particularly since

02:03:22   Java has come up.

02:03:23   There have been hundreds of papers written in the academic circles, tons of work in Hotspot

02:03:27   and other Java implementations to do different tweaks and different tunings and different new

02:03:34   kinds of algorithms and garbage collection. And that work really hasn't been done for Arc yet.

02:03:38   And so I think that there's still a big future ahead. On the programming side of things,

02:03:43   the cycle side of things, I think it's also a really interesting question of how much should

02:03:48   people think about memory? When I was baiting you a little bit, you said that the great thing about

02:03:54   about garbage collection is that you don't have to think

02:03:56   about memory, but of course we know that's not true, right?

02:03:59   Because if you have a reference to some big object graph

02:04:02   that you didn't mean to keep around,

02:04:03   maybe it's in your undo stack,

02:04:05   then you will quote unquote leak that memory, right?

02:04:08   And that's true of a garbage collector,

02:04:11   that's true of ARC as well.

02:04:13   It's just any automatic memory management approach

02:04:16   has that problem.

02:04:17   And so that is a really interesting thing

02:04:22   that there's this question of,

02:04:25   if you're building a large-scale system,

02:04:28   do you want people to quote unquote,

02:04:30   never think about memory?

02:04:31   Do you want them to think about memory all the time,

02:04:34   like they did in Objective-C classic retain and release,

02:04:37   manual retain and release,

02:04:39   or do you want something in the middle?

02:04:40   And I think that Arc strikes a really interesting balance,

02:04:43   either whether it's in Objective-C or in Swift,

02:04:46   where I look at manual retain and release

02:04:50   as being a very imperative style of memory management

02:04:54   or malloc and free, all these things

02:04:55   where you're telling the code line by line,

02:04:58   this is where you should do a reference count operation.

02:05:00   This is where you should release the memory.

02:05:02   This is what you should do at this point in time.

02:05:04   Arc then takes that model and bubbles it up a big step

02:05:07   and it makes it be a very declarative model.

02:05:10   So instead of telling the compiler

02:05:11   that this is the place you should do a retain,

02:05:17   you instead say, this is an owning relationship.

02:05:20   And the cool thing about that to me is that not only does that get rid of the

02:05:24   mechanics of maintaining reference counting and define away tons of bugs by

02:05:28   doing that, it also means that it is now explicit in your code what your

02:05:32   intention was. And that's something that people who maintain your code benefit

02:05:36   from. And so by saying that I have a weak pointer to the parent object of my

02:05:41   thing, that's a really important relationship to know about. And as you're

02:05:46   looking at the code, you're maintaining the code, having that be explicit is

02:05:48   very valuable, because that talks about the relationship

02:05:52   between values and to me, again, with the goal

02:05:56   of being able to write large scale applications in Swift,

02:05:59   I think that's really useful.

02:06:00   I also don't think it's hugely burdensome,

02:06:02   though it is definitely part of the learning curve

02:06:04   of learning how Swift works that has to be balanced

02:06:08   in there as well.

02:06:10   And so, I don't know, I mean, I look at it as there,

02:06:13   Arc has clear advantages in terms of allowing Swift

02:06:18   to scale down to systems that can't tolerate having a garbage collector. For example, if

02:06:23   you want to write firmware in Swift. I think it does provide a better programming model,

02:06:28   where programmers think just a little bit about memory. And I think that going forward,

02:06:34   it provides a really high-performance model that you can get better than garbage collection

02:06:40   in almost every way. So I think that in terms of trade-offs, it's the right one to push

02:06:45   The other, I guess, third piece that garbage collection is really bad about is kind of a showstopper for Swift, which is interoperability with C code.

02:06:56   So 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.

02:07:12   But the problem is that once you start moving objects around, if you're interfacing with C code, you can't have some random C code having a pointer to your object and have it move, because then you get a dangling pointer.

02:07:22   And so once you get down that line, you end up with things like JNI, the Java Native Interface, where you have to explicitly pin things, you have to maintain them, it's very complicated, it's really buggy.

02:07:35   And Arc completely defines this away by just saying that,

02:07:39   "Okay, something's in memory. It has predictable lifetime.

02:07:43   You can reason about it.

02:07:45   Swift provides tools for dealing with unsafe pointers

02:07:48   and things like that."

02:07:49   And that makes the interoperability with existing C code,

02:07:51   but also with Objective-C and maybe someday C++ code

02:07:55   really simple, really natural, and really efficient.

02:07:57   And I think that's a huge advantage that Arc provides

02:08:00   that really would be impossible to do with a garbage collector.

02:08:04   So, that's my opinion. I mean, I think reasonable people disagree, obviously. But it's something

02:08:11   that does come up now and then.

02:08:13   Or it used to come up anyway. I'm convinced. I think you should use R for Swift. Get on

02:08:17   that.

02:08:18   Yep. And there we go.

02:08:19   Chris, thank you so very, very, very much for coming on the show. Obviously, we are

02:08:24   not an interview show, as the listeners have discovered over the last hour or two. But

02:08:29   to take your time on what is presumably

02:08:31   a very busy time of your life

02:08:33   and spend it with us three knuckleheads.

02:08:36   I really appreciate it and it was very kind of you to do

02:08:38   and hopefully this won't be the last time

02:08:41   that we'll hear you on a show or maybe even this show.

02:08:43   We'll see.

02:08:44   So thank you, Chris, I really appreciate it.

02:08:46   - Yeah, well thank you for having me.

02:08:48   I've had fun even though I'm terrified

02:08:49   and probably made a fool out of myself.

02:08:51   - Not at all, trust me, that's normal.

02:08:53   I'm still trying to get over that.

02:08:54   - Plus that's our job.

02:08:56   (laughing)

02:08:57   - All right, thanks a lot to our three sponsors this week,

02:08:59   Eero, Squarespace, and Audible,

02:09:01   and we will see you next week.

02:09:03   (upbeat music)

02:09:06   ♪ Now the show is over ♪

02:09:09   ♪ They didn't even mean to begin ♪

02:09:11   ♪ 'Cause it was accidental ♪

02:09:13   ♪ Accidental ♪

02:09:14   ♪ Oh, it was accidental ♪

02:09:16   ♪ Accidental ♪

02:09:17   ♪ John didn't do any research ♪

02:09:19   ♪ Marco and Casey wouldn't let him ♪

02:09:22   ♪ 'Cause it was accidental ♪

02:09:23   ♪ Accidental ♪

02:09:25   ♪ Oh, it was accidental ♪

02:09:26   And you can find the show notes at ATP.FM And if you're into Twitter, you can follow

02:09:33   them at C-A-S-E-Y-L-I-S-S So that's Kasey Liss M-A-R-C-O-A-R-M

02:09:43   Auntie Marco Arment S-I-R-A-C-U-S-A, Syracuse

02:09:54   It's accidental, accidental.

02:09:56   They didn't mean to.

02:09:59   Accidental, accidental.

02:10:01   Check podcast so long.

02:10:07   We didn't talk about woodworking stuff.

02:10:09   Yeah, making splinters is fun.

02:10:12   What kind of wood was that table made out of?

02:10:15   It's walnut.

02:10:16   That's got to be tough.

02:10:17   That's a lot of cutting.

02:10:18   That's pretty hard wood, right?

02:10:20   Yeah, I mean, it takes time.

02:10:22   But it's fun.

02:10:22   It's one of these areas where you can learn a lot about it over time and keep going deeper

02:10:27   and deeper in different spaces, and you never know everything.

02:10:31   So it's a lot of fun to dive into woodworking.

02:10:33   It's also very different than sitting in front of a computer all day.

02:10:37   You actually get to make something with your hands, and you get to build—

02:10:40   Much higher chance for dismemberment.

02:10:43   That is true.

02:10:44   That is true.

02:10:45   I think it's interesting when programmers have incredibly analog hobbies.

02:10:51   It's also hilarious because the woodworking community is going through this whole CNC

02:10:54   thing where they're turning it into a very programmed thing and people always say, "Well,

02:11:00   why don't you get into CNC and do blah, blah, blah."

02:11:01   I'm like, "But that's exactly what I'm escaping.

02:11:04   I don't want to have to program my…"

02:11:06   I love that you can't even escape the community arguments over standards.

02:11:10   So you just cut down a tree and you throw it into your workshop and then out comes a

02:11:16   table.

02:11:17   Yeah, well, so that's the funny thing about people is that people are all the same.

02:11:20   and they just don't wanna notice and agree to that.

02:11:23   - Oh my goodness.

02:11:24   - You know, you get to very different communities

02:11:25   and they think they're all different,

02:11:26   but they're actually the same at root.

02:11:30   - So Chris, you're obviously changing careers,

02:11:33   well not careers necessarily, but changing employers.

02:11:36   Would you consider yourself a car person?

02:11:39   - Well, so that's a funny question.

02:11:40   I mean, I obviously need a car.

02:11:42   Cars are really important.

02:11:45   But I'm what I consider to be an uncar person.

02:11:48   I want to accelerate the path to cars being appliances that

02:11:53   solve people's problems.

02:11:54   And I'm personally not the kind of guy

02:11:56   who loves doing oil changes and fiddling around with them.

02:11:59   I just want something that is reliable, that works,

02:12:03   ideally drives me to where I want to go,

02:12:04   and I don't have to think about it.

02:12:06   It's just solving my problems.

02:12:08   It's not something I have to care for, feed, and maintain.

02:12:11   So that's kind of the way I look at cars.

02:12:14   Can you drive a stick?

02:12:17   I did drive a stick before I got my Tesla a few years ago.

02:12:20   So, yeah.

02:12:21   - It all comes clear now.

02:12:22   - I mean really, from the point of view,

02:12:24   it kinda sounds like you want to make cars boring

02:12:27   in a good way, really.

02:12:29   And that's a notable goal,

02:12:31   and I think I can see why you went to Tesla.

02:12:34   However, it is kinda funny that Tesla is, in my opinion,

02:12:37   clearly the most exciting car company

02:12:40   that the world has known for quite some time.

02:12:42   And so to go there while having such like a,

02:12:46   An almost nonchalant opinion about cars

02:12:49   is interesting to me.

02:12:51   - Yeah, well I admit that I never considered

02:12:53   going to work at a car company before,

02:12:57   but that's because I always considered car companies

02:12:59   to be not in need of the kinds of skills that I bring.

02:13:04   But autopilot I think is a really exciting

02:13:08   and really big problem, and it kind of fits

02:13:10   with my desire to solve nearly impossible problems

02:13:15   and take on new things.

02:13:17   And so I'm really excited about it.

02:13:19   - So I'm a little curious on that note.

02:13:22   We've talked on this show before about

02:13:26   whether we think that full self-driving cars,

02:13:30   basically when and whether we think those will exist,

02:13:33   like in what kind of time frame,

02:13:34   are we talking a decade, our lifetimes, ever?

02:13:37   Because it's one thing to make something

02:13:38   that can work on clearly marked highways,

02:13:41   it's another thing that can make something work

02:13:43   where John lives where there's ice all over the roads

02:13:46   for most of the year and so like,

02:13:47   there's no more lane markings,

02:13:48   there's barely any flat road surfaces,

02:13:51   or you have all these different ambiguities

02:13:53   that you have in real world roads.

02:13:56   Do you think, you know, again,

02:13:59   obviously this is not in any kind of official capacity

02:14:01   as an about to be Tesla employee,

02:14:03   do you think, big picture,

02:14:07   that we will see completely self-driving cars

02:14:10   capable of driving on effectively all roads

02:14:12   within say the next decade,

02:14:15   and if not maybe within our lifetimes?

02:14:18   - Yeah, I think that it's very possible

02:14:20   within the next decade,

02:14:21   and hopefully that's a long view.

02:14:25   But keep in mind the goal is to drive better than a human,

02:14:29   and significantly better than a human.

02:14:31   And I think one of the things that gives me confidence

02:14:34   in this is that it's not an even playing field

02:14:38   because the autonomous cars have more sensors

02:14:42   than humans do.

02:14:44   They have a radar, for example,

02:14:46   and that means that they're capable of doing things

02:14:48   that humans just physically can't.

02:14:50   And there's a huge technology problem,

02:14:53   there's huge software problems,

02:14:54   this is not a overnight kind of a thing

02:14:57   that you wake up and solve immediately,

02:14:59   but I have confidence it could be solved,

02:15:02   certainly within a decade.

02:15:04   - Well, the good news is it's not gonna take a lot

02:15:07   to be better than your average driver from Massachusetts,

02:15:09   because that's a pretty low bar.

02:15:11   - No, because they know how to navigate these intersections

02:15:13   that have like seven different exits,

02:15:15   all at different angles, some of which are one way,

02:15:18   none of which are marked.

02:15:19   So the humans can figure that out.

02:15:21   It's gonna be tough for the sensors.

02:15:22   - Tell you one thing, I will drive in Manhattan

02:15:24   without any problems.

02:15:25   I would never drive in Boston.

02:15:27   - Oh, amen, brother, I completely agree.

02:15:29   All right, so to bring this back around,

02:15:30   Chris, you made mention way early in the episode

02:15:33   that you like yellow cars.

02:15:35   - What?

02:15:37   - Yeah, yeah.

02:15:38   - What is this?

02:15:39   - One of my favorite cars was a yellow Mini Cooper

02:15:44   with black hood stripes on it.

02:15:45   - Nice.

02:15:46   - And a Mini Cooper convertible, it was totally awesome.

02:15:49   That doesn't get you in the carpool lane,

02:15:52   but it was a beautiful car.

02:15:55   - In his defense, like yellow,

02:15:57   like I've seen that kind of category of color,

02:16:01   like yellow, orange, maybe teal,

02:16:04   or even like a pink, like that kind of bright,

02:16:07   almost neonish colors, can work really well.

02:16:10   They often don't, but when they work well,

02:16:14   they look pretty good.

02:16:14   I could totally see that.

02:16:16   The only flaw I see in this plan is that Tesla

02:16:19   does not currently offer either yellow paint as an option

02:16:22   or custom paint colors as an option.

02:16:24   - Well, so now you've broken into the real secret

02:16:26   they wanna hire a compiler guy.

02:16:28   (laughing)

02:16:29   - That's why.

02:16:30   - Would you have gotten your Tesla in yellow

02:16:32   if you could have?

02:16:33   That's the question. - Yes, absolutely.

02:16:35   - It would look like a giant banana.

02:16:36   What are you doing?

02:16:37   (laughing)

02:16:39   - Yeah, I hadn't really fully thought this through, John.

02:16:44   - I don't know if you could, that car can pull,

02:16:46   we're talking about a Model S, right?

02:16:48   - Yeah. - Yeah.

02:16:48   - Yeah, no, I would, yellow doesn't seem right for that.

02:16:51   We could do some Photoshop mockups,

02:16:53   let's workshop it a little bit, we'll see.

02:16:55   Maybe if you got black stripes down the middle.

02:16:57   - Yeah, I admit this is a case where details matter, so.

02:17:00   - Yeah, no, I mean, that's like,

02:17:02   if there's any way for you to get like a pet feature

02:17:04   implemented in the model line,

02:17:06   that seems like a pretty good one to do.

02:17:08   At least, and you know, I would ask,

02:17:11   I'm sure, I know you're probably not gonna be working

02:17:13   on the Bluetooth UI, but I'm sure you could probably

02:17:17   put in a word with the right people

02:17:19   to please improve Bluetooth audio.

02:17:21   (laughing)

02:17:23   But otherwise, if you can make a yellow one,

02:17:25   I think that would be, you know,

02:17:26   in addition to potentially saving thousands of lives a year

02:17:30   with autopilot software, you know,

02:17:32   getting improved Bluetooth and a yellow option

02:17:34   would be pretty impressive.

02:17:35   Well yellow would make your car more visible to other drivers, other human drivers

02:17:38   Who need bright colors to know that you're there since you don't have any engine sound

02:17:42   And I have to say this is the most effort I've ever done to win over one Swift programmer

02:17:51   [laughter]

02:17:57   So I'm not sure if this is a scalable approach

02:17:59   Yeah, this is a bad strategy for Swift adoption

02:18:01   You should seek other me instead of coming on everybody's podcast and talking to them

02:18:05   individually.

02:18:06   Oh my god, that's amazing.

02:18:07   [BLANK_AUDIO]