Chris Lattner 講述 Swift 起源故事

時間 2019-11-05

標籤 chris lattner 講述 swift 起源故事欄目 Swift 简体版

原文原文鏈接

做者：Ole Begemann，原文連接，原文日期：2019-02-18 譯者：jojotov；校對：numbbbbb，WAMaker；定稿：Pancfhtml

在新推出的 Swift 社區播客第一集中，Chris Lattner, Garric Nahapetian, 和 John Sundell 講述了關於 Swift 起源的故事和 Swift 社區的現狀。git

本文是我整理出的一些比較有趣的東西（爲了能更好地閱讀而作了部分修改）。你能夠看到我主要引用了 Chris Lattner 的講話，由於我認爲他對於 Swift 是如何被創造出來的描述是最值得保留下去的。但這並不表明 John 和 Garric 所說的東西沒那麼有趣。你真的應該去完整地收聽整集播客——反正所花的時間和閱讀本文相差無幾。github

Swift 社區播客自己也很是值得關注。做爲一個讓你能夠經過各類方式進行貢獻的項目，它很是符合咱們的預期（上面提到的三位嘉賓在第一集中談到了更多細節）。在本文的完成過程當中，個人工做主要在 creating the transcript 這個 Issue 上進行，甚至在代碼格式部分和編輯機器生成的文本部分收到了許多來自於社區的幫助。在此對全部提供過幫助的人表示感謝！objective-c

你能夠在 GitHub 上找到完整的記錄副本（WebVTT 格式）。全部的播客都是由 CC-BY 4.0 受權。算法

Swift 的起源

（開始於 16:59）編程

Crhis Lattner: 關於這件事，我必須從 WWDC 2010 開始講起。當時咱們剛剛上線了 Clang 對 C++ 的支持，很是多的人在這件事上面花費了極其巨大的精力。我對這件事感到很是開心的同時，也有一些煩躁，由於咱們作了太多的細節工做。並且你很難不通過思考直接編寫 C++ 代碼，「天吶，應該有比如今更好的實現方法吧！」swift

所以，我與一個叫 Bertrand Serlet 的哥們兒進行了許屢次討論。Bertrand 當時是軟件團隊的老大，同時也是一位出類拔萃的工程師。他是一個使人驚歎的人，而且在語言方面有點極客範。當時他正在推動對 Objective-C 的優化工做。我和他進行了許屢次一對一的白板會議。windows

At the time, Swift was called ‘Shiny’. 在那時，Swift 還叫 ‘Shiny’xcode

Bertrand 負責蘋果公司全部的軟件項目，所以他基本沒什麼時間。但他老是會讓我在工做結束時順便拜訪一下他，看他是否是有空。他常常會呆到很晚，而後咱們會在白板上進行很是認真的討論。咱們會談論很是很是多的東西：新語言要達成的目標、一些奇怪的細節如類型系統，而且咱們最終都會把這些討論變成一份計劃書。所以我爲他作了這份計劃書並演變成構建一個新語言的想法。那時這個新語言還叫作 "Shiny"，寓意着你正在建造一個很酷的新東西。^[1] 固然我也是 Firefly 電視節目的粉絲之一。（譯者注："Shiny" 的梗源自 2002 年美國電視節目 Firefly，意思至關於真實世界中的 "cool"。）安全

John Sundell: 當時的文件後綴是 .shiny 嗎？

Chris Lattner: 確實如此。你知道在那個時候，這仍是個很小型的項目。真的就只有我和 Bertrand 在討論這件事。另外就只有一個一樣很是出色的工程師 Dave Zarzycki 參與了早期的一些概念上的討論。

一開始，咱們就天然而然地展開了關於內存管理的討論。當時，咱們都確信一點就是：必需要有一個好的方法來解決或改善內存管理，而且咱們須要確保內存安全。於是，你必須有一個自動內存管理功能。

爲了達到自動內存管理的目標，咱們有史以來第一次以 Swift 的內部設計討論爲起點，並最終在 Objective-C 中實現了此特性。

首先想到的一個關鍵功能就是 ARC，同時咱們須要讓編譯器自身支持這個功能，而不是經過運行時來實現。Objective-C 當時使用 libauto 垃圾回收系統，但它有着一大堆問題。所以爲了達到自動內存管理的目標，咱們有史以來第一次以 Swift 的內部設計討論爲起點，並最終在 Objective-C 中實現了此特性。隨後有許多的東西都是這樣產生的，包括 ARC 和 modules 甚至 literals 及更多相似的功能，它們的確都是由 Swift 的幕後開發主導的。^[2]

