Under the Radar

66: State of Swift


00:00:00   Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment.

00:00:05   And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.

00:00:10   So here at Under the Radar, we have a long and storied history with Swift,

00:00:15   going all the way back to November of 2015, when the show was but an infant,

00:00:21   and we talked about whether it was time to adopt Swift.

00:00:25   And in the, I think it's about 15 months since then, much has changed, much has happened,

00:00:30   and it is kind of a strange thing to finally be able to talk about,

00:00:36   but I think we are now both in a place that we can actually talk with some experience about Swift,

00:00:41   rather than before, where we were waffling purely speculatively about it.

00:00:45   If there's anything that can go on my tombstone, it's like, waffles purely speculatively.

00:00:51   That's basically all I do. You're a professional waffler. Exactly.

00:00:56   But yes, we have now both used it, and I think it is an interesting time in the life cycle of Swift,

00:01:03   I think, to talk about, because I think it is hitting a point now where if you aren't using Swift on a regular basis,

00:01:10   or at least in some capacity, you're likely putting yourself behind, rather than,

00:01:15   there may have been a period, I mean, this is largely what we were arguing back in 2015,

00:01:20   that back then, if you were adopting it, you may be setting yourself up for a future hurt,

00:01:25   whereas I think now you might be, you've sort of hit the inflection point around,

00:01:30   it's something that is now stable enough, is now widely adopted enough,

00:01:37   and is just becoming the industry standard at this point.

00:01:40   And I thought it would be interesting for us to unpack it a little bit and just talk about our experiences,

00:01:45   because I've been doing Objective-C for so long that doing anything else is always going to feel weird,

00:01:51   and I think it's been interesting. So I wrote all of Workouts++, the last major app I launched in Swift.

00:01:59   There's not a line of Objective-C in it. There were a few areas where I could have cheated a little bit,

00:02:04   where I had some existing functions or library code that I could have pulled in from another project,

00:02:12   and I said, "No, I want this all to be in Swift," and so I translated those over and made them work.

00:02:17   So the entire thing is done in Swift. And it's been an interesting process,

00:02:21   because learning in general is interesting, and I think maybe it's just age,

00:02:27   but I think the process of learning something feels like more of a mountain to climb now,

00:02:33   that it's actually genuine, hard work for me cognitively to get over it.

00:02:40   But now that I've done it, I think I'm glad that I did, and I certainly have no regrets.

00:02:44   But we'll get into this as we go on. But it is definitely not without its trade-offs to be getting into now.

00:02:52   And you get into it too, right?

00:02:54   Yeah, so I actually started in the last few weeks, I guess, or about a month ago.

00:03:00   I had a need for a new extension for Overcast 3.0, and it was going to be a pretty small extension,

00:03:09   not a lot of code, so I figured this is a perfect opportunity for me to try out Swift

00:03:13   and to make this extension entirely written in Swift. And I did.

00:03:17   And I did it in a day, or less than a day, actually, because it was the same day that ATB recorded with Chris Lattner,

00:03:23   which is one of the reasons I did it that day.

00:03:25   To just suggest you wouldn't have to sheepishly look at your feet when he started talking about Swift.

00:03:30   Exactly, just so I could say I'm now a Swift programmer, and it was totally worth it.

00:03:34   But yeah, so I started with it that day, and I've since written a little bit more of Overcast 3.0 using it.

00:03:39   Not a ton. I'm really very, very shallowly dipping my toe in the water so far.

00:03:45   But I have decided this is the thing that I'm doing now.

00:03:48   And I have written new code since then that is an Objective-C, partly because of just the simplicity of

00:03:55   "I know how to do this really fast in Objective-C, and this is going to be a constant battle for me."

00:03:59   Trying to balance, do I take the extra time and hassle to learn how to do this in Swift,

00:04:05   or do I just do it the easy way that I already know how to do it in Objective-C?

00:04:08   And that is a constant battle for me.

00:04:11   That's the whole reason I hadn't learned Swift up until now, is because it's like,

00:04:14   "Well, I know how to do this really quickly, and I don't want to take the time to learn."

00:04:17   And that is a very pragmatic approach to take most of the time for a lot of things.

00:04:23   But there does come a time when it does start holding you back.

00:04:27   And as you mentioned, I think that time for Swift has definitely passed.

00:04:32   That now, we can kind of compare it.

00:04:35   I mean, things aren't exactly the same, obviously.

00:04:37   We live in a different world, different conditions, but we can kind of compare it back to when OS X launched,

