Recorded at Swift Summit in London, Brian Gesiak, Chris Eidhof, Ayaka Nonaka, and Airspeed Velocity sit down with Colin Eberhardt to discuss The State of Swift. If you want informed answers to questions like, “What’s so great about Swift?”, “Is Swift ready for production?”, or the seemingly obligatory, “Will Swift replace Objective-C?”, then this is definitely a discussion to watch.
Airspeed Velocity has been obscured, to preserve anonymity.
You can read an edited transcript below.
Q: Where do you currently use Swift? At home, at work, crazy scripts on the command line?
Brian: As I mentioned earlier, I created Quick, the Swift and Objective-C testing framework. I wanted to get into that really quickly, but none of the existing frameworks really supported it yet, so I figured it would be a good exercise to maintain it myself. Since then I’ve been maintaining that, and it’s one of my main Swift projects. At Facebook, one of the questions I focus on is whether using Swift will result in an improvement for users of the apps that I write, but that’s up to every team to decide. I work on newsfeed infrastructure, and using Swift adds a significant amount of size to the app, so that has to be weighed with other costs. The majority of what I work in is still Objective-C and C++, since that’s what the Facebook codebase is written in.
Ayaka: In terms of personal projects, everything that I do is Swift now. I have one CocoaPod that’s in Swift, and because I’m interested in learning Dutch, I made a Swift API called Polyglot that translates Tweets for me.
Chris: These days, I write all my code in Swift. We’ve also been building a new app in Swift, so I can also raise my hand for the question about shipping Swift in production.
Airspeed: I am all talk, because I don’t actually write any production code, Mac or iPhone, at all. My day job is working on the Windows platform, so I am not an iOS or Cocoa developer. Swift is an opportunity for me to write something on the Mac platform that I use at home. I literally only write Swift code for my blog, so I write about it just as a language, and not about the platform. It’s nice that Swift is complex and interesting enough that you can write about it just as a language, rather than as a conduit for the platform. I would love for it to be part of my day job, but there are complexities with that…
Q: Can Swift handle your scale?
Brian: For my open source testing framework, you don’t deal with the same problems with a testing framework as you do with actual production code that runs in an app. Swift is definitely one hundred percent capable of handling problems a testing framework like that would have. The one thing that it can’t handle is that it can’t really do dynamic stuff, and part of the APIs for Apple’s XCTest use NSInvocation. If you try to access that from Swift, that line gets highlighted in red and says, “NSInvocation not available.”
Q: In Al’s talk, he used the terms ‘monadic’ and ‘monadically’. Can you tell us what ‘monad’ means?
Chris: One of the things I don’t like about functional programming is the complicated terminology, like ‘monads’, and there are a lot of confusing explanations of that term. In the book I helped write, we liked to give a lot of examples of these. For example, flatMap appeared a lot in today’s talks, but it was called push and andThen, and we also saw the question mark operator. And so, in the book, we tried to avoid these words until the final chapter, and only then explain that all these things were a monad. Basically, a monad is any kind of type, for example Result or Optional, that implements the flatMap operation. That’s the short explanation. If you have any type that conforms to flatMap, you have a monad.
Q: Swift has had a massive impact on iOS development. What are your favorite parts about Swift?
Brian: The part that I like the most is probably how Swift allows you to write fluent interfaces. It lets you do that out of the box, and fairly easily. When you build those in Objective-C you end up with a ton of brackets everywhere, and Swift allows you write those without a lot of glue code or block properties. That’s great.
Ayaka: One thing that I very much enjoyed is the fact that Swift really opens up the doors to other types of developers to join the existing community. I’ve had a chance to watch WWDC videos with Java and Ruby developers and geek out over all these new language features, collaborate and learn new things with them.
Chris: I really enjoy the tension between expressiveness and low level-ness, so we can write really fast code in Swift and still have it be super expressive. For example, as we saw in Airspeed’s presentation, you can reduce and still end up with massively fast code. I think this is super cool, and the team that is pushing all these expressive features like the nice type system is the team that built Clang and LLVM, so they know how to make it extremely fast. I think this is just the beginning, and Swift will improve in both ways. It’s already come very far, and it’s a lot better than most languages.
Airspeed: Swift has learned all of the good things that people have loved about their languages, and so anyone who comes to Swift comes with a positive mindset, because they see in it all of the things they like about their favorite languages. For example, Ruby developers like it because they see this easy block syntax that they’ve been used to, and C++ programmers see generics and compile time polymorphism, which are things that they’ve been trying to fix in C++ for all these years. Swift really has absorbed all of the advancements, like how C# looked at Java and thought about how they could do a bit better, and thus became a very powerful language. Swift takes it that little bit farther - it’s slightly more functionally expressive, and also more optimizable or low level capable than other languages.
Q: Will Swift become a backend language? Javascript is making waves in backend development, but will Swift ever have an impact?
Airspeed: It already is a backend language. What makes it not a backend language, apart from the platform? I think the reality is that the only impediment to this is the need to run it on the Mac platform. That’s the only reason why it wouldn’t see widespread adoption.
Chris: The last month I have been writing a Rails backend for a new app, and in the past, I also used to use PHP. The really nice thing about the Rails backend was the great infrastructure, like Heroku, so you didn’t have to think about server management. With Macs, I don’t know how to do that. I think it’s super easy to write a web server in Swift, but the thing is, the infrastructure is really lacking still. Once this is fixed, Swift could be super powerful on the backend.
Colin: There are probably a lot of people here who would like to see it, but I personally don’t see it happening. Swift has a fantastic niche in iOS development, since it is targeting one product. I just can’t see it being used for server-side programming, other than potentially to write APIs for iOS apps. Javascript already runs on the web, on the server, and practically everywhere, so it has and will continue to have the most impact on the server.
Brian: I just want to comment on that: even with developing for iOS, there is a major limitation. The fact that there aren’t really any good solutions for CI, having a Mac VM or a better platform to run these things would be amazing for iOS development. That would open up Swift as a server-side language.
Q: Tell us some of the things you don’t like about Swift.
Brian: Everything that I mentioned before about not being able to interact with the XCTest API is a major oversight. There are other things related to testing that make me red in the face just thinking about them, because it’s so aggravating. Like the fact that there is no way to test whether Swift code raises an NSException. The only way to do that is to write some bridging code, where Swift calls Objective-C, the Objective-C does a try-catch, and reports the results back to the Swift.
Colin: That’s a big problem because you’re writing in Objective-C. If you’re writing totally in Swift, would you want an NSException?
Brian: That’s my second point. You can write a function, for example, that adds two numbers, and you can have a precondition that says both of those numbers should be positive, but you cannot write a test that ensures that when those numbers are negative, your app crashes. What the Swift team is telling us is that you can test your code but only so long as you are testing the happy path. If you want to test things outside of your preconditions, like edge cases, good luck with that! Your test suite crashes.
Ayaka: This is a tough question for me, because I’m pretty positive about Swift in general. I definitely do get irritated when there are compiler errors, or other things that don’t work with the compiler. I just want the kinks to be sorted out, and I think that the Swift community and the Swift team at Apple are very open about this, they’re always fielding issues and responding to questions. Some people complain every time their project breaks, but I think it’s really exciting to see Swift evolve, and to feel like we’re part of the process, seeing the changes as opposed to reading about them.
Chris: I agree with the tooling part, there are still a lot of broken things. What makes me sad about Swift is that it also creates a lot of controversy and tension between people. For example, I really like functional programming but I don’t think it’s the main solution. Now, because it’s possible, I’m really excited and I want to talk about it, but I’m never saying we should ditch all the other paradigms, like OOP. It makes me sad that people get scared of a new language, and then you have people who want to do it differently. This is a side effect of Swift that I don’t really like, but I guess it’s natural to change.
Colin: It’s interesting to note that none of you have said anything about Swift itself, but instead the things around it.
Ben: I don’t think there’s anything to dislike. It’s just missing features, whether that’s stability in the compiler, or the runtime performance which needs to improve, and so on. I think it can get better, and it’s still only version 1.2, so it’s a very early product. I feel the pain of people who get frustrated when they have to update their products, but everything is still changing. It’s important for Swift to stay malleable, and I think it was actually a really bold move for them to release it when they did, at such an early stage. They got a lot of flak for that. I think the fact that we were able to look at it while it was still forming, and give feedback, was really open compared to how they could have done it. We wouldn’t have had nearly as good a product had it been developed internally for years, and then suddenly emerged fully formed. Likely it would have had more things we wouldn’t like about it, coupled with fewer things we could do to change it.
Colin: None of you miss more runtime dynamic behavior? Not reflection or introspection? Say you wanted to write an object relational mapping, or a framework that would render a form based on some data. Do you miss that?
Airspeed: All major languages eventually evolve, so I’d be pretty surprised if it didn’t come. What form it comes in might be more interesting than in other languages, but I don’t see why it can’t come. The fact that they control the runtime, the compiler, and the language itself means that they can evolve the language to make reflection practical. I would assume that, at some point, it’s going to come. I would be amazed if it didn’t.
Chris: There are a lot of ways we could do reflection. If you look at Haskell, what they call generics is not what we call generics, they have a typed way of doing reflections which is a really nice way to deal with this. You don’t have to do as much at runtime, and you can move part of that to compile time, which is what Swift is about. I think there will be some interesting ways in which they do reflection. What I like about them not doing it yet — although I would like it — is that for now we need to solve our problems in a different way, for example with types. This will help us weed out the unnecessary uses of reflection.
Q: Is Swift ready for production?
Brian: I think it depends on your definition of production. If it is an app that you will enjoy with a small number of friends, then really, it could crash every day and you wouldn’t mind. Even then, I don’t think Swift is necessarily not readily. Ash Furrow gave a great talk at dotSwift that spoke to the perils of using Swift in your development process, and one controversial slide in that said to expect double the development time. If you’re going to spend double the time on development, that probably isn’t good for your users. But otherwise, I can’t really say whether it’s good for production or not.
Ayaka: I’ll answer with a question, is Objective-C ready for production? [Audience laughs]
Chris: Like I said, the app that I’ve been working on is purely written in Swift, but I’m actually more afraid about the backend part.
Airspeed: I think the question should be, is Swift ready for development? One of the things that’s interesting is, obviously, that people have been frustrated with the instability, especially in the very early beta versions. But the reality is that none of that comes along once you ship your code. I have not heard of any problems where it does not run flawlessly in production as an application. Maybe there have been cases, but they haven’t been big cases where they get a lot of attention, so really it’s a question of, are you ready to do your development in Swift? It’s difficult to disentangle when Ash says you’ll spend twice as long; is that because it’s something you’re not used to? Or because of the tooling? It’s probably a mixture of both.
Q: Is Swift functional?
Brian: This is something where I’m more curious about how the audience feels. Do they think Swift was a language that was designed for functional paradigms? I think that thought is mostly due to Chris and objc.io. I read their book and my eyes opened to the possibilities.
Chris: Well, if we hadn’t written the book somebody else would have done it. It was very difficult when I switched from being a Haskell developer, and I did not enjoy programming for two years. I started really enjoying Objective-C again after I realized I didn’t know anything about it, and so, when Swift was announced, I was reading about Swift on Twitter and got so excited because we could finally use all this functional stuff that I already knew and loved. We will still use objects and OOP for things like view controllers. The nice thing is that it’s not really a question of whether we will do functional programming because Swift allows for it. We can really choose our own path, depending on what we or our team is comfortable with.
Q: Will Swift replace Objective-C completely in the near future? Do you think Apple will eventually focus all of their efforts on Swift?
Ayaka: Completely, no. I feel like there will be some Objective-C lying around somewhere that someone will be using. There are a lot of companies that have very large codebases in Objective-C, so I think we will need some kind of backwards compatibility.
Airspeed: I mean, it could be worse, you could be a Microsoft developer. They’ve managed to get themselves into a situation where they have four mainstream languages simultaneously: C++, C#, Visual Basic, and F#. I think we’d be lucky if it was just two, and besides, they’ve done a really good job at making them interoperate. It’s not completely transparent and there are some tradeoffs, but the fact that they can so seamlessly interoperate together means they can coexist for as long as they need to.
Q: With two minutes left, let’s ask some of the sillier questions. Can anyone else name another Taylor Swift song, besides Shake It Off? And why is a monad like a burrito?
Brian: I don’t know, but the question made me angrier than the XCTest things.
Ayaka: Is the second question because I said that briefly? I think there’s a joke that once you know what a monad is, you lose the ability to explain what it is without using crazy analogies like, “It’s a burrito, wrapped in a cabbage!” or something.
Colin: And I think that’s a great answer to end on. Thank you to all the panelists!
Airspeed Velocity, Ayaka Nonaka, Brian Gesiak, Chris Eidhof, Colin Eberhardt
Featured News
Receive news and updates from Realm straight to your inbox