John Sundell: 因此在當時，你腦海裏已經有許多關於 Shiny 的特性，最後它們都在 Swift 中實現了。但你曾經說過，「咱們並不想一直等待新語言開發完成。咱們應該把這些很是吸引人的特性加入到 Objective-C 中。」

在構建一個新的語言時，你必須一直問本身，‘爲何不直接優化現有的語言’，這是幕後構思過程的一部分。

Chris Lattner: 或許如今看來，Swift 的出現是必然的，但若是你從另外一個角度思考這個問題，在當時並非全部人都能認識到這一點，甚至連我也不能肯定。Bertrand 從過去到如今都一直很是的棒，他一直給予咱們極大的鼓勵。並且他老是能在質疑中前進。Bertrand 有點相似科學家，他僅僅只是想經過各類途徑尋找真相。的確，當時咱們有許多疑慮，但同時也有許多好的想法。包括 Bertrand 在內的不少人一直在推動這項工做。在構建一個新的語言時，你必須一直問本身，‘爲何不直接優化現有的語言’，這是幕後構思過程的一部分。而這個問題的答案是，「很顯然，咱們應該把現有的優化好」。這也是爲何諸如 ARC 的功能會出現。

可是，在 Swift 中，最須要解決的問題是內存安全。在 Objective-C 中，除非去除 C 相關的東西，否則是不可能達到絕對的內存安全。但去除了 C 的 Objective-C 會失去太多的東西，而它也再也不是 Objective-C 了。

Garric Nahapetian: 沒錯。所以，把一些 Swift 的特性添加到 Objective-C 中就像是特洛伊木馬同樣，可讓你們更容易地信任 Swift ，由於你已經完成了 Objective-C 方面的工做，是這樣嗎？

Chris Lattner: （這裏面）其實有許多有趣的內部動力。我以爲咱們很是專一地優化 Objective-C 及其相關的平臺。對於開發 Swift 而言，這是一種下降風險的辦法。若是說，「咱們要把全部東西都一次性推到重作」，並且不通過任何測試的話，確定會有巨大的風險。但若是你只把「少部分」的東西單獨推倒重作，好比一個全新的內存管理系統，而後對它進行迭代、調試並結合社區的力量進行開發的話，就只會產生有限的風險。不過有一點我要說的是，無論是外部的社區仍是蘋果內部的社區，貌似都在對咱們說，「爲何你要優先考慮這個？咱們就好像是機率論中的隨機漫步同樣。爲何你要作這個而不是其餘的？」所以，這也成爲了一個有趣的動力。

初始團隊的成長

（開始於 22:49）

Chris Lattner: 蘋果擁有着一支很是強大的工程師隊伍。那時有很是多的人一塊兒維護 Objective-C，這實際上是有點執拗的一件事，但同時這也讓咱們在動態庫、應用和其餘相似的東西上擁有了十足的深度和背景。正因如此，那時有許多關於優化 Objective-C 的想法涌現。自從喬布斯離開並創立 NeXT 以後，許多傑出的人物都一直參與這項工做並寫下了大量相關的白皮書。所以，Objective-C 背後有一個極其龐大的社區在推進着。

當時，我和 Bertrand 以及 Dave 討論過一些想法，我也開始着手編寫一個編譯器的原型。不過結果很顯然，我很難靠本身去構建出全部的東西。因此最後的事情也理所固然地發生了——大約在 2011 年四月的時候咱們與管理層討論了關於 Swift 的事情，而後也得到批准去調動一小部分人員。Ted Kremenek、Doug Gregor、John McCall 以及一些其餘的傑出工程師都是在那時調入 Swift 項目的。如今回頭看看，其實挺有意思的，由於當時是第一次有一些語言和設計專家對 Swift 作了批判性的評價。他們反饋了不少嚴厲的批判。雖然他們的本意並非打擊咱們，但他們的確說的很對——這個語言當時實在是糟透了。

能讓這一切順利進行有一個關鍵緣由，就是咱們有機會拉攏一位泛型領域的世界級專家，以及一支構建過 Clang 編譯器的團隊。同時這支團隊也參與過許多不一樣的有意思的項目，並可以儘量地發揮他們的工程天賦。雖然他們只是幫助推動和開發構建的一部分人員，但卻相當重要。

