Silver：將Swift引入.NET和 Android

原文  http://www.infoq.com/cn/news/2015/03/silver-swift-dotnet-android

作為“蘋果Swift編程語言的自由實現”， RemObjects公司的Silver項目 使得無論是在.NET，Java/Android還是Cocoa/Cocoa Touch平臺都能做Swift代碼的原生編譯。RemObjects宣稱Silver的目標是盡可能貼近Swift，雖然現階段在底層平臺方面確實存在差異。

很多局限要歸咎于目前Silver還處于測試態，不久的將來，這一情況定會有所改善。還有少數是永久性 差異和局限 ，由于關系到特定平臺需求，這些問題會存在很長時間。這些局限會影響到：

• Array, Dictionary,和String類型，這些類型無法有效實現為structs（值語義）；classes同樣如此;
• 默認初始化，無法為classes而只能為structs創建；
• 聲明在不同項目中的擴展，而不是擴展類中。

Silver為此提供了一些 語言擴展 ，包括異常、迭代器、分部類，等等。Silver提供了運行于Windows和Mac上的完整開發環境。Windows平臺，Silver集成在Visual Studio上，Mac平臺則是一款名為 Fire 的IDE。

InfoQ與RemObjects的首席架構師marc Hoffman（sic）就Silver進行了深入訪談。

InfoQ：你能解釋下Silver是什么以及使用Silver能帶來哪些好處嗎？在你看來，哪類開發者適合使用Silver？

Sic：作為編譯器及相關工具鏈，Silver能通過我們自主研發的蘋果新語言Swift，為三大主流平臺——.NET, Java/Android和Cocoa構建應用。對Windows開發者而言，Silver集成在Visual Studio上，而對Mac開發者而言，則是我們自主研發的輕量級IDE——Fire。

Silver能帶來多層面的好處。Swift是一門正被廣泛接受，近幾年會被億萬開發者學習的偉大語言。Silver能讓你用Swift進行開發，但不局限于蘋果平臺，還可適用于.NET和Java/Android平臺。

對于具有蘋果背景、想擴展到其他平臺的開發者，以及純.NET或Android開發者，我們相信Swift都具有吸引力。純粹因為Swift是一門偉大的開發語言，比Java甚至C＃具備更多優勢。

當然，對于那些需要在不同平臺應用間共享代碼的開發者而言，Silver更具吸引力。我們明確反對編寫“跨平臺應用”（就是那種為所有平臺 構建、到處運行的應用）。然而，在構建某些專用應用時，的確可以共享一些“業務邏輯”類型的代碼。好比，你為iOS和Android（也許是 Windows Phone）編寫移動應用，Silver推薦你在每個平臺上從零開始設計應用，而后端代碼（諸如與服務器通訊、建立內部數據模型或是執行運算）能夠根據應 用投放平臺的不同輕松共享。即便項目間不存在代碼共享，項目中只使用一種語言和IDE也有助于避免沖突，因為你無需在不同編程環境間來回切換。舉個例子， 也許你想編寫iOS應用，而后端要用ASP.NET服務器——這些都可以用Swift，在同一IDE中實現。

以我之見，“為什么要用這個編譯器”這個問題經常被人們忽略。我認為Silver是一個很好的開發工具：語言豐富，IDE功能齊全且使用靈 活（無論是用Windows的Visual Studio還是用Mac的Fire IDE）。即便你根本不關心多平臺，這些優勢也會讓你有足夠多的理由選擇Silver而不是Java或C＃（或蘋果自家的Swift和 Objective-C）。

由其他兩款自研編譯器（Oxygene和C＃，Silver與其共享后端及工具鏈）的使用情況推斷，Silver有望被所有開發者采用——從小型獨立單人工作室到大企業。

InfoQ：你們是否打算支持蘋果Swift參考手冊中所定義的完整版Swift語言？何時支持Swift 1.2？

Sic：對蘋果Swift語言的支持，我們會盡可能向規約和參考手冊靠攏，這是我們的目標。是的。由于平臺的原因，會有一些小差別，但我們會試著把這種差異最小化。

我們小心翼翼、如履薄冰地在一些必要的地方額外添置了少數特性。例如.NET和Java平臺上存在相當多無法處理的異常，于是我們在語言中需要的地方新添了異常相關的catch/throw擴展。這些擴展平時不會給你帶來困擾，它們只會在需要時出現。

如果你已經從蘋果的開發書籍或網上的示例中熟悉了Swift語言，那么只需要學習極少的相關具體實現，就可以高效地使用Silver了。

至于Swift 1.2, 我們的編譯團隊之前的習慣是，積極更新編譯器。Swift 1.2的絕大多數重要更新都已經在團隊內部實現，本周晚些時候（今天是2月18號）會隨下一個測試版本一同發布。希望Swift繼續高速迭代，我們時刻準備著。

InfoQ： 能和我們分享一些 Silver 工具鏈的相關細節么？你們在每個平臺上都有自己的編譯器么？

Sic：基本上是這樣，我們有一個覆蓋三種語言（Oxygene，C#現在是Swift/Silver）的編譯器和三個目的平臺（NET, Java/Android 和Cocoa）。

三種語言都支持這三大平臺。事實上，甚至會在同一項目中混合多種語言，這相當酷。三種語言共享同一后端，因而Silver其實已經非常可靠了，這是因為Silver背后的編譯器架構經過10多年的錘煉，久經考驗、構建精巧。

平臺后端代碼各自獨立，.NET平臺生成的是IL代碼，Java/Android平臺則是JVM字節碼，而Cocoa所用的是經（與蘋果相同的）LLVM后端生成的原生CPU ARM和x64代碼。

除了編譯器本身，Silver還有面向所有平臺的廣泛工具鏈支持，其中很多工具鏈能夠在三種語言間共享。例如，我們為Java、 Android、Mac及iOS在Visual Studio中集成了部署和調試支持，使得Windows開發者可以在其IDE上輕松完成全面調試。在Mac上，我們有自主研發的名為Fire的開發環 境，用以支持三種語言和三個平臺。

InfoQ：可以通過Xcode構建Swift應用的前提下，是什么原因使你們最終在OS X平臺上選擇了Fire？

Sic：坦白說，如果用Swift在Mac平臺構建Mac或iOS應用是你的所有工作，那么，選用Fire和Silver的理由并不那么充分，也許更多會 是一種偏好。Fire是一種相當輕量級的IDE，就個人而言，即便是純粹的iOS項目，我也喜歡用它，而不是Xcode（我這樣說，就像有人說喜歡 Xcode一樣）。但，我很可能有偏見。

在需要使用不同語言或不同平臺的情況下，Fire（和Silver）才會真正大放異彩。例如，你想用Swift（或C＃或Oxygene）創建Android項目，或為iOS和Android創建兩個應用項目并在其間共享代碼。

但即便從事的只是些并不共享代碼的個別項目，相比因切換項目而不得不“換擋”的工作方式，使用相同的工作環境更贊，比如你有一個 Android應用，一個iOS應用，兩者毫不相關；或是一個iOS應用，一個服務器后端，像我前面所提的例子一樣。如果你兩邊用的都是Silver，就 不用使用兩種語言在兩種不同的IDE上工作了。

Silver（特別是Fire上的）的開發體驗相當不錯，IDE不會形成妨礙，你可以集中關注代碼本身。Silver無視平臺。我們認為Silver能夠吸引單平臺或多平臺的開發者。

Silver正在內部測試，計劃“年初（2015）”發布。有興趣使用Silver測試程序的開發者可以 注冊 并免費獲得程序。

查看英文原文： Silver Brings Apple's Swift Language to .NET and Android