【矽谷問道】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 應用到伺服器端。其實伺服器和行動裝置 App開發頗有類似，比如架構設計和函數庫調用上。但是，唯一的麻煩就是我們得讓 Swift 能在 Lunix 上流暢運行。同時構建大量伺服器端的庫函數。現在 Swift.org 上已經有專門的版塊討論區伺服器端上的開發了，大家集思廣益的感覺非常好。

再接下來，Swift 要取代 Java，無論是指令碼語言還是底層的系統設計，Swift 最終都應該能應付自如。

指令碼語言上，開源社區和我們蘋果內部都在嘗試將Regex、多行字串等指令碼語言的特徵都加入到 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. 你為什麼去做電動車？

首先我個人非常喜歡車。但我又懶得自己老是去加油啊、開車，我更喜歡一種更可靠的方式，最好我自己啥也不用做，車子就可以把我送到目的地。我也不需要擔心維護啊什麼的。我其實是特斯拉最早的一批客戶，我覺得特斯拉駕駛起來很開心。

不過我重來沒想過我會去一家汽車公司任職，因為我覺得我是個程式員，這跟汽車有啥關係？不過特斯拉讓我去做自動駕駛系統，這個就很對我胃口了。因為這也是世界級的難題，我想嘗試挑戰一下。

補充

Chris Lattner 提到的語言

• Go

首頁：http://golang.org/

Google發布的開源語言。編譯速度媲美 C，安全性有過之而無不及。學習曲線也與 Java 類似，比較簡單。目前主要用於網路伺服器，儲存系統，和資料庫中。

• Dart

首頁：https://www.dartlang.org/

Google 開發的語言。基於類，只能單一繼承，風格上偏向 C。目標在於成為下一代網路開發語言。目前 Google 正在嘗試用 Dart 開發 Android 應用，達到去 java 化的目標。

• Haskell

首頁：https://www.haskell.org/

函數式程式設計語言，支援惰性求值、模式比對、列表內包、類型類和類型多態。使用者很少，普遍認為難學難用。主要用於金融系統及安全性和效能要求拋高的產品。

參考連結

音頻：ACCIDENTAL TECH PODCAST 205

原文：PEOPLE DON'T USE THE WEIRD PARTS

Swift 3 將不包含穩定的ABI

轉載 為什麼業界很少使用 Haskell？