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.
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
javac’s output can. But there is also Kotlin/JS, where Kotlin is “transpiled”
suitable for use in iOS projects and elsewhere.
Could Kotlin target something that works on Fuchsia?
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.
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.
Need an extra hand with your Android app development project? CommonsWare can help — reach out for details!