Open Sourcing Swift
...and “What's In It For Me?”
Editor's Correction: The video title lists Thomas Hanning, but should say Thomas Visser. We're getting the video fixed asap, sorry about that!
Greg: Way back, Objective-C, Swift, we've always had a really good tradition of open source software within the community and Objective-C itself has been open source for a long time, GCC Compiler, Clang, LLVM, all of that stuff. I think one of the most exciting pieces of news at WWDC this year was that Swift was going to be open sourced, it got a lot of cheers from the audience. So what we want to do over the next half hour or so is talk about reactions about Swift itself going open source, maybe some predictions, and of course, the importance- Everyone's favorite radio station: WIIFM, “What's In It For Me”, and what are we going to get as regular Swift, iOS, Mac, and other kinds of developers, too.
Q: As soon as Swift gets open sourced and you download the repository, what's the first thing that you're going to look at?
JP: Right. That's a great one. I think the very first thing that I'll try to do is to see if the code that I have that leverages some private, completely undocumented, reverse engineered Apple stuff still works with the official stuff. Because that's always been a hack and it'd be nice to move away from that.
Really hoping to get an insight in how we can make value types in general that are as good as the standard types.
Thomas: I'm really curious to see how they implemented the standard library. I'd really love to see how they made collections, the string, etcetera. Really hoping to get an insight in how we can make value types in general that are as good as the standard types.
Boris: I would be most interested in how @NSManaged works, but I guess it won't be in there, so I'm not sure. Just checking out the interoperability stuff with Objective-C, I think, would be interesting.
Veronica: I'm most interested in whether people are opening issues. Currently, Radar isn't public. You can't see other people's issues being opened, so I'd like to see whether issues are now public and if Apple is responding to them publicly. I think it's a really good way to tell kind of the culture owned open sourced project is looking at those things.
Q: That's an interesting point you brought up about the standard library, Thomas, and about what that's going to look like. We've had core foundation, the C part of it has been open sourced for a while. CFLite, you can get that from the Apple open source page. But how much of the standard library do you think is going to be available with the language?
Thomas: I'm thinking that at least the standard library, the thing that we now have to bundle into every release we do, I think that part is going to be open sourced. Foundation? I'm not sure. I'd say that we might wanna think about making open source software without NSString and Grand Central Dispatch, to make sure that it will work for other platforms that will be able to run Swift.
Greg: JP, you were mentioning some of your “hacky" codes. What are some of the things that you've been looking at to add to the... Things that you've been adding to the language already?
...A lot of that internal tooling is going to be extremely useful in helping the community take the next steps with the language
JP: So if you look at the Objective-C side of things, there's been a lot of the more fundamental components of it, the tool chain that has been open source for a long time, and I'm sure that there are Swift equivalents to that. So for example, Clang, LibClang, it'd be great to see if they supported Swift support as well. I just suspect that a lot of that internal tooling is going to be extremely useful in helping the community take the next steps with the language, rather than just hope that Apple, who are the only ones with access to this stuff at the moment, that the community is really going to be able to pick it up.
Q: Veronica, you mentioned the issues in filing radars and things like that. Considering Objective-C has been open sourced for so long, what kind of difference do you expect to see between, say what Objective-C is like as an open source language, and what Swift is like? Do you have any experience with filing issues against Objective-C and things like that in the past?
Veronica: I don't have experience filing that in the past. I think it's a large cultural change for Apple to kind of make these issues public and to be more transparent about what they're working on. I think from what Microsoft did with open sourcing a lot of projects recently, and having projects that were source open in the sense that the code was publicly available but they weren't responding to feedback from the community, I hope that Apple will be different, however, I don't have a good model for other companies that have done things differently.
Q: Okay, and as we sort of diverge from Objective-C, again thinking about the interop, bridging, things like that- do you think that open sourcing Swift is going to increase or accelerate the pace of that divergence from Objective-C or keep it the same? What effects do think that's going to have in terms of us developing Swift and still having to deal with Objective-C? Anyone feel free to jump in.
Swift is heavily reliant on the Objective-C runtime
JP: Well, at the moment, as Andy was saying earlier today, Swift is heavily reliant on the Objective-C runtime, and the fact that the Objective-C runtime is open source. I don't foresee Apple really going through all the effort to decouple it from that when it's really more of an asset than a liability, although it's also part liability. The fact that the Objective-C runtime is already open source, I'm sure there are parts of Swift that currently rely on closed source parts of it, but I don't think it'd be necessarily a far leap to, say, require the Objective-C runtime for parts of the Swift functionality.
Thomas: I think there's going to be an interest from the community to get stuff going to make Swift more valuable stand alone, outside of the context of Objective-C. Maybe even in the end, language changes that will make it seem less like Swift is built to be compatible with some weird aspects of Objective-C.
Veronica: One thing that's interesting to me is looking into Swift's limited meta programming capabilities compared to Objective-C. Other speakers have mentioned today about how, for example, core data relies on the Objective-C runtime and could not be written in pure Swift as Swift stands. So I would love to see pure Swift alternatives to a lot of these core technologies we use, or yes, changes to Swift to enable pure Swift implementations, say, of core data.
Q: Apple's usually been traditionally very closed, let's say, to put it nicely about these kinds of things. How closely do you think they'll work with the community in terms of things like pull requests, or how open will they be to contributions and things like that? What are your thoughts on that?
Boris: I would hope they do it a little bit differently, and I think during WWDC they also mentioned that they want to take contributions from the community. But I think it's also going to be reliant on what kind of stuff the community will contribute, and if Apple sees that as helpful or not in the beginning. But yeah, I sure hope that it's gonna be on GitHub.
I think there's some great opportunities for the community to contribute to the standard library
Thomas: I think there's some great opportunities for the community to contribute to the standard library, because since Swift came out we've seen multiple alternatives for the same concepts arise from open source software. For example, there are a lot of futures libraries, there are a lot of result type things, signals. I argue that those types, those concepts, should be in the standard library.
JP: I think we'll see an interesting dynamic playing with the different components that are going to be open source, so Apple is committed to not only open sourcing the Swift compiler tool chain, but also the standard library. The compiler tool chain is mostly C++, the standard library is, allegedly, all Swift. So I see Apple taking a very different stance on their approach to open sourcing both, where I think it'd be very feasible for them to upstream the Swift compiler tool chain back into LLVM and Clang and continue to work through the mailing list space process, which is actually very open even though it doesn't look like a modern tool like GitHub, it's still a very open process where anyone can contribute, it just looks a bit dated by our modern standards.
But that they would take a different approach for the standard library where they'd actually encourage Swift developers to contribute to that maybe in more of an interactive way, and one of the reasons why I think of this is that most Swift developers are Swift developers, not C++ developers. So in practice, I'm not sure if Apple going completely out of their way to make the compiler tool chain super easy to contribute to in a very collaborative community aspect to it, would really pay off, and what they've done with LLVM in the past doesn't really align with that.
Q: So in terms of tool chain, what kind of things are you looking for? Once the tool chain is open source, for example Apple developing Clang and LLVM putting that under their umbrella was driving forward a lot of innovation in Xcode itself, but what kind of things do you think the community will come up with once they have the tool chain available in source code?
Everything depends on Xcode right now. I guess there won't be Xcode open source alternatives
Boris: I guess the first part will be to actually make it usable, because everything depends on Xcode right now. I guess there won't be Xcode open source alternatives. They also said that Swift is going to come to Linux, there is no Xcode, and so I guess the first step would be to actually figure out how to feasibly build larger things.
JP: From a tooling perspective, a lot of the baseline architecture and the plumbing is in place with the existing LLVM project, and I wouldn't be surprised if internally swiftc is really just maybe a fork or a layer on top of LLVM and Clang. So I picture that being merged back in, I don't really foresee Apple making a tool that will let you parse an xcodeproj file or an xcworkspace file on other platforms. So we can have an alternative to Xcode, much in the same way that you can compile Objective-C on any platform at the moment, and you can just pass in the Clang compiler parameters.
That was sort of one of the questions that one of my colleagues asked me: "What's gonna happen with CocoaPods?"
Q: That was sort of one of the questions that one of my colleagues asked me: "What's gonna happen with CocoaPods?" If you have all of these Pod files, they rely on a project file in the workspace. What kinds of things do you think we're gonna have- Is that gonna help or hurt the third party libraries that are out there right now in Swift, getting them to work on something like Linux? Do you think that's gonna be a big deal, a problem or something that people are gonna actively try for, moving forward?
Boris: Well, I guess having Pod specs helps a lot, because they are independent of Xcode. At first, everything is there to build a tool, to be able to build Pods on Linux, or whatever. Currently it's very tied to Xcode, but that is not a necessity and the library developer doesn't necessarily have to do much, because the Pod spec is already there and already documenting everything in a more platform-independent way.
Q: I had a quick look, just out of curiosity, at some of the stats. I looked at the LLVM repository, there are about 200 contributors, 100 people had thousands of commits. Clang was about 224, and about 10 people had thousands of commits, heavy contributors. So, realistically speaking, how much uptake do you think this is gonna take? Is it just gonna be people browsing around the C++ with a curious look on their face? Or what kind of actual contributions to the source trait itself do you think we're gonna be seeing, moving forward?
JP: Again, I'd look at the compile side and the standard library side as two very different parts. I think in practice, most Swift developers would want to contribute more to the standard library because then they're writing Swift, and it's probably at a level that they understand. You don't have to be a compiler engineer to work, necessarily, in the standard library. So, I'd expect most of the uptake to be there and most of the interest to be there and honestly, most of the value to be there. You'll probably have a lot of people that are finally paying attention to those lower level compiler tool chain side of things, but I don't expect too many people to really put in the massive effort that it would take to land a patch in there.
Thomas: I think quite a lot of people have run into issues with Xcode or any of the other tools, especially with a Swift tool chain, and instead of working on a workaround, that same effort probably can be made to just make a patch, or at least the people who are interested in that area will now have the opportunity to actually fix it.
Veronica: Yeah, and also people coming to Swift from other languages or people who have the interest in other styles of programming. For example, I have a background in Scala and I'm into functional programming. I'm very well aware of how Swift does not have a lot of key functional features needed to do code that me and other people interested in that want to write. So, people who have a very strong interest in a certain style of programming, or just there's a feature that they feel Swift needs, those people who really care a lot about that, I think, will be making contributions.
Boris: I think there's also a benefit that goes beyond making contributions. At the moment, a lot of swiftc is pretty in-transparent and not really documented, so it will already help when you can look at things and see how they actually work, and people can document them outside of Apple. Then there's also the whole part of supporting additional platforms, if you think about Android, Windows maybe… But, in general, taking Swift to other platforms that Apple is not going to support.
Yeah, too bad Microsoft just started supporting Objective-C too as well, right? So it's too bad for them
Greg: Yeah, too bad Microsoft just started supporting Objective-C too as well, right? So it's too bad for them, but they can jump on this bandwagon pretty quickly.
Boris: I can definitely see people trying out sharing code from the iOS app on the server side. But, we'll have to see how much, on top of the standard libraries there, so probably a lot of foundation needs to be built first, there's probably no HTTP handling and stuff like this, so we'll need to build that up. But then, I can totally see people wanting to share code between the iOS app and their server.
Thomas: It seems like Swift is also a good language to write command line tools, for example, Carthage is written in Swift. And those command line tools will be useful in a lot of other platforms, including Linux, so I think that we will see that definitely.
One of the ways that I see cross-platform Swift development taking off is...
Veronica: So when they made the announcement, after WWDC as a former web developer I was very excited to see if somebody would write the first web framework in Swift. Looking around, there was one project that very few people knew about, that was on GitHub already, that someone had written. Yeah, I am agreeing with JP here, I don't really see that being the most popular thing, people writing their whole web applications in Swift, if the tooling is there, and if people who program in other languages get exposed to Swift and see how awesome it is, I definitely see it becoming more popular. However, I think the small code sharing is going to be where the most utility is and where it would be most common to begin with.
Greg: We're also going to take questions from the audience. If you have a question for the panel or you have a very, very brief statement that you would like the panel to react to, then we'll go ahead and do that for a little bit.
Audience Q: If you had to guess, what day do you think Swift will be open source?
Greg: I was saving that question for the end, but yes let's get to it. Whoever comes the closest, I will tweet you the bag of money emoji on the panel.
Boris: My guess would be right before Christmas, like 20th of December, so that they can keep the, "This year," approach, like promised, but I don't think they wanna work over Christmas, so.
Veronica: I was guessing before Thanksgiving for a similar reason, just because I'm optimistic that they will finish faster, but same idea. If they don't finish it before Thanksgiving it's kind of all downhill from the rest of the year.
I think it's gonna be the 5th of December, because that's a national holiday in the Netherlands where kids get presents.
JP: Yeah, I'm with Boris on this one. I think it's gonna be as late as they can possibly do it, hopefully without any of the Apple engineers or marketing teams having to work during the holidays, so I'd say right before Christmas.
Greg: I’m on record already on Twitter as saying: today or tomorrow, because the LLVM Conference is going out, and that was my pick.
JP: They actually just open sourced part of Common Crypto and the security framework today.
Greg: I'm this close. Get your money bag emojis ready, everybody. It's gonna happen today or tomorrow.
Audience Q: Ash mentioned in his talk that we as a community are just learning, we're stumbling and learning from our mistakes and what not. How do you think we as a community, as software developers, won't run into the same... I don't want to call it mistake, but the same path that happened with Node where you had Joyent leading, dictating what was becoming of Node.js and then we had this fork with io.js that eventually ended up merging back to Node. How do we as a community prevent that from happening, given that we have no say of actually what will go and won't go into the language? And to follow up, will something like protocols and extensions prevent those from going down that path?
Veronica: One nice thing I would say of having a steward like Apple, a large entity, being a steward of the open source project is that it is much less likely for it to stop being maintained. Okay, Google made backwards incompatible changes with Angular, so backwards incompatible changes can happen, however, large forks are things I do not predict with having a central entity like Apple. On one hand we will not get as much input as if we were kind of collectively owning it, and not one entity like Apple driving it. However, we do have a nice sense of knowing that the project isn't going to necessarily fork.
I can foresee a future in which maybe a large company…Hm-hm- Facebook, might actually want to fork Swift and to have their own version that's hyper-optimized for the specific use cases that they have
JP: I'm actually not that optimistic about it. So I agree in practice, but I can foresee a future in which maybe a large company…Hm-hm- Facebook, might actually want to fork Swift and to have their own version that's hyper-optimized for the specific use cases that they have. One of the major issues, and I can't necessarily quote anyone directly on this, but I've heard people at larger companies say that one of the reasons why they hesitate with Swift adoption, even just putting in one line, is that you have to drag in all of these fairly large dynamic libraries. And so, for that reason, and maybe many others, large companies might be actually interested in having their own forks, especially if they have to ship those dynamic frameworks anyway. So if they have control over that, and it seems like that might actually be the case, then I would foresee a world in which some people are running slightly modified versions of Swift. But, I do agree with Veronica that in practice, it's probably not going to be a widespread thing where you have half of all of Apple developers are using one version of Swift, and then everyone else is using kind of a community-driven Swift version.
Audience Q: My question is, especially to Veronica coming from the Scala community, and I'm sure there are other people coming from other functional languages. What is the language feature you think Swift is most missing and that will, maybe, get picked up once it becomes open for contribution?
Veronica: Well, my talk tomorrow morning will tell you just that.
Audience Q: I'm very interested to see where Swift goes on Linux. I think, it would be a great language to write APIs on the backend in the future. My question is, what do you think about that as a possibility? How do you think it can compete with Scala or Go?
JP: That's a really, really deep and good question. I think to really have a major part in that market, in the non-Cocoa development market, by Cocoa I mean Apple development platforms. I think we'll need a rich set of tools and libraries that aren't just Apple platform-specific to really build, and those will come over a large period of time. So I don't think it would happen overnight, even if everyone was interested in doing it, because there's a lot of stuff that would have to be built for that. And even then, Swift isn't always going to be the right language for every possible use case. So, we're probably better off not trying to make it do anything and everything, and really just being honest about what the language is good at, and really leveraging that so that we can focus our energies rather than spread them. That's my opinion.
Veronica: I generally agree with that, however, I think that Swift, at least, is fast enough, or can be fast enough so that it can be somewhat of a competitor, and I think Apple sees it that way. But I agree that spreading ourselves too thin and trying to be the language that can do everything, I don't think that is the best route. And we really need that tooling in place for it to even be used, let alone be extremely popular, for completely different applications.
Thomas: I think that at WWDC when they introduced Swift, they said that it could be anything from a scripting language to a language that you would write your operating system in. It would be great to see Swift living up to that aspiration.
Audience Q: So, I'm interested what your guy's thoughts are on the possibility of using the new open source Swift stuff for embedded systems in particular?
JP: That’s actually really related to what Thomas just said about having a language that can scale all the way from the lowest levels to the highest levels, and I do think Swift has that potential, but we're really talking on a longer scale here I think, on the order of years. The way I see it is that... Well, actually I should probably just prefix this with a bit of context: I recently heard that the embedded processor that runs on iOS devices and watchOS devices that runs some of the more financially-important Apple Pay information, so it's called the Secure Enclave, I think, actually runs a compiled version of Java, and so, if you have that running on an embedded system, I'm sure that Swift is actually going to be a lot better for that particular use case. So, I will see it eventually.
Q: What sort of direction do you think Swift is going to take in terms of if Objective-C didn't take up... Well, maybe it's a tall order here, but if Objective-C didn't sort of spread beyond Apple, what is it about Swift that seems to get people excited and why is there this expectation that Swift is going to take over on the server side and other places like that? What is it that's different about it compared to Objective-C, seeing as Apple has gone down this road seemingly before?
JP: The standard library. Writing Objective-C without NSArray, without NSDictionary, without all of what Foundation gives you, gives you very, very little; whereas that was the most exciting part of Apple saying they were going open source Swift. If they had just kept it at that, I think that we'd be having a very different conversation today. But since they said they'd open source the standard library, that let's you do a whole lot more, even if we don't end up getting the foundation bridging parts of the standard library.
Boris: I would also say that while Cocoa is a really great framework, I don't think Objective-C was ever that compelling to use instead of a different language you had, which probably also had a better ecosystem. Like why would you have used Objective-C? Whereas Swift has a more, it's a very modern language, there are others like it, but still it's not this odd ball that nobody really wants to use, but kind of has to.
Boris: I would say the io.js example is rather one where a fork worked well. They had a fork that was faster in development, and then, at some point, they couldn't merge it back in. So it’s something like this that I don't think is necessarily bad. So, having a fork that can move faster than one release per year, might actually be interesting.
Q: So you think we're going to go beyond the yearly major release version of Swift, because of community involvement? Or do you think Apple will still say, "No, we're gonna hold back on these commits and not take as many pull requests." What are your feelings on that?
Boris: I doubt that Apple will change so much in that regard, that’s how it functions. But I could see there being a fork that is used in-between each yearly major release, having some little features, and then at some point they get merged back, and then everyone can go back to using the official Swift.
Audience Q: What are your general thoughts on the Android community developing Kotlin? That's pretty much like Swift, but for Android.
JP: I think Kotlin's great but it's a distinctly different beast. What Kotlin is to Java, I wouldn't necessarily say Swift is to Objective-C. Kotlin is not going to replace Java anytime soon, even though a lot of people would prefer it did, but you don't see Oracle or Google really championing Kotlin over Java, right? It's more of a community effort, whereas with Swift it's really coming from above. It's the word of Apple and Apple is saying, "This is the future." Yeah, so the situation is a bit different, but from a technical standpoint they do share a lot in common where Kotlin is kind of like a breath of fresh air into the landscape.
One of the things I'm most excited about is (..) how much Apple has been investing in Playgrounds, so much more than I had ever thought.
Audience Q: One of the things I'm most excited about is embedding some Swift into web pages, or even just seeing how much Apple has been investing in Playgrounds, so much more than I had ever thought. I get really excited about the idea of someone perhaps bringing those to Linux or Windows as well for that real-time idea of programming. Do you see something like that happening?
JP: I could totally see that happening. So, LLVM has JIT support for Swift, and that's how most of the scripting and Playgrounds stuff works. JIT being the "Just In Time," compilation, so it doesn't have to pre-compile the whole Swift stuff, you can just kind of stream it in. I'm not a compiler engineer, so I'm getting all this wrong I'm sure. But the tricky part, I guess... So there's a few things. To get this to work on the web, maybe it would work in web-kit based browsers where you can have this LLVM JIT working at the same time, so you can leverage that already being in there. But, Swift being able to be compiled and ran on something that's not LLVM is really far out. I think you'd have to completely replicate the entire stack as far as I can tell, so that'd be very tricky. So, no, I don't really see Swift in the browser taking up any time soon.
Veronica: I am also super excited about Playgrounds and how much Apple has been investing in it. I think it would be a very smart move of Apple to create a cost platform kind of Playground standalone independent of Xcode. I think it offers a lot of value independent of developing iOS in the Xcode environment. I think that would be a very smart move by Apple, and I would hope they do it. But yeah, we'll see.
Q: All right, let me ask, finally. I am not a compiler-engineer, and I am not going to contribute to the open source Swift, let's say, the standard library, or anything like that. But I'm a regular iOS developer, a Mac developer, What is in it for me for Swift, why should I be excited about Swift going open source?
Veronica: Oh, you should be excited, because if Apple is more transparent in terms of showing issues anyone files, and you can see Apple's response to it, that is huge for you as a developer, even if you do not contribute to Swift at all.
Boris: I would say, seeing the source of the standard library is valuable for everyone.
Thomas: I think that if we as a community can shape the form of the language, and the standard library. That we get a richer environment from the get-go when you download Swift, and start using it on your Linux machine. That is an improved experience for everybody.
JP: I was going to say exactly what Boris said, so I'll add something else. People who are going to be contributing to any part of that stack can still benefit from the tools that the rest of the community will be able to build from that code being out there, and just the general community having that know-how, that will shape the community moving forward.
Greg: All right, cool. I wanna thank you all for your very thoughtful questions, and thank you to the rest of the panel for joining me. JP, Thomas, Boris, Veronica, thank you very much.