【硅谷问道】Chris Lattner 访谈录（下）
【硅谷问道】Chris Lattner 访谈录（下）
Chris Lattner 访谈录(下)
话题
- Swift 在 Server 和操作系统方面有着怎样的雄心抱负？
- Swift 与 Objective-C 的爱恨情仇？
- Swift 之父对于 RxSwift 和 ARC 有什么独到的见解？
- 随着 Swift 之父的出走，这门语言还会继续高歌猛进吗？
访谈实录
Swift 在系统、服务器、网页端的发展
16. Swift 在服务器，或者 Linux 上可以说运行得不错。你们是一开始就计划在服务器或者系统端运行 Swift，还是说你们更希望 Swift 专注于 iOS 开发，而不是去与 python 或 Rails 竞争？
你如果去看苹果官方的 Swift 书，里面有这样一句：“Swift 的目标是，上能写应用程序，下能写操作系统（Swift was designed to scale from hello world to an entire operating system）”。所以我们一开始，就是要将它创作成为一门一统天下的语言。
这也许有点痴人说梦，但是大家等着，过几年就知道了。无论是我还是苹果的其他人，都把 Swift 当成是未来世界的主流语言来看的，它将会超越 Python，甚至有一天取代 C。那么我们是怎么实现这一步的呢？
开源是重要的一环。你不开源，别的平台就不大想用这个语言。当各种各样的开发都采用 Swift ，Swift 一统天下的目标也就越来越现实。现在很多学校的计算机基础教育就在教 Swift，它越来越流行了。
所以嘛，第一步我们就是让这个语言流行起来，让大家使用它。我对“流行”的定义是，Swift 必须要有一个杀手级的产品，这样大家就会知道 Swift 有多好，大家都会使用它。现在 iOS 平台和 Mac OS 平台有很多非常棒的 Swift 应用。这样我们开始第二步，开源。第三步，我们要走得更远。
什么叫走得更远？我觉得现在我们要做的就是把 Swift 应用到服务器端。其实服务器和移动应用开发颇有类似，比如架构设计和函数库调用上。但是，唯一的麻烦就是我们得让 Swift 能在 Lunix 上流畅运行。同时构建大量服务器端的库函数。现在 Swift.org 上已经有专门的版块讨论服务器端上的开发了，大家集思广益的感觉非常好。
再接下来，Swift 要取代 Java，无论是脚本语言还是底层的系统设计，Swift 最终都应该能应付自如。
脚本语言上，开源社区和我们苹果内部都在尝试将正则表达式、多行字符串等脚本语言的特征都加入到 Swift 当中，虽然工作量很大，但我认为它们最终都将成为 Swift 的一个部分。
系统开发方面，我觉得取代 Java 最重要的一点就是 Swift 一定要有自己的特色。我觉得 Rust 是一个不错的语言，虽然现在没多少人用。Swift 在某些顶层开发上要明显优于 Rust。再等过些年，当 Swift 在系统开发上真正流行起来之时，Swift 就离一统天下不远了。
17. 对于 Swift 在服务器上的发展，你觉得交给开源社区去做就足够了吗？苹果自己会不会推出面向服务器端的 Swift 函数库？
首先我觉得若要成为服务器端的流行语言，这几个部分 Swift 必须具备：编码和解码，网络传输协议，HTTP。这些部分我觉得要成为标准函数库，因为它们是最基本的东西，苹果内部自己来做也许更好，因为能确保质量。对于具体的网络应用函数库，我觉得短期内没必要。这是因为业界内部对此就争议很大，如同 Ruby on Rails 那样的王者框架还没有出现。
我觉得对开源社区而言，最重要是两个工作。第一，是 Swift 的包管理器（Package Manager）。这个可以让我们在多个平台、不同函数库之间协同工作，大幅提高兼容性和效率；第二，是并发模型（Concurrency Model）。Go 语言之所以在服务器和云端开发这么受欢迎，就是因为并发模型做得好。并发模型应该会集成在 Swift 5 中。
18. 现在 Swift 在服务器端还不是那么成熟。有人说 Swift 不过是写 App 的一门语言。现在已经 3.0 版本了，大家貌似都还只是将 Swift 用来写写 iOS 应用。你怎么看？
我现在根本不担心 Swift 在服务器端最后不会成功。很多人写了几年 Swift，自以为很懂这门语言。当 Swift 具备服务器端特性的时候，苹果一定会跟大家说，你看 Swift 能做这个那个，你用其他语言来写就要麻烦得多。
现在最大的问题是大家还觉得 Swift 只是苹果自己搞出来的东西。他们觉得 Swift 不过是苹果自己的玩具，只能用在苹果自己的 iOS 系统和 Mac OS 系统上。所以我们应该加大开源和构建社区的力度。现在外行对于 Swift 的态度还可以接受，慢慢地 Swift 就会在系统开发领域追上来。
19. 大家似乎都在期待 Swift 能在网页开发上有所建树。现在网页或者网络程序开发方面，一般是多种语言混用，前端和后端可能语言逻辑完全不一样，你对此怎么看？
这可能要花很长时间，要是能取代 Javascript 那就简直了。现在 Dart 在网页开发上做的不错。我个人看好 asm.js 和 WebAssembly，它们都是通过 LLVM 编译的，跟 Swift 一样。如果这两个今后做得足够好，也许就没 Swift 什么事了。未来之事，都很难说。
而且我现在发现，Javascript 已经变成一门基础语言了。我看很多脚本语言现在都直接编译成 Javascript，Javascript 就像比特一样成为一个最基本的表达方式。我觉得五年之后，很有可能 asm.js 会一统网页端。虽然大家说 Javascript 不好 debug，但其实就算你写 C 这么成熟的语言，debug 起来依然很头疼。这也是我们为什么不在 Swift 中加入宏定义，因为那个给编译和 debug 增加了难度。
Swift 语言设计
20. Swift 好像一开始就设计得简单易懂、而同时又有很多高阶的复杂操作。经验丰富的程序员可以写出漂亮的语法糖，对编程一窍不通的小孩也可以玩转 Playground。你认为 Swift 是一门将复杂和简易融为一体的语言吗？
Swift 在这点上目前做得还不错。但我担心开源之后大量的新功能添加进来，使得 Swift 不再简单。我一直致力于让 Swift 成为一门简单易学的语言，同时又足够强大。你想我们为什么不支持内联汇编 (inline assembly support) 这样的功能，就是只有极少数极客会喜欢。以后我们也要秉持这个原则。
一个不会写 Swift 的人。打开 Playground，敲下 “print("Hello World")”，旁边就会显示出来，这点跟 python 很像，你不用去打"\n"这样的换行符号。也就是说 Swift 对于新手来说非常友好，我们可以从 Hello World 开始逐步深入，从简单慢慢过渡到复杂。
对于系统开发而言，Swift 相比 Rust，会更好的自动控制内存分配，因为我们可以借鉴开发 ARC 时的经验。你想内存分配这种底层的东西，也只有少数大牛能精通。那为什么不把 ARC 引入到底层来简化开发呢？我觉得这是 Swift 开发的另一个方向。
21. 有人说 Swift 是大杂烩，一部分借鉴 C#，一部分借鉴 Javascript，一部分借鉴 Objective-C，你是怎么看的？
Swift 确实是大杂烩。但是它并不是简单的模仿其他语言，而是借鉴，然后创造出一个伟大的语言。我们确实参考了大量其他的语言设计。比如 Haskell 很多概念就被引入到 Swift 中。Swift 中的 Protocol，就是从 Haskell 的 construct 中得到启发的。
还有其他部分长得像 Dart，亦或是借鉴了 Go 和 C#。这样做也有另一个好处，开发者拿到 Swift 的时候会有种似曾相识的感觉，这样大家也更愿意用 Swift 开发。
Swift vs. Objective-C
22. 给我个现在就学习 Swift 的理由？
这个其实无所谓。我个人不觉得 Objective-C 会短期内被取代，苹果依然支持 C 和 C++，而且放弃 Objective-C 对苹果来说有百害而无一利。你不必一定要学习 Swift，Swift 只是一门更好的语言。
说到 Swift，我们给它取这个名字就意味着我们希望这门语言非常得高效。它本身设计的目的不是让你短时间内写大量代码，而是用最少的时间、最简洁的代码来完成工作。
编程其实包括方方面面，不仅仅是写代码，还有 debug，给各种系统适配，以及其他各种事情。其实开发的时间短，找 bug 的时间一般都会很长。比如在 Objective-C 中，你会花不少时间修 unrecognized-selector error，但是 Swift 从顶层设计中就排除了这类 bug。
Swift 还有其他一些好处。比如可以对字符串使用 switch...case...语句；可以使用 functional programming；可以用 enum 和 protocol。Swift 其实是一门包罗万象的语言，菜鸟和老手写出来的 Swift 可以完全不一样，这取决于经验。
我最近发现，很多 iOS 开发者会把 Swift 当 Objective-C 来写，逻辑结构完全一样，只是换个语法。其实这就意味着他们没有意识到 Swift 的价值 -- 认为 Swift 不过是 Objective-C 的替代品。当开发者深究 Swift 的语法后，他们才会意识到这是一门多么高效的语言。
23. 会不会像 Objective-C 一样，在未来 Swift 添加一些动态特性？
Swift 目前没有加入动态特性的计划。很多人问为什么 Swift 不能有响应，reflection这些特性。甚至有人写博客说，“迟早有一天，苹果要重写 Swift 的所有架构”，我每次在 WWDC 前看到这些博客都会呵呵。很多人不明白什么叫动态性，也不关心我们发布的 Swift 计划表，只是不停的写博客，预测这个吐槽那个。
我个人可以明确表示，Swift 近期内没有加入动态特性的计划。凡事有轻重缓急，我们得先处理其他事情，比如并发模型，比如在系统端上的优化，比如脚本的适配。不过以后如果有时间，Swift 会加入动态特性的，前提是我们计划表里的事情都做完了。
24. 你不担心没有动态特性，很多 Objective-C 的程序员会各种不适应 Swift，然后就放弃用 Swift 了吗？
我不担心啊。Swift 本身支持 Objective-C 上的所有特性，你只需要那部分代码使用 Objective-C 兼容，然后把它们加入到 runtime 中即可。
虽然有很多人说，我就是想写纯粹的 Swift 代码，但其实我不觉得这是一种倒退。你可以使用 reflection 模型，要用这个功能你用就是了，自己设计的代码结构自己负责。在写代码这事上，从来没有非黑即白一说，我们要做最重要的事，而不是天天在推特上开听证会。Swift 核心组做的工作就是把关 Swift 开发，把这门语言导向一个正确的方向。
Swift 编程规范
25. Swift 现在好多语法糖。怎样避免写出奇怪和低效的 Swift 代码？你觉得现在 Swift 可以称得上成熟吗？
现在正是 Swift 成熟之时。Swift 1 和 Swift 2 的时候，确实语言的变化很大，大家很头疼。但是 Swift 3.0 是一个稳定成熟的版本，它真的不错。之后的工作是在 Swift 3.0 的基础上增加新的函数库或者功能，而不是修改现有的架构。
其实 Swift 开发者也在纠结语法糖太多的问题。我听说一些人出了一些 Swift 的书籍，这很好。其实我们在设计 Swift 的时候，就考虑到语法糖的问题了。比如你写代码，把所有变量都用 var，这时候编译器会提醒你对常量使用 let。这说明一点，Swift 是鼓励 immutable 数据类型的，并且 Xcode 也会自动督促你写出更规范的代码。不过目前对于“是该用 class 还是 struct？”这类比较困难的问题，编译器还没智能到能自动检测并纠正。
26. 有些语言一开始就有设定好的语法糖和规范。为什么 Swift 没有这样，而是让开源社区去讨论？你个人对 Swift 有没有一些编程规范？
作为一个程序员，我骨子里流淌着编程规范的血液。但在 Swift 的开发过程中，我还是改变了一些固有观念。比如说，我认为所有代码代码段都应该是一个地方输入，一个地方输出。但我后来发现这样设计语言很难维护，可读性也不佳。 比如说我们设计的 guard else 语句，你一定要在末尾写上 return 之类的结束语。这就导致了一个函数有多个地方输出：你在 guard else 里 return，在其他地方也 return，不符合我原来的设想。但是如此设计会令安全性提高，因为我们把一些特殊情况给提前处理掉了。
对于空格这种格式问题，我个人倾向于空 2 格。我知道有些人喜欢空 4 格，还有人喜欢 3 格（因为他们觉得文件中不应该有 tab）。这完全是萝卜青菜各有所爱，大家对此争论不休，哪一种都有一定道理。所以我们最后也没有对 Swift 提出固定的格式要求，大家写出自己喜欢的代码就行。但是这也造成了一定程度的混乱 -- 你写的代码格式会与同事的完全不同。但是我觉得这并不会影响语言的多样性。
Go 当年强行推广了一套编程规范，结果到现在仍有争议。我们现在的工作不是做语法上面的规范，而且我们也不希望推出一套规范后大家好不买账。开源的另一个好处是，大家可以自行决定什么是好的语法规范。就算有时间我个人或者 Apple 也不会去写 Swift Style Guide。比起规范我更愿意去回答理论和语言设计上的问题。
有一件趣事我想分享，我一直担心别人会问，为什么 Swift 的函数名叫 func？而不叫 function 或者 fn？这其实颇有争议。不过现在已经是 Swift 3.0 时代了，大家这样用得很顺，我们也不会去更改了，所以争论于此没有意义。
RxSwift 以及响应式编程
27.很多开发者用 RxSwift 或者其他响应式编程。你在开发 Swift 过程中有没有仔细研究过响应式编程这些？
我已经开始关注 RxSwift 了。但是我自己没用响应式编程来开发过产品，所以我对它们的理解来自于博客。RxSwift 看起来很棒，你可以少写很多代码，而且似乎开发效率也会更高。但听说维护和测试起来也很难，有优点也有缺点。
如果我有空写一个 App 的话，我肯定回去试试 RxSwift，然后再过来发表观点。我现在不敢说”强烈推荐”，或者“强烈不推荐”之类的话。
Garbage Collection vs. ARC
28. 我们都知道 Garbage Collection 和 ARC 各有千秋。Objective-C 有 Garbage Collection，后来加入了 ARC 的机制。Swift 则是完全 ARC。你能说说为什么你们那么看好 ARC 吗？
Objective-C 最开始是基于 Libauto 系统开发的，而 Libauto 本身就有诸多限制，所以我们当时采用了 Garbage Collection。我个人觉得 ARC 完全要优于 Garbage Collection，因为后者经常在内存上回收一下我们不想回收的变量。所以我们在 Objective-C 上采用了引用计数和 ARC。
ARC 最重要的一个优势就是，它很好的处理了 final 这类参数。如果你用 Garbage Collection，比如 java 吧，final 参数就是那些不被回收一直在跑的东西，这样展开讲问题是一箩筐。我举个最简单的例子，当有个 final 变量运行在一个错误的线程上时，它会多次重跑，导致实例被不停的创建。ARC 则是从根本上解决了这个问题。
目前反对 ARC 的理由主要有两个，一是人们觉得 ARC 引入了额外的开销，因为你要维护引用计数嘛。另一个是 ARC 容易造成循环引用。
我个人要强调的是，这些毛病 Garbage Collection 也有。除此之外 Garbage Collection 还不能终止所有的线程，或者在特定的一个时间点终止一个线程。这是因为 Garbage Collection 引入了安全指针（safepoint），这同样也是一笔额外的开销。
ARC 中引用计数的开销在实际开发中影响不大。而且我们对对象的整个生命流程都有掌控，而这是 Garbage Collection 不具备的。实际上我觉得 ARC 中有些额外开销是必须的，那些不必须的开销以后也会慢慢改进的。
至于循环引用的问题。相比于你必须在具体的一行说明，retain/malloc 这个变量，然后再在后面某一行说明，release/free这个变量这种麻烦事，你只需要用 strong 或者 weak 表示你对对象的所有权，你省去了大量思考内存分配的担忧和操作，这难道不是一个巨大的进步吗？
身后之事
29.把 Swift 交给 Ted 你放心吗？
完全不用担心。
Ted 这人实力非常强。斯坦佛的博士生毕业，苹果十年工作经验，曾经以一己之力完成了 Clang 的静态分析器。Ted 在管理方面也很优秀。我有时候会突发奇想，让手下一个人或者一个组去做“我认为有意义”的项目。Ted 则是非常稳健的管理者，他总会领导组员去做最重要的事情，这就是我跟他的不同。
另外我们的小组也很强，核心团队的几个人：Doug Gregor, John McCall, Joe Groff, Dave Abrahams。这几个人都是极其优秀的极客。Swift 其他团队的工程师也很给力。有他们在，没有任何理由 Swift 不会成功。
30. 你为什么去做电动车？
首先我个人非常喜欢车。但我又懒得自己老是去加油啊、开车，我更喜欢一种更可靠的方式，最好我自己啥也不用做，车子就可以把我送到目的地。我也不需要担心维护啊什么的。我其实是特斯拉最早的一批客户，我觉得特斯拉驾驶起来很开心。
不过我重来没想过我会去一家汽车公司任职，因为我觉得我是个程序员，这跟汽车有啥关系？不过特斯拉让我去做自动驾驶系统，这个就很对我胃口了。因为这也是世界级的难题，我想尝试挑战一下。
