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 ）关注我们，并与我们的编辑和其他读者朋友交流。