John Sundell: 在那時 Swift 語言的情況是怎樣的？好比，語言的語法是什麼樣子？編譯器的哪部分基礎設施已經搭建完成了？它是否是已經接近於原型的階段甚至更進一步呢？

Chris Lattner: 那時 Swift 已經很是接近原型階段了。這些資料都是徹底公開的，由於在 GitHub 上，變動歷史是徹底公開的。變動日誌雖然不能徹底追溯全部的歷史變動，但已經足夠了。

在 Doug 加入以前，Swift 並無泛型系統。當時咱們很想作一個泛型系統，但我不是頗有自信能獨自設計出來，Doug 卻作到了。我記得在很早的時候，John 曾經接手過一個項目，讓一個相似語法分析器的東西變得能夠真正生成代碼。Doug 所作的事情大概就是這樣。

有不少零碎的事情我不太記得了，但有些東西我卻一直記憶猶新。我記得 var 和 func 就是從最初就制定好的。早期的 Swift 中不少基本語法都和如今的 Swift 語法很是接近。

當你構建同樣新東西的時候，一般想法是領先於文檔的，而文檔又先於代碼。咱們當時狀況也很是相似。到如今，想法已經領先於代碼很是之多了，這都是無可避免的。

當時的 Swift 已經十分接近於一個原型了。但仍有許許多多的想法未實現。當你構建同樣新東西的時候，一般想法是先於文檔的，而文檔又是先於代碼。咱們當時狀況也很是相似。到如今，想法已經領先於代碼很是之多了，這都是無可避免的。

關於 Craig Federighi

（開始於 26:10）

Chris Lattner: 對於社區很是重要的另外一位夥伴名叫 Craig Federighi。Craig 在蘋果社區中很是出名。在 2011 年早些時候，他加入了這個項目。那時正好 Bertrand 從蘋果退休，Craig 便接手了他的工做。

說到 Craig，他是一個很是、很是有趣的人。不管在臺上仍是臺下，他都着非凡的我的魅力。大多數人們都不瞭解他到底有多麼的聰明。他還在許多方面都有着極其深刻的研究。我徹底沒想到，他在語言方面懂得不少。他曾爲 Groovy 和許多其餘類型的語言做爲正式參與者工做過，有些語言我甚至還沒接觸過。並且，他並不像是一位只會談論策略的高層人員。他一樣關心許多細節的事情，例如閉包語法、關鍵字和其餘東西。

Craig 真的是一位很是嚴格的任務推進者，同時他也推進着 Swift 的實現以及 Swift 與 Objective-C 的聯動。不只如此，他還關心着 Objective-C 自己的維護；關心着 API；關心着 Objective-C 的 API 導入到 Swift 後的形態，還有相關的一切。Craig 在積極給予反饋的同時，一直保持着在團隊和項目上出乎意料的卓越態度。他的幫助對 Swift 的現狀影響很大。

Garric Nahapetian: 這真的很酷，由於他恰好是在 WWDC 2014 的講臺上第一位發表演講的人。

Chris Lattner: 沒錯。

John Sundell: 而後他就介紹你出場了，對吧？我還記得那句經典的標語：「沒有 C 的 Objective-C」。

我對那句「沒有 C 的 Objective-C」標語有着複雜的感受，由於其實我想表達的並非這樣。

Chris Lattner: 說實話，我對那句標語有着複雜的感受，由於其實我想表達的並非這樣。

John Sundell: 那是句很棒的標語。

Chris Lattner: 在那個時候，以這種方式向社區宣傳是很正確的選擇。

（……）

在項目的一開始，個人目標實際上是構建一個全棧系統。

Chris Lattner: 至於說爲何我當時很矛盾，由於在項目的一開始，個人目標實際上是構建一個全棧系統——分析市面上現有的系統，取其精華，棄其糟粕。並且當時的目標是構建一個能夠編寫固件、編寫腳本、編寫移動應用和服務端應用甚至是更底層系統代碼的語言，同時在語言層面上並不是只是經過隨意堆砌來實現，我要讓它在上面說的全部方面都能表現出色。

因此在當時而言，這個方向絕對是正確的。雖然目前 Swift 還沒能達到預期，但欣慰的是它的發展將會使它可以在將來擁有這些的能力。

文檔的重要性

（開始於 30:32）

