拓展 Swift 應用領域

做者：terhechte，原文連接，原文日期：2018-05-03 譯者：BigLuo；校對：Cee，numbbbbb；定稿：Forelax

我想你們應該都會贊成 Swift 是一門優秀的語言，很好的處理了那些簡單與複雜的問題。理論上講，它將會成爲重要的編程語言之一。目前，Swift 的使用僅限於蘋果開發領域（外加少許服務端 Swift 以及近期宣佈的 Swift 版本的 Tensorflow）。

「My goal for Swift has always been and still is total world domination. It’s a modest goal」

「我一直期待着 Swift 統治世界，這是一個謙虛的目標。」

• Chris Lattner

隨着新的泛型特性在 Swift 4.1 中推出以及 ABI 在 Swift 5 中逐漸穩定，Swift 彷佛逐漸具有了跳出蘋果開發領域的條件。本文我會討論一個我知道的問題，它阻礙着 Swift 普遍的應用，準確的講，與其它問題同樣，該問題也正在被開發社區着手解決。

我會簡單介紹 Swift 在這個領域的競爭力。就像 C++ 同樣，其它編程語言也渴望成爲一個跨平臺的通用的語言。經過比較 Swift 和其餘語言處理相同問題上的方式，可讓咱們該如何改進 Swift。

系統包管理

Swift 擁有一個很是健康的開源社區，擁有大量傑出、精心編寫且實用的開發框架。可是，這些開發框架多爲 iOS（macOS 相對少不少）UI 庫，這讓 Swift 受限在這個開發領域。這裏有不少 UI 動畫庫、UI 佈局庫、含有 UI 元素的框架、UI 協做庫和 JSON 解析庫。由於缺乏 UIKit/AppKit，它們中的大部分沒法在 Linux 上運行。固然，這裏也有一些相似於 Vapor 或 Kitura 的 Web 框架，致力於在 Web 開發領域推廣使用 Swift 語言。

然而，與大衆觀點不一樣，在 Linux 平臺上，不少公司不只在 Web 服務端，也在 Linux 的其它方面作了大量的工做。先簡單舉個例子，有些編程語言能夠管理系統，掌控系統權限，而且提供相應的開發工具和庫。這些內容雖然和 iOS 或者 macOS 應用開發沒有相關聯，可是對於系統或者 Web 開發來講極其重要。好比，數據庫權限、系統文件管理、進程管理、日誌分析與收集、容器管理、部署工具、甚至區塊鏈工具。

隨着 Swift 4.1 的發佈，在 Hacker News 上有一個討論這門語言的帖子。我完整通讀屢次後，以爲回覆頗有趣。讓我感觸最深的是下面的評論：

「相比 Go 和 Rust 在系統支持和庫的量級方面，Swift 的系列庫只有一小點兒......若是咱們列出其它編程語言在已發佈的應用、數據庫後端方面庫的貢獻，Swift 的數量基本能夠忽略不計」

讓咱們來看看這些競爭對手。

競爭者

在最近幾年，編程語言領域出現了幾個新的有力的競爭者。固然，你也許並不一樣意這些語言是 Swift 的合格競爭者。這裏僅根據我我的的感受列舉出幾個編程語言，排名不分前後。

這些見解可能並不許確。請不要由於你是某個語言的粉絲，並認爲個人說法存在錯誤，就把他們分享到 Twitter。我只是一個有着某些觀點的普通人，而這些觀點確實含有一些錯誤。相反，咱們能夠利用這些精力來追問問題起因，並改善或解決問題自己。

Go

Go 的發佈時間比 Swift 早不少，它多用於開發系統工具，卻不多在圖形界面中使用。Go 不支持現代語言特性，如標籤聯合、泛型，或函數式編程。但它易上手，速度快，並使用了垃圾回收器，生成的二進制文件使得其內存消耗很是低。固然，垃圾回收器也使得 Go 在嵌入式開發和使用 Webassembly 變得有點棘手。

Go 良好的性能，語言的簡單性和低內存佔用率催生出了大量的系統工具和庫。如：Grafana、Kubernetes、CoreOS-etcd、Go-Ethereum、CockroachDB、Hub、Terraform 等等。經過這個列表，咱們能夠看到一個問題的多種解法。