00:04:44   and they launched the Cocoa APIs.

00:04:46   And Mac developers have been writing in this other way, using C instead of Objective-C and C++,

00:04:53   and then the Carbon frameworks came around to kind of help bridge that gap.

00:04:58   But ultimately, it was very clear that the future was Cocoa,

00:05:02   and that you really should be writing your apps using Cocoa from that point forward.

00:05:07   And a lot of Mac developers waited for a long time for various good reasons.

00:05:11   Some of them weren't so good, but most of them were good reasons.

00:05:13   And eventually, Apple started making new capabilities and new frameworks that could only be accessed through Cocoa.

00:05:20   And so it forced people to bring their apps over begrudgingly at that point.

00:05:26   It's only a matter of time before there is something like that for Swift.

00:05:31   And it's probably not even that long of a time.

00:05:33   It could even be this fall with this fall's OS updates.

00:05:36   Basically, any time now, we could hit a point where Apple launches some new framework or capability,

00:05:44   or maybe they launch a whole new platform that only accepts apps written in Swift.

00:05:50   That's, I think, less likely right now, but down the road, maybe.

00:05:54   And so it's only a small matter of time before we are kind of forced,

00:06:01   or really strongly encouraged with some new capability to use Swift.

00:06:06   And it would be best for you as a programmer if you decided the timeline

00:06:12   on which you learned a new language, because it is a big productivity hit.

00:06:17   So it's the kind of thing where if you wait for Apple to force you to do it,

00:06:22   then Apple is deciding that timeline for you.

00:06:25   That basically means that at some point in the future,

00:06:29   Apple is going to cost you three to six months of lower productivity

00:06:33   while you figure out this new language,

00:06:34   because you're forced to adopt some new thing for them for business or market reasons.

00:06:39   Whereas if you learn it earlier than that, you can choose when to do that.

00:06:43   And you can do it at a more opportune time, you can do it over a more gradual period if you want to,

00:06:48   and so you can choose when to take that productivity hit, when to learn this new language,

00:06:52   and when to start migrating your code over.

00:06:54   So that way, when the inevitable happens, when Apple does something that either forces you

00:06:59   or encourages you to use Swift, you're already ready,

00:07:02   and you don't have to then take that hit at that point.

00:07:05   You already took it at a more opportune time.

00:07:07   So I think this is a wise, you know, if you look at the language,

00:07:11   I think it's very clear it's settling down.

00:07:13   A lot of the basics are now pretty firmly established,

00:07:17   and while there's still a lot of room to go on the language itself,

00:07:20   there's still a lot of future enhancements and directions that it needs

00:07:24   and that it will eventually get over the coming years, probably.

00:07:27   I think it's very clear now that it is stable and safe enough to write apps in,

00:07:33   and that you probably should be writing most new code in Swift these days,

00:07:38   unless you have some really, really compelling reason not to.

00:07:42   Yeah, and I think Swift, too, it seems like it's hit the point where

00:07:46   I think the biggest concern I had in the early days was

00:07:49   it isn't so much that the language itself was changing out from under me,

00:07:55   which was certainly something that has happened, and I guess theoretically could still happen,

00:07:59   but the bigger things that I was worried about is that it hadn't gotten to a point

00:08:03   that it had worked out what its sort of idiomatic approach was going to be,

00:08:09   like what good normal Swift was going to look like.

00:08:13   And I think a lot of Swift 3, like the changes they made last summer,

00:08:17   seemed to be about kind of formalizing a bit around a approach and a naming structure

00:08:24   and like the way you should structure your method names,

00:08:27   and they did a lot of work around the way you do that,

00:08:30   so that you have a good Swift API should look like, seems to be fairly buttoned down now.

00:08:36   And I feel like that is, when I started to dig into it and see those types of changes,

00:08:42   it spoke to a certain level of maturity that isn't just like, does this work?

00:08:47   And to the level of like, okay, this is something that is mature enough to a point

00:08:52   that I can start using it and not find myself kind of going down these dead ends

00:08:56   where it's like, actually, we tried that and that's not really a good way to structure things,

00:09:01   or to name things, because it's a bit of a joke, but one of the hardest things in programming is naming,

00:09:06   and it's an important thing to be able to have consistency across your code base.

00:09:11   And when you look at a method to know what it does, and whether you like it or not,

00:09:16   Swift has an approach that they've taken now where the named parameters

00:09:20   and the way that you have internal names and external names,