Chris Lattner: （在這裏）我還要最後提到一支團隊。你目前所看到的 Swift，它是一個編譯器，是一門語言，是一系列 API 的集合，也是一個 IDE。但讓這些事情可以成真，並讓 Swift 走向大衆，離不開開發者發佈團隊的工做。他們是 Apple 的科技編輯，負責編寫如 Swift 編程語言書籍之類的東西。Swift 的成功和快速適應市場離不開當時第一時間發佈的高質量文檔和書籍。直到今天，他們仍在維護這些文檔，真的很是難以想象。

咱們直接把這些科技編輯拉入了設計討論會

我記得當時咱們直接把這些科技編輯拉入了設計討論會。像 Tim Isted、Brian Lanier 和 Alex Martini 這些人，他們在週會上花了大量的時間爭論着一些細節問題——「咱們是否應該使用點語法？」「咱們應該使用這個關鍵字仍是那個關鍵字？」或者是「咱們是應該把 func 改成 def 嗎？」同時還討論着——類型系統的深度以及代碼生成算法應如何工做；咱們如何達到較好的性能？字符串應如何運做？還有各類各樣的問題。

若是你能在設計階段就考慮到如何像你們解釋這門語言的話，工做會進行得更順利。

我見過不少次這種事情，當你構建完一個系統後你還要嘗試着解釋它。而後當你開始解釋這個系統時，真的會陷入一個尷尬的處境，好比：「天啊，我居然還要去解釋這個東西是如何工做的」。若是你能夠在設計階段就處理好反饋信息，並引入文檔，引入這些關於如何向你們解釋的工做，你會進行得更順利。

Swift 的開發工做是一個團隊效應

（開始於 34:58）

Chris Lattner: 我想說的是，不少人會說「Chris 發明了 Swift」。雖然個人確在不少年的時間裏一直用不一樣的方法推進着 Swift 的開發，也算是帶領着整個項目，但事實上其實他們都忽略了一點，有數以百計的人爲 Swift 的許多關鍵問題做出了貢獻。例如構建調試器、構建 IDE、構建 Playgrounds、構建教育相關的內容、構建各類東西以及相關的社區。

我在許多地方都不如他們優秀。他們幾乎組成了一個不只是在 Apple 內部，同時活躍於 Apple 以外的社區，並一塊兒推進着 Swift 相關功能的構建，並以他們本身的方式作着貢獻。這就是爲何 Swift 能發展的現在的規模，我認爲這也是 Swift 能一直成長下去的緣由。

Garric Nahapetian: 這也是咱們錄製這集播客的緣由之一——讓這些在幕後作過貢獻的人能夠站在聚光燈下。

不要像編譯器開發者同樣寫 Swift

（開始於 42:15）

Chris Lattner: 有件事我以爲很神奇，大家兩個寫的 Swift 代碼比我寫的還多。我可能對 Swift 的內部實現、它爲何會是這樣的、它是如何作到某些事的，以及它是如何運做的比較瞭解，但大家卻擁有着真正以 Swift 來構建產品的經驗

John Sundell: 是的，這頗有趣。有許多許多人在爲 Swift 項目工做，爲它的編譯器工做，並且他們大部分時間都在寫 C++。我想順便問一下，這種感受是怎樣的？你設計了這門很是酷的語言，你們也逐漸開始使用它了，但你卻還在使用 C++。

Chris Lattner: （大笑）這讓我痛不欲生。這真的太可怕了。就像老天開的玩笑同樣，強制我一直在寫 C++。

關於社區反饋

（開始於 43:11）

Chris Lattner: 爲何 Swift 如今能發展得這麼好，擁有一個龐大的的社區，並且你們都習慣於在上面寫博客，這確定是都主要緣由之一對吧？社區的反饋的確影響了 Swift 1 和 2 。那些抱怨就像是提醒咱們的信號同樣，「這根本不合理」，「我在這上面遇到了問題，還有那個和另外的都遇到了問題」。這些的確幫了咱們不少，特別是在優化、排期和推進最終的 Swift 版本方面。

早期的社區反饋的確影響了 Swift 1 和 2。

比較意外，也能夠說是咱們有意爲之的是，在 Swift 1 中沒有加入錯誤處理機制。同時咱們也沒有加入協議擴展，這些能力咱們絕對是但願 Swift 可以擁有的，但只是錯過了發佈日程。所以咱們很清楚必需要去構建這些功能，但在第一兩年間這些東西倒是直接由社區最終推進完成的。而後當 Swift 開源，Swift Evolution 變成了一個偉大的項目。這個項目可能在人們的時間效率優化方面表現並不理想，但它倒是讓 Swift 非比尋常的重要因素。我想這項榮譽屬於全部在社區中花時間爲 Swift 的功能優化和工做推動提供幫助的人。