簡言之，若是你想作基於系統層面的開發，你能找到幾乎全部你想要的依賴包。

Kotlin

Kotlin 像是 Android 版本下的 Swift，但其底層卻徹底不一樣。基於 JVM 的 Kotlin 使得它必須大量使用引用類型，就像 Go 的垃圾回收器使其在嵌入式系統的開發成爲一個挑戰。然而，Kotlin-Native 的出現讓它在將來有了更多的可能性。Kotlin-Native 是基於 LLVM 構建的，支持嵌入式平臺開發、Webassembly 等。Kotlin 也能被編譯成 Javascript，Kotlin-Native 甚至可用於構建 iOS 應用的框架。

Kotlin 也可能會成爲將來的一個主流語言，但和有着相同問題的 Swift 同樣，其發展遇到了相似的阻礙。幾乎全部可用的開源庫集中在 Android 開發領域。而 Kotlin-Native 解決的是一個純粹 JVM 語言所面臨的問題。我不知道一個易於執行且輕量級的 Kotlin-Native 要如何實現（相比於 C++ 或 Swift，尤爲是在嵌入式開發、複雜系統開發、或 Webassembly）。

Rust

Rust 是一個有趣的語言。事實上它是如此的有趣，我花了幾個月的時間慢慢的學習它。這門語言的不少方面與 Swift 類似，但比 Swift 更難（這裏咱們暫不作討論，該部份內容將以主題的形式發佈在博客）。彷佛這兩種語言一開始就是採用徹底相反的設計思路；Swift 做爲一個易學的語言起初是一些容易上手的特性，慢慢的添加複雜的特性。Rust 起初做爲一門複雜的語言，它正在慢慢的增添一些更簡單的抽象對象或更好的錯誤調試信息來讓初學者容易上手。兩種語言語法相似，這點我並不驚訝，直到將來的忽然某天，我意識到兩門語言在某些簡單和複雜特性上有着高度的類似性。然而，目前而言，在你經歷一段複雜學習體驗的後，便會發現 Rust 背後有提供了一些很是誘人的特性。

相對於 Swift，Rust 提供了更好的跨平臺特性和一個雖難於處理但更高效的內存管理策略（好比在對象的生命週期和全部權方面），幸運的是，Rust 的一部份內存管理的優勢將來也會在 Swift 上出現，同時它也支持 Webassembly（你能夠用 Rust 寫一個前端 App），也提供了很好的基礎庫讓開發者可以快速的構建新項目，雖然它沒有提供像 Go 同樣數量級的高質量項目，但它也提供了一些有潛力的項目（CoreUtils，RedoxOS，TikV，Vagga，Servo，Parity）。但更重要的，如今已經有大量的 Rust 第三方庫供你選擇。你能夠來看看看下這個列表。

其餘語言

這裏還有像 D，Nim、Chrystal、Elixir、TypeScript 等語言，固然也包括 C++ 自身。

咱們看到了什麼

目前 Swift 在系統包管理領域有短板，這也是一個先有雞還有先有蛋的問題。

「由於沒有足夠多的系統包，致使那些對 Swift 感興趣的開發者在開發簡單 Demo 應用時數據庫處理不方便，從而對 Swift 失去興趣，對 Swift 失去興趣的開發者更不肯意去改善包管理了。」

對我而言，咱們須要改進咱們的系統包/庫。若是咱們能用 Swift 寫出 Kubernets 之類的東西，那必定很棒。爲了實現這個項目，咱們須要一套好的基礎庫用於通常性的系統開發。下面我列出了基礎的功能庫和相關三方服務（此外，下面列出的功能，已經存在部分，不須要咱們重複造輪子）。

• 認證
• 緩存
• 併發
• 雲服務
• 命令行參數解析
• 命令行 UI
• 命令行編輯器
• 壓縮
• 計算（例如：BLAS）
• 加密
• 數據庫
• 數據處理
• 數據結構
• 數據可視化
• 日期和時間
• 分佈式系統
• 電子郵件
• 編碼和解碼
• 文件系統
• 圖像處理
• 機器學習
• 解析
• 文本處理
• 虛擬化

