作者：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。