John Sundell: 我所想到的就是，不只是那些文章和內容，同時包括開源在內的全部東西，都是如何大量反哺了 Swift 自身。例如，相似 Codable 功能，在它未完成以前人們會開發數以千計的 JSON 映射庫。我也是其中之一。我曾經構建了 Unbox ，由於在 Objective-C 中你不須要在這方面花費許多時間和精力。你只須要說，這是個字典，那咱們就訪問它的某個 Key 而後假設返回結果永遠是字符串。但一旦你坐下來把一樣的代碼以 Swift 實現的話，你就會發現須要用到大量的 if let。所以我能想象到這些你們都嘗試解決的東西，絕對會以不一樣的方式反哺 Swift 自身的設計進程。

Chris Lattner: 是的，這無可厚非。並且 Codable 的設計來自於 Apple 的一支非 Swift 核心開發團隊的動態庫團隊。他們對這個工做真的頗有耐心，他們實現並推進着它，而且一直支持着它上線。

很難想象到底社區影響了 Swift 多少。

社區呈現了各類各樣的東西對吧？好比 Result。爲何 Result 要加入到 Swift 5 中？由於咱們一次又一次地構造了它。即便核心團隊不但願有一個 Result 類型，由於這彷彿是語言的失敗體現；即便咱們一致認爲 Result 類型不是必要的。但社區中卻一直有清晰且強烈的聲音，「大家看，咱們須要它。無論在長期看來它是否理想，但咱們如今的確須要。」所以社區真的影響了不少東西。並且你可能不可思議到底社區影響了 Swift 多少。

關於初始預期

（開始於 46:07）

John Sundell: 對於 Swift 的現狀，以及你發佈 Swift 後它的改變，這些是否都符合你的預期呢？通過了這些年，對於你在最初階段的想法，Swift 如今有多少是符合的？

當 Swift 1 發佈時，咱們也有一些疑問，咱們是否能夠在 Objective-C 的社區中得到一席之地？咱們是否能在 iOS 的生態系統中得到一席之地，或者是將會分紅幾派？

Chris Lattner: 這麼說吧，我以爲預期也會隨時間改變。若是回到 2010-2011 年，我並無預想着它會有多成功。我認可當時我只是以爲這是個有趣的業餘項目。這本來就是個填補夜晚和週末時間的東西。你知道，在整日的工做後再去作一個業餘項目是頗有趣也很具挑戰性的。當它愈來愈接近完成，並直到 Swift 1 發佈時，咱們都一些疑問——咱們是否能夠在 Objective-C 的社區中得到一席之地？咱們是否能在 iOS 的生態系統中得到一席之地，或者是將會分紅幾派？咱們當時的確有這樣的疑慮。如今我能夠說我會感到很欣慰，由於我以爲社區中絕大多數人都對 Swift 持樂觀態度。

Chris Lattner: 不過如今依然有新的領域等待探索。Swift 在服務端的表現一直愈來愈好，但仍有大量的工做須要完成。在外部，也有許多不一樣的社區活躍着。我對數字和機器學習的社區特別感興趣，這些對全世界都有重要的意義。在這些社區中，有着許多有趣的人，我以爲 Swift 在這裏能夠發展得很好。

Swift 的全球制霸只是一個開玩笑的目標，但它來源於使用和熱愛 Swift 的人們的信念。

我有時會開玩笑地說，咱們的目標是 Swift 全球制霸。這只是一個玩笑目標，但它來源於使用和熱愛 Swift 的人們的信念。若是真是這樣的話，我會很是願意把這份愉悅帶給人們，並幫助改善整個世界。現實中仍有許多讓人頭痛的系統對吧？仍有許多人還在寫着 C 語言代碼。就那些 bug 和安全脆弱性來講，真是讓人感受十分不幸。同時，咱們還要面對生態系統的問題，以及許多其餘的挑戰要征服，這都是咱們做爲一個社區能夠完成的。在這方面，我認爲有着無限的可能。

在 Apple 社區之外推廣 Swift

（開始於 50:18）

Chris Lattner: 儘管人們如今都是以積極、樂觀的態度來討論 Swift，可 Swift 仍有許多問題。我以爲咱們必須保持開放的態度來討論這個，並把它看做一個解決問題的練習。主要的問題集中在 Linux 生態系統上面，與之相比，Windows 生態系統的問題簡直不值一提。爲了讓 Swift 的受衆更普遍，咱們真的還有許多工做要作。

