转载

Silver：将Swift引入.NET和 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

感谢丁晓昀对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

正文到此结束