The CommonsBlog

A Fuchsia Future? Part Three: A Tale of Two Languages

Fuchsia is not just a difficult-to-spell name of a color. It is also the name of a “skunkworks” project inside of Google building a next-generation operating system for all form factors. This week, I’ll explore various aspects of this and my expecations of its impact on Android developers and apps.

Today, I’ll look at what you’ll be using to write your Fuchsia/Flutter apps.

The official app development language for Flutter and Fuchsia is Dart.

Dart is a perfectly cromulent programming language. My guess is that when it came time to choosing an app development language for Fuchsia, Google wanted a language that they control, given what happened with Oracle v. Google. Google created Dart. Dart is not limited to Fuchsia — in addition to all of the Flutter platform targets, Dart can be used elsewhere, directly or as converted (“transpiled”) into JavaScript.

However, Dart is YAPL: Yet Another Programming Language. Admittedly, it it more popular than is Kotlin in the January 2019 edition of the TIOBE programming language index. However, I have to imagine that Kotlin has greater momentum, as while Flutter has its fans, Android is huge, and Android app development is moving in a Kotlin-y direction, given Google’s firm push.

Kotlin, like Dart, supports multiple runtime targets. Android app developers focus on Kotlin/JVM, as while Android does not strictly use the JVM, the Kotlin/JVM compiler’s Java bytecode output can be consumed by Android’s build tools, just as javac’s output can. But there is also Kotlin/JS, where Kotlin is “transpiled” into JavaScript. And there is Kotlin/Native, whose tools generate LLVM bytecode suitable for use in iOS projects and elsewhere.

Could Kotlin target something that works on Fuchsia?

If nothing else, it should be possible to create a Kotlin/Dart transpiler. Dart is an ALGOL-family language, as is JavaScript. Dart uses classes, objects, methods, variables, and such. Creating a transpiler may not be simple, but it should be doable.

It is also conceivable that Kotlin could be compiled into bytecode that can be consumed by the Flutter build tools. Dart itself supports a VM mode, and (if I understand it correctly) Flutter apps can use that mode in development. Flutter apps get AOT-compiled into machine code for distribution through app stores. I don’t know all the gory details of their implementations, but if the AOT-compiler works off of the DartVM bytecode, perhaps Kotlin could generate that bytecode much as it does JVM or LLVM bytecode.

If Kotlin can generate Flutter/Fuchsia-compatible code, in principle the Flutter APIs could be used from Kotlin. Worst-case, it would be more like how Kotlin is used with iOS today, where the iOS UI is written in Swift (or Objective-C [shudder]), but lots of business logic can be shared via a Kotlin/Multiplatform module. In the Flutter case, the Flutter UI itself might wind up having to use Dart, but one could share code with non-Flutter projects using Kotlin/Multiplatform.

Obviously, there are lots of technical challenges here, and it’s entirely possible that it is impossible for Kotlin to target Dart the way it does the JVM, JavaScript, and LLVM.

But if we see Kotlin supporting Dart in the future, to me that is a fairly strong sign that Fuchsia is “for realz”. JetBrains is not going to throw resources at Kotlin/Dart just for grins. JetBrains will try to build a Kotlin/Dart target if either:

  • They feel that adding Dart support is important for Kotlin to be available for more platforms, and the only significant platform that is uniquely Dart is Fuchsia, or

  • Google throws money at them to make a Kotlin/Dart target

And while we like to think of Google as having these huge piles of money lying about, in reality Google has budgets, no different than any other firm. Google is not going to hand JetBrains a chunk of cash for Kotlin/Dart work unless there is a decent chance for it to be worth their while in time.

So, I am watching JetBrains fairly closely, as a Kotlin/Dart target would say a lot about the future of Fuchsia.

Tomorrow, I’ll take a look at what developers should be considering, as we ponder Fuchsia’s future.

Find out about new posts on the CommonsBlog via the Atom feed, or follow @CommonsWare on Twitter!