00:09:23   and it's very much something that seems to be settling in, and that kind of style side of it,

00:09:30   I think is a great indicator that is settling down.

00:09:33   And I think also, the style they've chosen, it seems reasonable and it makes more sense to me

00:09:41   than I feel like when I was looking at the older versions of Swift.

00:09:45   It felt a bit more verbose than it needed to be sometimes,

00:09:50   and I kind of like the way that you can, you know, it tightens things up a little bit,

00:09:56   and it makes it feel a bit more natural, for me, coming from Objective-C.

00:10:00   Because I was a bit surprised, honestly, that it was easier to learn than I thought it would be.

00:10:07   I'm by no means a Swift expert at this point. I've written an app in it,

00:10:11   versus I've written dozens of apps in Objective-C, but going to it, it helps, certainly,

00:10:19   the APIs that I'm working against, I know inside and out.

00:10:23   And so that part didn't change. I know how UIKit works, and I know how all the frameworks work,

00:10:28   and so I'm just using the Swift version for that.

00:10:31   But I also like the one thing that's kind of nice with Swift that I wasn't sure how much this would be true,

00:10:39   and maybe nervous, was you don't have to go all in on kind of the more, I guess I'd call it esoteric features of Swift.

00:10:51   The language nerd features?

00:10:53   Yeah, like where you can do these really clever, complicated things with closures and generics and types,

00:11:00   and you are doing these very clever things.

00:11:06   Basically anything that a Ruby or C++ programmer would think is really cool.

00:11:11   Yeah, that's cool, and I'm glad that you can do it.

00:11:15   And I subscribe to several RSS feeds of people who do that, and I try and read them,

00:11:19   and I usually get two paragraphs in and then bail.

00:11:22   But I was worried initially that that was what I was going to have to do,

00:11:26   that my code was going to, in order to write good Swift, it was going to have to be this kind of very esoteric,

00:11:31   this kind of very crazy version of code that just isn't the way that I tend to think about problems.

00:11:37   I tend to think very straightforwardly and pragmatically, and that works well in Objective-C,

00:11:42   and I was glad that I could just kind of do that in Swift.

00:11:44   And maybe my Swift isn't taking advantage of some of these cool features that I could be taking advantage of,

00:11:50   but it still works well, it still flows nicely, and isn't like I'm kind of fighting against the grain on that.

00:11:56   And there are a few times that I've done things that are a bit cleverer,

00:12:00   when you start to do things where you have a function that takes a closure that you can use to process data,

00:12:07   and so you can ask for, like I use this in a bunch of my, like in Workhouse++, there's a bunch of graphs, for example.

00:12:15   And the way in which I structure that, depending on what data you're passing to it,

00:12:22   it needs it in a different, like the end result is just going to be numbers on an xy plot,

00:12:29   but the input can be different, and so I have a nice little, like, swifty thing where you can,

00:12:33   when you're setting up the graph, you also give it a little transform to take the data from whatever form you have it on the input side into the expected output side.

00:12:42   And that makes that graph code look really cool and clever, and I feel kind of cool about myself that,

00:12:48   "Hey, I wrote this very swifty thing, but if I didn't do it that way, and I just did it in kind of a more procedural, direct way, that would have been fine too."

00:12:57   And I like having that flexibility and not feeling like I'm totally having to buy into this just super esoteric version of things that is possible in Swift.

00:13:07   Yeah, exactly. I mean, I think one of the advantages that we get as indies, especially as like literally one person shops,

00:13:15   is that we only write this code for ourselves. We are probably the only people who will ever even see this code.

00:13:22   Like, there's the slight chance that you might down the road sell the app or hire somebody,

00:13:27   but for most of the apps that you and I, and I think most people like us, write, that's usually not the outcome.

00:13:32   So you can basically write your code in whatever style you want, in whatever language you want that works on the platform,

00:13:40   and using any degree of the languages available cleverness that you want.

00:13:45   And so if you are the kind of person, like you're a real language nerd who really likes all those really clever things that languages can do

00:13:52   with some of these kind of esoteric constructs and little complexities throughout, then you can do that.

00:13:59   And you can be incredibly personally satisfied that you can do that, because there's no style manager at your company telling you that you aren't allowed to use that.

00:14:07   You can use the latest versions of all the languages and all the coolest things that come with the latest versions of all the languages.

00:14:11   You can make those decisions yourself, and if you want to be clever, you can be clever.

00:14:16   If you want to be straightforward, you can be straightforward.

