ATP

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