Chris Lattner 在 WWDC 17 Swift panel 上的一些谈话摘要。
如何评价 Swift 的开源
设计编程语言的很多时候就是做权衡。从不同的角度看会得到不一样的结果，没有一个完美的方案。你做出一个设计后在某些方面有好处同时也会有另外一些不好的地方。这些所有的好处坏处很难全部看清，除非你展示出你的设计理念，用户从不同的角度反馈他们的观点给你。
开源社区给予了我们很多反馈这是很好的，不好的地方在于有时有太多的建议会影响我们的讨论进度。
Swift 4 与 Swift 3 的区别
Swift 3 开始的时候有一长串的目标，随着时间的推移很多目标都无法完成。Swift 3 的目标本来是 ABI 稳定，开发到一半的时候我们修改了这个目标。已经有很多人开始使用 Swift，相比 ABI 稳定我们认为源代码（source stability）稳定才是最重要的，不希望每次升级原来的代码都不能使用需要改动很多。
译者注：Swift 4 的 moudule 编译选项可以选择 Swift 3 或者 Swift 4，如果 framework 继续使用 Swift 3 依然不影响整体项目。从Swift 3 升级到 Swift 4 的语法要改动的地方也很少。虽然不是完全的 source stability ，但是对于开发者而言，这次升级对原有的 Swift 3 代码确实影响小的多。
Swift 在服务端的表现
从技术角度来看，Swift 作为一门服务端语言还有很多事情需要做。相比于其他成熟的服务端语言比如：Go，Node.js，Ruby，PHP等。但是 Swift 的一个优势是运行的更快，对 CPU 和 内存的利用率更好。
Java 是一个很有趣的语言因为 java 也运行的很快，有着一个成熟的生态，VM 也很棒。java 的问题不在于 CPU 使用，而是内存。和 Swift 相比，java 需要3到4倍的内存。
Swift 的动态能力和元编程
Swift 是否会有更强的动态特性这是毫无疑问的，问题是这件事的优先级，在目前是不是最需要具备的能力。大部分人包括 Swift 开发团队都想要反射的能力，但是更多的人希望代码可以编译的更快。
我们对 Swift 4 和 Swift 5 设定了目标，完成制定好的计划是更重要的事。
这次 Swift 4 中的 Codable 就是一个好的例子，是通过静态反射实现的。然而使用 Hygienic macros 也是一种很好的实现方式，但是使用这种方式需要进行一套完整的设计。虽然最后如果这个特性实现了会带来很多其他的积极好处，然而并不意味着我们目前就要完成这个特性。最重要的是解决核心的问题并且让语言更好用。
当人们讨论反射能力的时候我其实不知道他们具体要的是哪一种能力。Swift 4 中的 key path 有了不小的进步，可以以优雅、类型安全、富有变现力的方式解决很多问题。实际上在 Swift 3 中很多工作都利用了对象的 runtime 元数据，比如 Xcode 的堆调试器。我们只是没有把这些反射的功能作为 API 提供出来。希望未来某天可以把这件事列入计划吧。
Swift 的起源
Swift 始于2010年。当时我们刚刚完成 Clang 对 C++ 的支持。我真的要说写 C++ 的编译器是一件很苦逼的事。在写代码的时候不得不让你思考：一门好的语言应该要是什么样。
起初这不是一个正式的项目，就是自己捣鼓，尝试做一些 hacking。最终 Swift 正式立项内部也经过了很多的讨论，面对的最大的质疑就是“为什么不把 OC 搞好一点而一定需要一门新语言？”。
回忆一下，在10年14年间，OC 已经有不小的改进。比如有了ARC。其实 ARC 是为 Swift 进行铺路的第一件事。因为只有自动标记内存才可能安全，这是让 Swift 成为可能的重要一步。还有很多特性比如 modules，甚至小到字面量（@“NSString”）都是为了让 OC 更加接近 Swift。这样最后当 Swift 发布时大家就会觉得比较熟悉。
那么为什么不能在 OC 上改呢？因为 OC 的基础是 C。指针在 C 里又是普遍使用的。如果把指针从 OC 里移除，那 OC 看起来和新语言也没什么区别。如果会很大程度上的改变原有代码，不如直接在一个新平台上写，这样也能保证你的所有好的想法可以执行。
Swift 的远景
我对 Swift 的目标一直没变：全世界制霸。这是一个很谦虚的目标。但是这不是 Swift 5 的目标，这是十年或者二十年后的目标。那我们怎么做到呢？这个过程就像写一个大app：你制定一个目标，然后分解成很多小的目标，然后再分别达成这些目标。一门语言要统治世界首先要有一个杀手级的程序。你必须让社区有一个理由去学这门语言。世界上存在着很多语言但是已经无人使用。Swift 的杀手程序当然就是 iOS 编程。
一旦这样开始了，奇妙的事情就会开始发生。那些聪明的程序员会推动这个语言的发展并且想要得到更多。进而他们会尝试用这门语言做其他事情（不只是 iOS）。参考一下 JS 的发展历程。他们从一个小目标（给浏览器写脚本）开始，到现在有人用它写可怕的服务端程序。这中间到底发生了什么？这中间逻辑跳跃的原因是什么？为什么会想用 JS 写服务端？！抱歉，我没控制住我自己。我也很喜欢 JS，我只是更想干掉它。
发展的原因就是因为社区变强大了。社区在成长并且推高了语言的极限（push the boundaries）。早期我设计 Swift 的时候一个很关键的原则就是通用。它的目标不是比 OC 好一点，不是 OC 的一个改良。如果只是那么想，它就会看起来更像 OC，类型系统也不会有现在这么多的特性。它应该只会基于 OC 来实现。这样就不可能使得 Swift 可以在服务端运行。Swift 在 Linux 一个很酷的事情就是可以单独使用 Swift，不需要依赖于 OC。
总结一下让 Swift 成为统治世界的语言的实现方式就是打造一个通用的语言并且能真正的解决问题。然后就会有一个活跃的社区，然后你开始解决阻挡它成长的障碍。
当前的首要挑战就是服务端开发。对于 app 开发，服务端是一个很自然的拓展方向。你可以看到很多人想要解决客户端和服务端关联的问题，比如共享数据结构等。你也需要相似的语言级别的特性。我认为让 Swift 在服务端迈向成功的一个关键特性就是对并发的支持。这真的是一个早该有的能力，在你写服务端程序时要是没有对并发的良好支持确实也会很苦逼。不过对并发的支持不用等太久，相信到时候会有更多的人开始接受 Swift。Swift 有望成为一个 Java 级别的语言，可以做很多应用级别的事情。未来某天，Swift 支持 regular expression literal，这样就可以更好的支持脚本。这样就使用场景可以横跨应用，服务端，脚本。当然这个过程中还有很多工作需要做。
我个人想法，真正的杀手级特性大概就是三四年后开始具备系统开发的能力。如何干掉C++是一个难题，但是一定要做到。因为目前有一些工作只有 C++ 能做到，然而 C++ 的问题在于它是基于不安全的 C。这意味着这些应用程序都建立在一个痛苦的世界上。如果 Swift 可以解决系统级编程的问题（class of system programming things），这样就会对整个开发者社区打开大门，比如游戏开发者，他们真的很在意性能，目前他们只能用 C++ 写。
事情从开始到成功总是有一段很长的路。今天 Swift 写服务端的代码成为可能，但是还是处于早期的阶段。在 Swift 5 引入并发后，希望它更具有吸引力。如果从五年十年后的角度判断发展趋势，你会看到一个不一样的世界。更早的开始体验未来的趋势会让人觉得兴奋。
怎么看 Kotlin
Swift 和 Kotlin 是同一个时代的语言。所以有很多表面的语法看起来很像。但是如果深入的去看两者有着巨大的不同。Kotlin 倾向于面向引用（类和对象），是基于 Java 的一层包裹，所以有很多 java 的风格在里面。
如果 Swift 也只是一个类 OC 语言，那么所有东西都会说 NSObject，然后依然到处都是 objc_msgSend ，只是会把扰人的中括号去掉，做一些语法层面的改良。依然会有很多人喜欢这样，但是这样就不会有函数式特性，不会有值语义，不会有其他一些更安全的特性。
我觉得 Kotlin 是一门不错的语言，我真的这么觉得。只是它和 Swift 有着不同的背景约束。
怎么决定什么特性应该被加入 Swift，比如抽象类
Swift 从不害怕承认从其他语言偷一些好点子。甚至有一些特性是从 Dart 学来的。实际上想法是从哪里来的不重要，Swift 也无意于模仿某个语言。只是会考虑最好的方案。
那什么是一个好主意？抽象类（abstract class）是一个好主意吗？这很难确定。抽象类已经在社区里进行了好几次讨论。我个人倾向于认为抽象类会是一个好主意。但是这依然是个优先级的问题。人们想要很多特性，比如命名空间什么的。
真正让我觉得傻逼的是很多人说类是不好的，或者说继承不好。这是完全错误的。类非常的重要。引用语义也非常的重要。简单的认为一样东西是坏的另外一种东西是好的是错误的认知方式。这些都是不同的抽象工具，他们被用于解决不同的问题。另外一种不好的认知是：类很棒，可以解决所有的问题。或者说结构体很棒，所有的问题都应该用它来解决。我想很多人说继承不好是相对于 OC 中对类的过度使用。
Swift 打造成一门友好的编程教学语言
我不知道该不该说，其实 playground 最初的目标是为了可以在 iPad 上运行。
让 Swift 容易上手是一个重要的目标。核心理念就是你可以从简单的地方开始，然后随着熟练慢慢掌握复杂的东西。