00:14:19   And you can alternate whatever you want, depending on how you feel that day, and whatever the code is that you're writing.

00:14:24   And it's a wonderful luxury that we have in the positions that we're in.

00:14:29   And it's something that, like, if you're working with a lot of other people, if you're working at a company, or possibly even doing consulting.

00:14:37   You know better than I would how often this actually comes up in consulting, where you have a lot of other programmers looking at your code.

00:14:42   But if you're working with other people, then you have to deal with everyone having to either not follow the same complexity level,

00:14:50   and have code that varies wildly in cleverness and complexity being merged into the same app and worked on by a team of people.

00:14:57   Or you have to enforce some kind of style guide, which is never easy, but to enforce some kind of style guide on people,

00:15:03   makes them miserable, that says, "Alright, well this is the way we do this, this is too clever, this hurts readability or whatever else."

00:15:10   And so it is kind of nice to be in our position where we can pretty much write code however we want,

00:15:15   and the only people that will ever see it are us, so we're just writing to make ourselves happy with it,

00:15:19   and we can do it to any degree of cleverness that we wish.

00:15:23   Yeah, and I think that speaks to also the sense that I see in Swift, too, something that I can see how many of the choices that it has made

00:15:33   are about addressing problems that I think would come up in a situation that doesn't really directly apply to us,

00:15:40   that does speak to the situation, like the large codebase with lots and lots of people potentially coming in and out of a project,

00:15:47   or this was built by these consultants and then it was passed over to these consultants, and now we've taken it internally.

00:15:54   And this is something that I struggle with still, is Swift encourages very strongly a certain level of formalism in what you're doing,

00:16:06   about being very declarative about what your intentions are for something.

00:16:12   Perhaps the most straightforward example of this is optionals, where you have to be very clear about should this value have a value or does it not,

00:16:22   and you have to be very upfront and clear about that, and there's no way, if you have something that isn't an optional,

00:16:28   it'll always have a value and you can trust that to be there, absolutely.

00:16:33   And I can see that those types of features would be incredibly useful in that kind of varied, mismatched codebase,

00:16:44   where you're just removing ambiguities from the code. Everything has to be very upfront, everything has to be very explicit.

00:16:52   I mean, the other thing that drives me, that still drives me crazy, is the number of times I have to cast ints to doubles and doubles to cg floats,

00:16:59   and doing all this kind of work to move around, which all being very precise and very formalized, which is not a bad thing.

00:17:07   The code is still definitely better as a result of it in the sense of it is clearer, but it takes more work to do.

00:17:14   In Objective-C, I haven't been doing that and things have been fine, and that's easy for me to say because I'm a one-man team,

00:17:21   and so I just kind of know when it's appropriate to use a value and when it's not.

00:17:27   And every now and then I'll probably run into a problem with that, but in general it works out okay.

00:17:33   Whereas Swift has these things in it that I think are certainly benefits to me.

00:17:38   I wouldn't want to say that I don't like that they're there, but I find them inconvenient sometimes.

00:17:44   And it's probably getting better now that I've done more of it, that things become a bit more automatic.

00:17:50   But there's a lot of features in it that I think work well for these structural, big picture issues that you might encounter in a complex codebase

00:18:02   that don't directly apply to me, but are definitely something that I just have to wade through anyway.

00:18:09   We are sponsored this week by Pingdom. Start monitoring your websites and servers today at pingdom.com/radar.

00:18:16   You get a 14-day free trial, and when you enter offer code RADAR at checkout, you get 20% off your first invoice.

00:18:21   Pingdom is an awesome monitoring service. I use it, Dave uses it, I've used it for a very, very long time,

00:18:29   I think something like eight or nine years now. It is ridiculous how long I've used Pingdom because they're just good.

00:18:33   We used them all the way back at Tumblr, the whole lifetime at Tumblr, all the way up through all of Instapaper.

00:18:38   I've used it since all of Overcast, most of marker.org. I've used it for everything.

00:18:43   Dave even uses it to monitor sites that aren't even his, like when the WWDC was announced and things like that.

00:18:49   So with Pingdom, they offer easy to use, powerful, and incredibly effective monitoring tools and services.

00:18:57   So you can monitor the availability of your site, your database, your server, any kind of key interactions like a login or a search or anything like that.

00:19:05   You can monitor all of these things, whether it's like the front end or a backend service, all of these things.

00:19:10   You can have them checked as often as once every minute if you want to. And of course everything's customizable.

