作为“苹果 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 )关注我们,并与我们的编辑和其他读者朋友交流。
活动推荐:
2023年9月3-5日,「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题,策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229(微信同手机号)。
评论