I frequently see people making the mistake of conflating a programming language with the platform. It's an easy mistake to make, because these days, most major platform vendors have one language (or two) that they closely tie to and associate with the platform:

C# is for .NET development. Swift is for Apple's platform. And Java (the language) is, well, for the Java runtime (and variations, the most popular and relevant these days being Android). Right?

But if you really think about it, a programming language is really "just" the syntax you write in; it could, and should, be completely decoupled from the platform – which is the APIs you are writing code against.

That is the idea and promise that Elements is built upon and fulfills. But while that is great, I do think it's one of the factors why people initially have a hard time grasping just how Elements works, or why it really is a "best of both worlds" approach to development.

Platforms vs. Languages

Elements strictly separates thinking about platforms, and thinking about languages.

It (currently) supports four distinct languages, three well-known, invented by other companies that we adopted (and improved), and one that we devised ourselves:

  • Swift
  • C#
  • Java (new in Elements 9.2!)
  • Oxygene

Forget for a moment that the first three of those traditionally are associated with a specific platform. Don't think "Swift means iOS", don't think "Android means Java".

These are just languages. They define a syntax for how to express a program's logic. How to check conditions, how to run a loop, those kinds of things.

If you see a bit of Swift code, say

for i in 0 ..< count {
    print(i)
}

this code really has no platform association; it just "does something". There's nothing iOS or Apple about that for loop, it could just as well run on Android, in a Windows app or on a server somewhere.

Elements gives you four languages to choose from. You pick the one(s) you like best, and that's what you write your code in. You make that decision purely on which language you work in best, which syntax you prefer or, maybe, based on what existing code you have that you want to use.

Now, let's talk about platforms. There are several different operating systems out there that are currently relevant: iOS and Android (which uses the Java platform) on the mobile side, macOS, Windows and Linux for desktops and servers. And .NET/Mono and Java are sort of "meta" platforms that provide their own OS APIs and a runtime environment.

What platform you develop for largely affects what kind of code you write. You may deal with ARKit on iOS, with a Google Map control on Android or an NSOutlineView on macOS. That's code you write that is deeply tied to a platform ‐ but, if you think about it, it really has nothing to do with the language you use.

Who says you can't use Swift to drive your WPF application, C# to fill that NSTableView, or Java to drive that ARKit app?

Elements provides support for four sets of platforms:

  • .NET (and Mono) – for when you write code that runs on any variation of the .NET platform. Windows apps, Unity, ASP.NET, Mono, you name it. It's also great for command line tools and and servers.
  • Cocoa ‐ for writing native apps for the Apple platforms, be it iOS, macOS, tvOS or watchOS.
  • Java – to write code against the Java runtime, or Android's Java-based standard SDK.
  • and finally, under the umbrella term "Island", Elements supports compiling against CPU-native OS targets, such as Windows' Win32 API, the native Linux APIs, and Android's NDK (which Android devs normally only use for low-level stuff and high-performance graphics code where Java doesn't quite cut it).

But: none of these platforms are coupled tightly to any of the languages we discussed earlier.

You make two completely independent decisions:

  1. What language(s) do you want to use; most people or companies will choose one, but you can also mix languages within a project, or choose a language per project.

  2. What platforms you need to target. Want to write an iOS app? A Linux server? A Windows app? Or maybe apps for Android, iOS, Windows and Mac that share code? Fine.

What you pick for (1) does not depend on what your goal or need for (2) is, nor vice versa.

You can use your favorite language, regardless of platform. And you can target any platform, without having to resort to a language you don't know, don't want to learn or don't like.

But is it Native?

Yes! Whatever platforms you develop for, that's, well, the platforms you develop for. You have access to all the platform's APIs, directly and unencumbered. And on binary level (and to the user) your app will be indistinguishable from one created by the platform's "official" compiler.

(Well, our compiler team could probably tell them apart by little details as to how we optimize paths differently/better, or the like.)

  • A Java or Android app will be JVM byte code, and look, feel and behave like any Java or Android app.
  • An iOS or macOS app will look, feel and be as fast as any app written in Xcode.
  • A .NET will be indistinguishable from one created with, say Visual C#.
  • And an Island app will work the same as one created in, say C or C++.

It will be a truly platform-native app.

Interested?

Learn more about the Elements compiler, and all the languages and platforms here.