00:19:16   You can have it checked for like a string on the page to make sure it's okay.

00:19:20   One of the tricks I do with Pingdom is I have two checks, I have two levels of failure, one of which is called the vitals check.

00:19:28   And that checks a special page on my site that runs a whole bunch of tests and tests things like low memory, very high CPU usage on any of the servers, low disk space, stuff like that.

00:19:38   Long replication lag on a MySQL slave for instance. There's so many possible conditions that you're like, "I want to be notified when that is in this warning zone."

00:19:49   However, I don't need to be high alert, text messaged, phone called, faxed, woofed. I don't need all of those things to all happen at once for that kind of condition.

00:19:57   So you make two tests. One of them you have that kind of low error condition and you can set entirely different alert parameters for that one.

00:20:04   And then you can have like a high alert situation of like it is down, the site is down, something critical is not working, it is down.

00:20:11   That's the one that you set to all the high alerts. Because you have all these independent options you can set for different alerts, you can be alerted all different kinds of ways.

00:20:18   Text message, app push notifications, there's so much emails, so much you can do there.

00:20:23   I've been using Pingdom for a very long time. I highly recommend Pingdom.

00:20:27   All you need to do is give them a URL to monitor whether it's yours or somebody else's.

00:20:31   And you can search for changes, downtime, conditions, whatever you want and they take care of the rest.

00:20:36   You'll be immediately alerted to any failures that happen so that way you can go fix them before like the entire internet sees it and tweets you that, "Hey, your site's down."

00:20:45   Like you should know before Twitter knows and then you should be the one that can go then start fixing it before too many people see it.

00:20:52   So check it out today at Pingdom.com/Radar. You get a 14-day free trial and use code radar at checkout to get 20% off your first invoice.

00:21:01   Use Pingdom so you can be the first to know when your site is down.

00:21:05   Our thanks to Pingdom for their support of this show and Relay FM.

00:21:08   Some of the last few things that I think it seemed like it might be worth talking into were some of the things that we wish were slightly different in Swift or problems we ran into just to kind of wrap this out.

00:21:22   Because I think overall I have a fairly positive view on it, but I think there are still some issues that I ran into that make it a bit more sort of awkward.

00:21:31   And like the ones I was just touching on I think is like the easy example to like the things that won't change going forward probably, like some of the structural approaches and the formalism that the app has like isn't my favorite, but that's more of a personality issue.

00:21:44   But I did, one thing that I did run into many times that was definitely, probably in some ways was the biggest change for me coming from Objective-C was that it felt like the tooling for Swift still hasn't quite caught up to the level that I'm used to when I'm working with Objective-C.

00:22:00   Things like the documentation viewer being appropriate, coming up as you would expect it to and knowing what I mean when I'm option clicking on a method name, or how long it takes for things to compile, or probably even moreover it's the time it takes for the compiler to adapt to a change I make where it reports an error, I fix the error, and then I recompile and it's like sometimes it picks it up right away, sometimes it doesn't quite.

00:22:27   There's a lot of these little issues that I'm sure will get better, and I'm sure that whatever it is when we get the next version of Xcode this summer they'll continue to get better, but that was one area that I was coming to Swift was like, hmm.

00:22:42   The language issues aside, that is an area that I'm very hopeful that Apple is putting a lot of effort into to making sure that that catches up because it definitely makes me realize how spoiled we are in Objective-C land.

00:22:54   Xcode for Objective-C is just perfect. It does such a good job, it is so responsive and performant. Obviously, Xcode has its issues. I talked to Mia three or four years ago and I'm sure I was complaining about Xcode crashing and things happening, but by and large the actual day-to-day editing of code and things in Objective-C was one of the areas where I felt like I wish Swift could catch up to this and just be a little bit better and a bit more efficient.

00:23:23   A little bit better and a bit more reliable.

00:23:25   Yeah, and I think the good thing is that every time there's a new Xcode beta or a new major release in the summertime, they actually do make major progress in that area.

00:23:35   So it's not like they're standing still on that. They had a lot of progress to make, however they do seem to be making it on a regular basis. And it's to a point now where in my admittedly still very early and light usage of Swift, I didn't really run into a lot of problems.

00:23:54   There are certain little annoyances of things like figuring out the bridging and everything because none of the automatic stuff did it for me, but for the most part it was pretty good. And I've actually found it very useful.

00:24:06   One of the things that I commended the Microsoft development stack for a long time ago is that you can basically start coding in C# as long as you know that it looks kind of like Java.

