In episode 1 of the new Swift Community Podcast, Chris Lattner, Garric Nahapetian and John Sundell, talked about Swift's origin, among other things.
This is a transcript (edited for readability) of the parts I found most interesting. You see that I mainly quoted Chris Lattner because I think his account of how Swift was created is the most relevant to preserve for posterity. That's not to say that what John and Garric said was somewhat less interesting. You really should listen to the entire episode – it won't take much longer than reading this post anyway.
Swift Community Podcast is also worth checking out on its own. It is very meant as a project where some can contribute in different forms (the three go into episode 1). In this spirit, I worked to create the transcript in the open, and even received help from the community in the form of code and in the editing of the machine-generated transcription. Thanks to everyone who helped!
You can find complete transcription on GitHub (in WebVTT format). The entire podcast is licensed under CC-BY 4.0.
Chris Lattner: I have to go back in time to WWDC 2010. We have just launched C ++ support in Clang and that was a large, large, large amount of effort for tons of people. And I both felt very happy with it, but also a bit burned out because it was a lot of very nitty-gritty work. And you can't implement C ++ without thinking, "Gosh, there should be a better thing out there!"
And then I got into a number of conversations with a guy named Bertrand Serlet. Bertrand was head of the software community at that time, and Bertrand is an exceptional engineer. He is a wonderful person. He is also a bit of a language fan. And he had pushed to make Target C better. He always wanted more out of Objective-C. And he and I entered a number of one-on-one whiteboard sessions.
At that time, Swift was called & # 39; Glittering & # 39;.
Bertrand ran all the software at Apple, so he had no time. But he always encouraged me to get off at the end of the day and try to see if he is available. And he would be late and we would geek out on the board. We talked about lots of different things: the goals [of a new language] weird details like the type system, and finally we changed it to a pitch deck. So I built the pitch deck for him and came up with this idea of building a new language. At that time, it was codenamed "Shining" as if "you are building a shiny new thing". I was also a fan of the Firefly TV show.
John Sundell: Was the file type
Chris Lattner: Yes, actually it was. You know, at that time it was super little. It was really just Bertrand and I talked about it. Another truly amazing engineer named Dave Zarzycki became involved in some of the early conceptual discussion.
One of the things that came out of it very early was that we started talking about memory management. At that time, we were both convinced that it would be a good way to solve or improve memory management, and we needed to get to memory security. Therefore, you need automatic memory management.
The goal of automatic memory management was the origin of Swift's internal design discussions that became objective C functions.
One of the most important things that came out of it was the ARC and the idea that we could own the compiler and run this instead of having a runtime. Goal-C had this libauto garbage collector at that time, but it had a lot of problems. There was talk of the origins of Swift's internal design discussions that became target-C features. And many of the things that came out, including ARC and modules, and even letters and things like this, really came from Swift's back development.
John Sundell: So there were a bunch of features that you had in mind for shining and what later became Swift. But you said, "we won't wait until we have a completely new language fully implemented. Let's move on and take on the features we really want and just add them to Objective-C."
As part of the ideas process behind to build a new language, you always have to ask the question, "why not make the existing thing better?"
Chris Lattner: If you think about it from a different perspective, Swift can work obviously now, but at that time it wasn't quite clear to anyone, and even me, Bertrand was, and is very good because he is always super encouraging, and he always pushed through the doubts. Bertrand is a bit of a scientist. Find the Truth in Many Ways So yes, there are tons of uncertainties, but at the same time there are many good ideas, and so, as part of the idea behind building a new language, you have to always ask the question "why not Make the existing thing better? "And the answer was" clear, we should do better the existing things ". And then the ARC and all the other things that came out of it happened.
But in the case of Swift [the tentpole feature] was memory security. And you can't retrofit memory security in Objective-C without removing C. And if you remove C, you lose too much and it won't be Objective-C anymore.
Garric Nahapetian: Right. Then it was a bit like a Trojan horse to add these Swift features to Objective-C, which then made it easier to convince Swift people later, as you had already done Objective-C?
Chris Lattner: [There were] interesting internal dynamics. I guess we were very focused on making Target C and the platform better. When it comes to the swift development, there was a way to risk in a way, because if you say, "We'll roll out all at once," and none of it is tested, then it's hugely risky. But if you roll out "smaller" things, like a brand new memory management system, separately and then iterate, debug, and develop it with society, then it takes some risk away. But I would say that both the external and the internal community at Apple were kind to say, "Why do you prioritize this? It feels like we're kind of a casual stroll. Why are you doing this and not this one?" It is an interesting dynamic with it.
(Starting at 22:49)
Chris Lattner: Apple has a very strong engineering team. There were lots of people at that time, all who are writing Objective-C, who are very satisfied about things, but also have great depth and background in building frames, apps and all such things. And then there were many ideas on how to make goal C better. There were large white papers written by light fixtures that had worked since the NEXT day on these things. And then there was a huge internal community that ran it.
At that time, Bertrand and Dave and I talked about ideas, and I started to tag a prototype of the compiler. But of course I couldn't build everything myself. And so what happened was, around April 2011, we discussed Swift with the management and agreed to pull in a few more people. This is when people like Ted Kremenek Doug Gregor and John McCall and a number of other exceptional engineers over time, were withdrawn. And looking back on it, it was very interesting because this was the first time other language and design experts took a critical look at this. And they had a lot of very hard feedback. It wasn't meant to be hard, but they were right. That [the language] was terrible at that time.
And [having] the ability to have one of the world's experts on generics recorded in this and the team that had built the Clang compiler and had worked together for many years on many different, really interesting projects, to draw on the technical talent was important to make everything happen. And these are just a few of the people who helped drive and build it. But that was a big deal.
John Sundell: What was the state of the language at that time? Like, how did the syntax seem? What part of the compiler infrastructure was there? Was it very much in the prototype phase, or had you come a little further together at that time?
Chris Lattner: It was very much in the prototype phase. This is all public because the audit log is public. There is a changelog that doesn't go all the way back, but quite a way back.
Before Doug became involved, there was no generics system. We wanted the generics system, but I do not have the skills to design it myself. And Doug is the guy. John, I remember very early, took over to create actual code instead of just being a parser. It was a big piece he took on.
There were tons of missing pieces, but there are also pieces that go all the way back. I think
funcdates back to the beginning. Some of the basic syntax ideas are very, very similar [to what you see in Swift today].
When building a new thing, the ideas are often in front of the documentation and the documentation is in front of the code. It was very like that. And the ideas are so far ahead of the code right now, by the way.
So it was very much a prototype. But many ideas [were already there]. When building a new thing, the ideas are often in front of the documentation, and sometimes the documentation is in front of the code. It was very like that. And the ideas are so far ahead of the code right now, by the way.
(Beginning at 26:10)
Chris Lattner: Another part of the community that was very important was a man named Craig Federighi. Craig is known in the Apple community. He was involved in the project ever in early 2011. It was right when Bertrand retired from Apple and Craig took over his job.
Now Craig is a really, very interesting person. He is super charismatic, both on stage but also in person and in one-on-one. But what I think many people don't understand is that Craig is just ridiculously smart. And he is super deep on so many topics. And I don't expect this, but he knows a lot about languages. In previous roles he has worked with Groovy and many other types of languages and things I had not come into contact with. And he's not just the tall guy who cares about strategy. He also cares about tons of things, such as syntax, keywords, all kinds of things.
And Craig was really the hard driver and lawyer to really do it and make it relevant to Objective-C and meticulously target -C develops and cares for the APIs and cares what the APIs imported into Swift look like, and All that. And Craig, as well as providing good feedback, just kept, and holds, a very high bar on the team and project. Chris Lattner (19459008) That's pretty cool because he was the one who first announced it on stage at WWDC 2014.
Chris Lattner: Yes.
John Sundell: And then he took you out, right? It was the classic line: "Goal-C without C".
I have mixed feelings about "Objective-C without the C" line, because it really is not what it is about.
Chris Lattner: As honestly, I have mixed feelings, because that is not really what it is about.
John Sundell: It's a good tagline.
Chris Lattner: It was the right thing to say to society at that time.
From the beginning of the project, my goal was to build a full stacking system.
Chris Lattner: The reason why it is contradictory to me is that from the beginning of the project, my goal was to build a full-set system. It was to look at all existing systems out there, see what is good or bad about each of them, and then cherry – choose the best ideas from systems from which they come. And the goal really was to build something that you could write firmly on, or that you could write on, that you could write mobile apps or server apps or the low level system code, and be good at all, not just a terrible compromise.
So that positioning was certainly the right thing to do [at the time]. But hopefully Swift will grow over time in terms of what it can do.
(Beginning at 30:32)
Chris Lattner: [There is a] last group I want to talk about. Because you see what Swift is and for sure, it's a compiler, it's a language specification, it's a set of APIs, it's an IDE. But what makes it real and what has reached so many people is the work of the developer publication. These are the technical writers at Apple who wrote things like the Swift Programming Language book. And the success and swift adoption of Swift is largely directly related to such high quality, good documentation and a book available on day one. And it continues to be maintained today, and it's amazing.
We drew technological writers right into the design meetings.
And part of it was that we drew technological writers right into the design meetings. People like Tim Isted Brian Lanyon and Alex Martini spent a tremendous amount of time in weekly meetings where we argued, "do we use dot versus colon?" Or "do we use this keyword versus that keyword?" Or "shall we change
def?" But also about the depth of the type system and how code gene algorithms should work. And how do we get good performance? And how do strings work? And all the different pieces that go into it.
If you can include the explanatory-to-people section of the design process, you get something so much better.
I've seen so many systems where you build something and then try to explain it afterwards. And when you go to explain it and it's very difficult, and you're like, "wow, I have to explain the solutions to this thing". If you can close the feedback loop and include the documentation, include the explanation-to-people section of the design process, you get something so much better.
Chris Lattner: I mean, this is the kind of thing many people say, "Chris invented Swift". And well, it's a truth to it, I've been pushing it over many years in many different ways and kind of shepherded project. But it lacks the fact that there are hundreds of people involved in so many critical ways. To build debugger, build IDE, build playgrounds, build educational content in it, build all this, build community aspect of it.
There are so many different parts of this that far exceed me. It is very much a community of people both inside Apple but also outside Apple, who all push together and build things and contribute in their own ways. And that's why Swift is where it is. And that's why I see it grow.
Garric Nahapetian: And that's one of the reasons we want this podcast, to get some of them to light.
Chris Lattner: One of the things that is fascinating is that you two have written far more Swift code than I have. So I know a lot about the inside and how and why and how it fits together, but you actually have experience building and using it in production.
John Sundell: Yes, it's funny. It's this gang of people working with Swift, working on the compiler, and they all write C ++ most of the time. Just a quick page, what is it like? You have this cool language you've designed, and everyone else will use it, but you still need to use C ++.
Chris Lattner: [laughing] It kills me. It's awful. It's the universe's trick on me, forcing me to continue writing C ++.
Chris Lattner: One of the main reasons why Swift is good right now is that there is a large community of people out there who blogged about it, right? And the feedback really shaped Swift 1 and 2. It was the signal, all the complainants, people say "this doesn't make sense", "I have this problem with this, that and the other." It really shaped and prioritized and drove much of what was built.
Early feedback from the community was really shaped Swift 1 and 2.
Swift 1 accidentally, not accidentally, intentionally sent without error handling. It was also sent without protocol extensions, things we certainly wanted and just didn't fit the schedule. So we knew we had to build these things, but much of what happened in the first year or two was directly driven by society. And when Swift became open source, Swift Evolution is a huge thing. It may not be ideal for human time optimization, but it is an important part of what makes Swift truly exceptional. And I think it's total credit to the community of people who spend the time there and who help shape and operate it.
John Sundell: One thing that comes to mind is how not only articles and content, but also open source, it feels like, has fed a lot into Swift itself. For example, with things like
Codablepeople created a thousand different JSON mapping libraries. I was one of them. I built Unbox because it was one of those things where in Objective-C you didn't think much about it most of the time. You just said, here's a dictionary, let me access this key, and I'll just assume it's always a string. But when you sat down and wrote the same code in Swift, you realized that you needed to build a great pyramid of
if lets. So I can only imagine seeing the things people were trying to do solving in different ways, must also have received food at the design process.
Chris Lattner: Yes, certainly. And the design of
Codablecame from a framework on Apple that was outside the core Swift group. They were very passionate about this and they came up with it and drove it and told it.
It may not be understood how much society forms Swift.
And society can mean so many different things, right? Look at
Results. Why comes
Resultnow into Swift 5? Well, that's because many people built it again and again and again. And while the core team doesn't really want to have a
resulttype because it's a bit of a mistake in the language, and when we get concurrency, it won't be necessary. But society says loud and clear, "Look, we need it. It doesn't matter if it's not ideal in the long run, we need it." So society really shapes things. And it may not have understood how much society has that effect.
(Beginning at 46:07)
John Sundell: Look at Swift's current state and what it has become since you put it out there, has it suited your expectations, if you had anything? How does it match the ideas you had in the beginning now that it has been out for a couple of years?
When Swift 1 launched, was that the question, can we catch the Objective-C community? Can we capture the iOS ecosystem or should we fragment it?
Chris Lattner: Well, I guess expectations change over time. Back in 2010-2011 I had no expectation that there would ever be anything. And I admit that it was very much a fun side project. It was a nights and weekends thing originally. Have a day job, have a side project that is intellectually interesting and challenging. When it became more real and it was launched in Swift 1, was it a matter of, can we capture the Objective-C community? Can we really catch the iOS ecosystem or should we fragment it? It was a real concern. And then I am very happy that today I think the vast majority of the community is happy with Swift. And while there are tons of work to be done, it seems to be very successful in that community.
Chris Lattner: But there is a large open limit. Swift on the server is making great strides, but there is still plenty of work to be done. And there are other communities out there. I especially love numeric and machine learning communities, and they are super important to the world. And there are lots of very interesting people in these communities, and I think Swift can be really good there.
Swift world domination is a shocking issue, but it's based on the belief that people who use Swift love it.
And I say shockingly, Swift World Domination is a goal. It's a joke, but it's based on the belief that people who use Swift love it. And if that's the case, I'd like to give it more joy to more people and help improve the world. So many of the systems out there are very unfortunate in different ways, right? People still write C. And only in terms of the errors and security issues and things like that, it is very unfortunate. And there are ecosystem problems, there are other challenges we must overcome, and that is something we as a society can do. I don't see any boundaries on it.
(Starting at 50:18)
Chris Lattner: While this has been a very positive positive discussion about Swift, Swift also has many problems. And I think we must be open to talking about it and treating it as a problem-solving exercise. There are major issues with the Linux ecosystem, for example. The Windows ecosystem hardly gets off the ground at this point. There are so many different things that really need to happen to make it relevant to the wider audience.
Swift also has many problems. There are major problems with Swift on Linux ecosystem.
Chris Lattner: Our goal is to build an inclusive community. But if you are not an Apple developer, it may feel alienating that every time you search for some Swift stuff, you end up in an iOS discussion.
If you're not an Apple developer, it may feel alien every time you search for any Swift stuff you end up in an iOS discussion.
John Sundell: Yes, just. "How to do it in a
Chris Lattner: Exactly. And it makes you feel like an outsider and it can send the wrong signal. No one means it should happen, I guess, but the effect is real. And it is a challenge that we as a society face. And I don't know that there are good, simple answers to any of these issues. But I think we can get there.
Chris Lattner I could probably talk for five hours about this because it is very complicated. The short answer is that one of the standard views I hold is that open is better than closed. If you can get more involved, you get a better thing. I think the Swift Evolution process has many problems, Garric identified several of them. But I think it's generally a very good thing. It is also a great compelling feature that slows the development of the language, which I think is good. It is better for evolution to be conscious and carefully considered than to be quick.
I also think it is good to force a certain documentation and treat it, which is important. It's also an interesting way that causes Apple to interact with the community in a different way by providing a form to do so, which is very good.
I don't see Swift Evolution as a fixed thing. It has changed in many ways over the years, and there is always a difficult balance between, are you allocating design authorization to the community or prioritizing the ability of the community? This is challenging because if you leave it to the community altogether, you get many little things. But there are big things that must happen in the Swift world, for example, comparison, for example.
It's a bigger effort and it's harder to do through a complete bottom-up community process. So I don't know. I think Swift Evolution is a very good thing. I'm very glad we got it. I agree that it is not the only thing, and it should not be the only thing, but I think I think it is generally good.
I am always looking for what is the catalyst that allows the Swift package ecosystem, the Swift-on-the-server community or the machine learning community to take off.
And every change takes time to digest in a certain sense. When a great new ability comes in, it takes time for society to figure it out and use it and find out how it fits with everything else. Then it takes time to do well. The first thing I learned from Swift Evolution is the power to have the right catalysts in society. Swift Evolution really brought together a community of language powers to care about a particular aspect of the Swift project. I am always on the lookout for what is the catalyst that allows the Swift package ecosystem to take off, or that allows the Swift-on-the-server community to take off or to get the machine to learn the community together and do cool things .
How do we find the catalysts that allow people to get together in the right forum and really build on their strength and get energy, but also get the talent, get the people to work together in a collaborative way?