The end of the Kotlin+Android love story


#1

Google plans to replace Android with Fuchsia within the next 5 years. Fuchsia will support C/C++, Go, Dart, and Rust as programming languages. Java technology will then no longer play a role on Google devices - at least not in the form know today.

Today Android is the “killer application” for Kotlin because it is a welcome upgrade for developers that had to use dated Java versions otherwise. If Android and with it Java disappears from mobile devices the Kotlin+Android love story will end.

I wonder what that could mean for Kotlin. In principle Kotlin could be a good language for Fuchsia, too, since you can compile native apps with llvm. But Google seems to have no plans in this direction. And what is about the announced “Kotlin Foundation” that Google and JetBrains wanted to start? Is this still the case? Will Kotlin still be relevant for Google?


#2

Could you provide a prooflink for your statement? Google is developing Fuchsia, but it was intended to replace android befor kotlin and during Google-Oracle wars. I am not sure, it is still correct. Also, Fuchsia will still support JVM and therefore kotlin, so I do not see the problem.

Correct me if I am wrong, but Dart failed to make a place for itself in the community, so it is fairly possible, that Kotlin will take its niche.


#3
  1. Kotlin has three ‘versions’ for a lack of better word - Kotlin JVM, Kotlin JS and Kotlin Native. Even if Kotlin JVM will no longer work, if Fuchsia will support C/C++, then it will most likely be possible to add it as a compilation target for Kotlin Native.
  2. Fuchsia OS is still in development and I haven’t seen any official Google anouncement as to its release date or it replacing anything - if you have please provide the link.
  3. It won’t be easy to simply replace Android. Google would need to convince both hardware manufacturers and software developers to make the switch, and even end users may simply decide that they prefer another system and Fuchsia will die (like Windows Phone for example). And then there’s the question of all already existing Android devices - will it be possible to simply upgrade them to Fuchsia OS or will they have to be replaced. If it’s the latter I doubt people will throw away all theri phones, tablets, TVs, watches and what not and race to the stores to buy shiny new Fuchsia OS powered replacements (even if they could afford to).

#4

Fuchsia will most likely be capable of running Android apps, once it is ready. Just like ChromeOS can run Android apps today.


#5

My thoughts came up after reading this Bloomberg article. Some more information can be found in the Wikipedia entry about Fuchsia. There you can see that Google adopted Swift (and not Kotlin), what make it unlikely that Kotlin, as a similar language, will play an important role for that platform.


#6

Here is the later reference:

Mind you, that’s just the ambition, according to the report – and Google disputes that specific part; CNET understands there’s actually no five-year plan yet. Google CEO Sundar Pichai and Android/Chrome boss Hiroshi Lockheimer reportedly have yet to sign off on any road map. In a brief statement, Google said Fuchsia is just “one of many experimental open-source projects” at the company, but declined to comment further.

Five year plan is a myth. And Fuchsia is intended for smart home first. I think, that all speculations about languages are preliminary and based on random comments.There is not such a thing like support for swift, since swift is compiled to native code. The kotlin native could do the same. It is the question of tooling and toooling for android is provided by JetBrains (see where it goes?).

In my personal opinion, Fuchsia project is a great thing. Android is (at least was) great, but it is time for something new. Also I am very excited with the idea that someone finally decided to ditch linux in favor of microkernel OS. I hope it will still have first rate support for JVM, because the platform is really good. As for kotlin, it is our work to make the language ecosystem so good, it is very hard to replace, in this 5+ years.


#7

Rust was mentioned in this thread. The Rust compiler uses LLVM, which probably means that if they add Fuchsia as a Rust target, then they probably do that by making a LLVM to Fuchsia compiler. This should in theory make Fuchsia a target for any language that compiles into LLVM, including Kotlin/Native.


#8

I don’t know of the truth of this claim, but can relay my personal experience. I have been an Android developer for years and I love Kotlin. I am not currently doing Android development as my day job due to lack of opportunities where I live. So in my spare time I recently dove into the world of flutter and if I had my way I don’t think I personally would ever go back to regular Android development. There is just something about Flutter that makes it very enjoyable. So I am not sure I care if traditional Android development went away. But no matter what they will have to allow old apps to run for many years.


#9

We are moving off topic (if there was one at all), but I just read an article about flutter and there were some code samples for interface design. I haven’t written in android for a long time and Flutter probably looks better then vanilla android, but compared to the kotlin type safe builders used for example in tornadofx, it is really ugly.


#10

Can you link the article?


#11

I read it in Russian, but here is the original: https://hackernoon.com/flutter-5-reasons-why-you-may-love-it-55021fdbf1aa


#12

I agree that Kotlin is definitely better than Dart and I am constantly wishing I had some Kotlin features in Flutter (e.g. extension methods and the ability to leave out the !%@# semicolons), but the conclusion you quickly come to is that Dart is good enough and it really doesn’t get in your way that much. My experience echoes a lot of what I read in this article: https://medium.com/yakka/flutter-doesnt-need-kotlin-or-anything-else-5773965d5905.

The code will look a lot different because flutter UIs have deep nested widget trees. Instead of packing loads of functionality into each widget that has lots of state and complexity you instead have many small single purpose components that layer on extra functionality. This does have a slight drawback of discoverability in that often you struggle to figure out how to do something because you haven’t discovered this other widget that you can wrap your widget with to get it to do what you want.

The real beauty is the way that state is separated from UI and is built in a functional, reactive style. Most widgets are actually immutable. You want a piece of UI to change you have a stateful widget wrapper that when the state changes creates new instances of the immutable widgets. Pair this with redux and it is a really good experience.

Here is a better article that describes why flutter is revolutionary: https://hackernoon.com/whats-revolutionary-about-flutter-946915b09514


#13

To come back to the original point: The default UI technology for Fuchsia will probably be Flutter and there won’t be a great desire to use Kotlin (instead of Dart). So todays most prominent use case for Kotlin will probably disappear. But there are still some years to come and we could be happy that Android served as a gateway drug to Kotlin.


#14

Anyway, the future of mobile apps is neither Android nur Fuchsia. It is progressive web apps.


#15

wtf, would you mind actually reading what you are linking? there is a (still unmerged) PR for the swift open source project to support compiling to fuchsia. This is like saying “Apple adopted Kotlin” because kotlin can compile to native iOS binaries.