00:24:18   And so all you need to do is type a method name and a dot. Or type an object dot and then it will autocomplete and offer you every possible method that that option can do.

00:24:29   And it makes it so easy that you can kind of fumble through while barely knowing the language at all.

00:24:37   And that is kind of how I've been using Swift so far. I still haven't read the Swift book. I haven't actually learned Swift, I just started using it.

00:24:48   And I just kind of stumbled through because as you mentioned earlier, I know the frameworks really well and I know some general ideas of what Swift is.

00:24:57   There were a few times where I had to look up syntax for things like the guard let block and everything else, but for the most part I just kind of figured it out and stumbled through.

00:25:07   And a lot of times I will do something wrong, but then the autocorrect suggestion warning that comes up is almost always what I wanted and so I just let that do what it thinks it needs to do.

00:25:19   And it works. And at some point I'm going to have to read that Swift book and I just keep putting it off, but the tools are so good now that you can stumble through the way I do now.

00:25:31   You can, like if you are a reasonably experienced programmer and you know the frameworks, like most people listening to the show in all likelihood, if you haven't used Swift yet, it is surprisingly easy to just start using it without doing a whole bunch of research and learning up front.

00:25:46   You just start plowing through and the tools help you along the way. And that's great for, I mean it's probably great for novices also, but certainly from our point of view and from my point of view, that's been invaluable.

00:25:56   And the tools, there is still a lot of room for improvement, but they are, after hearing all the horror stories from people about source kit crashes in the early days and bad compile times and everything, I'm actually quite happy with the state of the tools right now.

00:26:11   Obviously yes, it can be improved, but they were better than I expected them to be given what I've heard. And the only thing that really bugs me about using Swift is that now my binary is going to be more than seven megs.

00:26:23   That's the one thing that, like, I know nobody cares. I know that you're using Overcast to download podcasts that are like 50 or 100 megs per episode.

00:26:33   I'm very aware of this fact, and so the fact that my app is like seven megs and that now that I'm shipping Swift code it's going to go up to like 25 megs, I shouldn't care about that, but I do.

00:26:43   And I wish that wasn't the case for a long time. That's why I didn't use Swift, was that I didn't want to bloat the size of my app.

00:26:50   Hopefully down the road they can build in the frameworks and the OS level when things stabilize so that that's less of a problem.

00:26:56   Or I'll just have to accept a 25 meg app for the rest of time and I'll just deal with it.

00:27:01   Yeah, and I will say, there's all those little things like that. App size is a minor point.

00:27:08   But I think the reality is it's quite an impressive trick that Apple has pulled here.

00:27:15   It's only taken three years to turn their development community entirely around.

00:27:23   It's not quite like they've gone 180 degrees, but they've made a fairly substantial course correction and done it in a way that makes sense.

00:27:32   I think I had a similar experience to you of learning. I read the first section or the first chapter of the Swift book.

00:27:40   I didn't read the whole thing, I just read the basic syntax part, which I think is probably all most Objective-C developers would need to do to get started.

00:27:48   So don't be too scared of the whole book, you can just do a little bit to get started.

00:27:53   And then it's familiar but different in a way that makes it very approachable and reasonable.

00:28:02   It's a great little trick they pulled to get everybody off something that they wanted everyone to get off, but did it in a way that hasn't been quite so painful.

00:28:14   And I think certainly some of that is because we waited until Swift 3 to get onto it, and so a lot of the teething issues are done,

00:28:21   and a lot of the early stability, or just the uncertainty. I definitely appreciate it.

00:28:29   I admire the people who were really excited about being part of Swift's creation and part of its evolution, and were really excited about that process,

00:28:37   whereas I had no interest in that. That just sounds like something I would not enjoy. I love being able to just arrive now,

00:28:45   benefit from all that work and the thoughtfulness that went into it, and pick it up pretty quickly.

00:28:52   It's kind of remarkable in some ways that you wrote an extension in Swift without ever knowing really more about Swift

00:29:01   than just probably seeing the example code on slides at WWDC and a few little bits and pieces there,

00:29:08   and you just kind of can work it out and make it happen. I think that says a lot to the language design and how far things have come.

00:29:16   And the tools.

00:29:17   Yeah.

00:29:18   Yeah. All right, thanks a lot everybody for listening. We're out of time this week, and we will talk to you next week.

00:29:24   Bye.

00:29:26   [BLANK_AUDIO]