RemObjects Silver is a “free implementation of Apple’s Swift programming language” aimed at making it possible to natively compile Swift code on the .NET, Java, and Android platforms in addition to Cocoa and Cocoa Touch. RemObjects’ stated goal for Silver is to stay as close a possible to Swift, yet some differences do exist at the moment accounting for differences in the underlying platforms.
Some of the limitations are due to Silver’s beta status and are thus bound to disappear at some point. There are also a few permanent differences and limitations, though, which are expected to remain indefinitely since they are related to platform-specific requirements. Those limitations affect: - Array, Dictionary, and String types, which cannot be efficiently implemented as structs (by-value semantics) and are thus classes; - default intializers, which will be created only for structs and not classes; - extensions declared in a different project than the extended class.
For similar reasons, Silver also has some language extensions, including exceptions, iterators, partial classes and more. Silver provides a complete development environment running on Windows and Mac. On Windows, it integrates with Visual Studio, while on Mac a specific IDE called Fire is provided.
InfoQ has spoken with marc hoffman (sic), chief architect at RemObjects,v to learn more about Silver.
Could you explain what Silver is and what benefits it aims to bring? What kind of developers you have in mind for it?
Silver is a compiler and surrounding tool chain that let’s you build projects for three core platforms — .NET, Java/Android and Cocoa — using our own implementation of Apple’s new Swift language. Silver works in Visual Studio for Windows developers, and comes with our own lightweight IDE called Fire for developers working on Mac.
The benefits Silver brings come on multiple levels. In general, Swift is a great language that is already seeing huge adoption and that many millions of developers will be learning over the next few years. Silver allows you to leverage that knowledge to develop not just for the Apple platform, but also for .NET and Java/Android.
We believe Swift will be appealing both to developers who come from an Apple platform background and want to expand to cover other platforms, but also to pure .NET or Android developers — simply because it is a great language two work in, and has many advantages over Java and even C#.
Of course Silver will be especially interesting to developers who want to leverage shared code between applications for different platforms. While we explicitly discourage people from writing “cross-platform apps” — that is, one single app that just gets built for each platform and runs everywhere — there’s still a lot of “business logic” type code that can be shared when building dedicated apps. For example, if you are writing a mobile app for iOS and Android (and maybe Windows Phone), Silver would encourage you to design each app from the ground up for the respective platform, but back-end code, for example for communicating with your servers, modeling your internal data, or performing calculations — depending on the purpose of your app — can easily be shared between the apps. Even when you’re not sharing code between projects, using one language and IDE across projects helps avoid friction, as you don’t need to rotate between different programming environments. For example, you might be writing an iOS app and the back-end server in ASP.NET — both using Swift, both in the same IDE.
Also, and I think that argument is often overlooked when asking “why use this compiler?”, I believe that Silver is simply a great tool to work in — it’s a rich language and a full-featured and comfortable-to-work-in IDE (whether you work in Visual Studio on Windows, or in our own Fire IDE on the Mac), so there is plenty of argument to be made to choose it over Java or C# (or Apple’s own Swift and Objective-C) just for those benefits — even if you don’t care about multiple platforms at all.
Judging from the usage we see for our other two compilers that Silver shares the back-end and tool chain with (Oxygene and C#), we expect to see adoption across all kinds of developers — from small independent one-man shops to large enterprises.
Are you supporting the full Swift language as defined by Apple in the Swift Reference Guide? When will you be ready for Swift 1.2?
Our goal is to support the Apple Swift language as closely to the spec and reference guide as possible, yes. There will be minor differences guided by the platforms, but we try to keep those to a bare minimum.
We’re also adding some minor additional features where needed, but we’re very cautious and doing that delicately. For example, on the .NET and Java platforms there is pretty much no way around having to deal with exceptions, so we added extensions to the language to catch and throw exceptions, where needed. These extensions are done so that they don’t get in your way if you don’t need them, but are there if you do.
In general, the idea is that if you are familiar with the Swift language from Apple’s book and the numerous examples found online already, you can sit down and be productive in Silver with very little (if any) additional learning specific to our implementation.
As for Swift 1.2, our compiler team has a track record of being very agile with driving our compilers forward. Most of the important changes for Swift 1.2 are already implemented internally, and will be in the next beta drop later this week (today being February 18). We expect Swift will continue to evolve rapidly, and we’re prepared.
Could you share some details about Silver’s toolchain? Do you have your own compiler on each platform?
Essentially, we have one single compiler that covers three languages — Oxygene, C# and now Swift/Silver — and three target platforms — .NET, Java/Android and Cocoa.
Each language can target each platform. In fact, you can even mix different languages within a project — which can be be pretty cool.
All three languages share the same back-end, which is the reason that Silver is already so solid — it’s essentially standing on 10 years of solid work and a compiler infrastructure that is time-proven and well established.
The platform back-ends are of course separate for each platform, generating IL code for.NET, JVM byte code for Java/Android, and CPU-native ARM and x64 code using the same LLVM back-end as Apple, for Cocoa.
Beyond the compiler itself, we have extensive toolchain support for all the platforms, all of which is pretty much shared between the three languages. For example, we have deployment and debugging support for Java, Android, Mac and iOS integrated with Visual Studio, so developers on Windows can have the full debugging experience right from their IDE. On the Mac, we have our own development environment called Fire that supports all three languages and all three platforms.
What is the reasons for using Fire on OS X, when you can build Swift apps through Xcode?
To be frank, if all you are doing is building Mac or iOS apps in Swift, on your Mac, then the reasons for choosing Silver and working in Fire are pretty slim, and it mostly comes down to taste. Fire is a very lightweight and lean IDE and personally, I like working in it a lot more than Xcode (and I say that as someone who does like Xcode), even for pure iOS projects. But then, I’m probably biased ;).
Where Fire (and Silver) really comes to shine is if you want to work with either different languages, or different platforms, for example if you want to create an Android project in Swift (or C# or Oxygene) or create two app projects for iOS and Android and share code between them.
But even if you’re just working on individual projects that don’t share code, it’s nice to have the same work environment and not have to “switch gears” as you switch between projects. Say you have an Android app and an iOS app that ave nothing in common. Or an iOS app and a server back-end, as in my example above. If you are working in Silver for both, you don’t have to work in two different IDEs with two different languages.
In general, Silver — especially in Fire — will provide a great development experience where the IDE does not get in the way and you can just focus on your code. Regardless of platform. We think it will appeal to both single-platform and multi-platform developers alike.
Silver is currently in private beta and planned for release “early this year (2015).” Developers interested in participating in Silver beta program can sign up to the program at no cost.