我認爲，讓 Swift 成爲一門通用的語言，可以在非蘋果操做系統上運行，Swift 須要提供一個健壯的、跨平臺的包管理系統。

你能作些什麼？

寫庫

在你決定寫 JSON 解析器，動畫庫、自定義的開關按鈕，或者抽象的集合視圖/表格視圖的代碼以前，考慮寫一個跨平臺的系統庫。若是你不知道怎麼作，你能夠去看看 Go 和 Rust 提供的那些已有的庫。

重寫現有 C 庫

對於某些場景，Swift 的確提供了庫，但那些庫底層仍然是 C 的實現。雖然那樣也搞定了問題，但在混合的過程當中引入了 C 這門不安全的語言，在那些要求絕對安全的執行案例中，咱們必需要爲此作特別處理。固然，若是你想不到你想要寫什麼，能夠用純 Swift 實現一個你使用過的東西。這也是一個好機會，學習更多的 C 的同時進而愛上 Swift。

關心 Linux

我最近用 Vapor 寫了一個小應用，須要爲它添加幾個依賴庫（好比：時間計數器）但大部分的現有的庫只支持 iOS/macOS。 假如你有處理跨平臺（因爲沒有 UIKit/AppKit 的依賴）的經驗，能夠嘗試在 Linux 上測試編譯 Swift。

這比聽上去更簡單。這裏有一個可用的 Swift 4.1 版本的 docker 鏡像，你能夠直接運行它來測試你的代碼，或者選擇經過 Virtualbox 虛擬機來運行它。

Swift 包管理的支持

若是你已經有了一個庫，除了支持 CocoaPods 和 Carthage 外，請嘗試支持 Swift Package Manager。

運行在 Foundation 庫上

另外一件依舊困難的事情是 Swift 在 Linux 的 Foundation 庫 是基於 iOS/macOS Foundation 庫的二次實現，所以依舊存在些沒有實現的特性和（特別棘手）bugs。這意味着也許你寫在 Mac 上面的代碼在 Xcode 中跑的很好，但因爲 Linux Foundation 庫的 bug，它運行在 Linux 上時可能會崩潰。爲了拓展 Swift 的應用領域，讓 Linux 上面的 Fundation 庫代碼變得更加健壯是一個很好的目標。

最簡單的開始方式是去 Swift Jira 的首頁搜索 Foundation bugs。

幫助改進 Foundation 庫

若是你沒有時間或者對在 Swift Foundation 上的工做內容不感興趣。你也能夠在 Linux 上使用或者測試 Foundation 庫，而且提交 bug 報告。只要有愈來愈多的人使用它，它也將變得更加穩定。

幫助改善 Linux 編輯體驗

Linux 用戶沒有 Xcode，因此他們使用 Atom、Emacs、Vim 或 VSCode。這裏已經有多個項目來讓這些編輯器支持 Swift 語言編輯。但咱們也許可以改進它們。若是你有空閒時間，用你喜歡的編輯器參與到這些項目中來，進行測試提交問題或解決這些問題。

參加在 San Jose 舉辦的 Try Swift 大會

若是你剛好在 San Jose 參加今年的 WWDC。這是一個很好的學習機會。 你會碰見一些有趣的人，嘗試參加在 San Jose 舉辦的 Try Swift 大會。

「你有機會爲 Swift 作出貢獻。加入一個 Swift 開源貢獻者小組，討論有關 Swift 開源項目的最新消息，而後在社區導師的幫助下爲 Swift Evolution 作出本身貢獻！」

你能夠查閱這個連接

舉手之勞

在過去的一年半里，我沒有太多時間作任何關於開源的工做，由於我一直忙於本身的（閉源）項目，但我真想再次爲 Swift 開源代碼貢獻。我真的很喜歡 Swift，這是一個很棒的語言，幫助它成功的那些日子，是我曾感到最美妙的時光，若是你有一樣的感受，請分享這篇文章。

若是對文章內容有想法的話，歡迎來 Twitter 上一塊兒討論

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