Swift 仍有許多問題。主要的問題集中在 Linux 生態系統上面。Swift 在 Windows 生態系統的問題簡直不值一提。

Chris Lattner: 咱們的目標是打造一個不排外的社區。可事與願違的是，若是你不是一名 Apple 開發者，你可能會在搜索 Swift 相關的東西時感到融入不了社區，由於搜索結果都是一些 iOS 相關的討論。

若是你不是一名 Apple 開發者，你可能會在搜索 Swift 相關的東西時感到融入不了社區，由於搜索結果都是一些 iOS 相關的討論。

John Sundell: 徹底正確。好比「這是如何在 UIViewController 中完成它的方法。」

Chris Lattner: 沒錯。這會讓你以爲本身是個外來者，但這並非咱們的初衷。我認爲這不是有意爲之的，但它倒是真實存在的。這正是咱們社區所面對的一大挑戰。我目前還不知道有沒有比較完美解決方案，不過我想咱們總會找到的。

關於 Swift 的演進

（開始於 55:12）

Chris Lattner: （關於 Swift 的演進）這是個很是複雜的事情，我大概要好幾個小時才能所有講完。若是簡短地說一下個人想法——開放要好於封閉。若是你能讓更多人蔘與，那麼你確定能獲得一個更好的結果。我想 Swift Evolution 的項目進展有不少問題，Garric 也列舉了一些。但這不妨礙它是一個很好的東西。同時有一點我認爲是有益的，就是它很好地減緩了語言的演進。由於當心謹慎地發展一個語言總比過快地發展好。

我以爲強制地推進一系列文檔進展也是一件很好的事情，由於文檔是十分重要的。Swift Evolution 項目引領了蘋果與社區在某種規範下，以不一樣的方式進行合做，這不只有趣，也是很是棒的一件事。

我不認爲 Swift Evolution 項目是一成不變的。在這幾年的時間裏，它在不一樣方面都發生了改變。同時，咱們一直在艱難地權衡着它的目的——究竟是爲社區輸出設計規範仍是幫助社區肯定優先級？對咱們來講，這是個具備挑戰性的問題，由於當你把它徹底交給社區去執行時，你可能會失去一些細節的東西。但在一些大方向上，整個 Swift 的世界都是認同的——好比併發性。

這是咱們的一次很是大的嘗試，並且經過一個自底向上的社區流程來實現它不是一件容易的事。所以不少事對我來講都是未知的。我以爲 Swift Evolution 是一個很棒的項目。我也很開心咱們如今擁有這個項目。儘管我贊成它不是咱們所惟一擁有的，也不該該是惟一的，但我仍以爲它絕對是業界標杆之一。

（……）

我一直在尋找 Swift 包管理生態系統的催化劑，到底應該以服務端 Swift 的社區爲起點，仍是以機器學習社區爲起點。

從某種意義上來講，Swift 的每個變更，都須要一段時間來消化。當一個大的新能力出現時，社區都須要一段時間來弄明白它、應用它、找出它的使用場景和它如何與其餘功能兼容。所以，花費的這些時間都是值得的。我從 Swift Evolution 所認識到的最重要的事，就是社區的合理推進所帶來的力量。Swift Evolution 真的爲咱們彙集了許多來自社區的語言極客，讓他們同時關注 Swift 項目一個特定方面。我一直在尋找 Swift 包管理生態系統發展的催化劑，到底應該以服務端 Swift 的社區爲起點，仍是把機器學習社區彙集起來乾點大事。

咱們如何去尋找這種催化劑——讓你們在合適的地方聚在一塊兒，經過他們本身的力量構建一個項目，發揮他們的能力和天賦，讓你們協做工做？

本文由 SwiftGG 翻譯組翻譯，已經得到做者翻譯受權，最新文章請訪問 swift.gg。

Jordan Rose 分享了一則與 Shiny 這個名字相關的佚事：.swiftmodule 文件中的「魔法數字」是 E2 9C A8 0E。它的前三個字節是 ✨ 的 UTF-8 字符（U+2728 SPARKLES）。 ↩︎
Greg Parker 聲稱 ARC 只是間接地從 Swift 的開發過程當中產生：ARC 的實現早於 Swift 的實現。但在幕後的工做中，Swift 早期的設想的確推動了管理層提供必要的資源去構建和部署 ObjC 的 ARC。 ↩︎