Silver:将Swift引入.NET和 Android

jopen 9年前

原文  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