Android’s Commitment to Kotlin | Hacker News Reader

Android’s Commitment to Kotlin

android-developers.googleblog.com

104 pointsWalterSobchak123 comments

At this point, I feel no language can compensate for the platform's out-of-date java libraries. I think Google has its priorities wrong: first should be recent java, second should be kotlin.

That was always the problem with google.

Look at chrome os fiasco. They had it for 6,7 years? They didn’t realized it until Microsoft did put effort to make their OS developer friendly that they should make chromeos developer friendly. Imagine how good chromeos was today if they have started to make it developer friendly in 2010 instead of 2017.

I disagree: they should just dump the whole ecosystem. Kotlin is a shabby bandaid, not because the language isn’t good (no comments there) but because the substrate is a mess of bloated, terrible, OO Java nonsense. Android development is just awful no matter the language.

I'm seriously not astrotrufing (for once!) but isn't Android itself shitty all round? Really complex OS that does a million things and all wrong. I have a phone where no fb is installed but fb services that cannot be stopped are running in the background.

I'm waiting for a Linux phone

Well, if your OEM installed crapware in the system/vender/OEM partition, that's not really Android's problem. All other apps/services are very removable.

It is the customer’s problem, so it is jointly a problem for Android and the OEM. Google may try to abrogate responsibility here as usual, but it doesn’t make it any less their problem.

Dunno, the answer is generally if you don't want crapware, buy a pixel.

But the pixels are (in my opinion) just such complete misses as phones. I’m not sure I’d want to use the latest Pixel if I got it for free, yet they charge an absurdly high price for it. I used to love my Nexus 4, and I liked my Nexus 5. It was absolutely amazing to have a real Google phone that I didn’t have to fight with in order to own for real at the lowest levels. But all the recent pixel phones have way too many trade-offs for me to use any of them as my daily driver. There are android phones out there which I like and would be happy to use as my daily driver, except on the software side they are way too locked down and I can’t root/flash them. I really wish phones worked the way computers do, I could just buy/build any hardware I want and run a fresh copy of Linux or windows on it under my complete control.

Why a complete mess? Sure Google is a popular target, much like apple, where a huge number of people chime in to complain. I've had every nexus and every pixel, all the way back to the HTC G1 on the first day it was for sale.

Sure choice of OS would be nice, but there's a huge number of man hours that go into making a nice touch UI. Something that experts don't tend to obsess over, unless paid.

The pixel's don't have a locked bootloader, and you could try one of the community builds, which I've done. But there's much less incentive lately. I used to root to tether, don't need to anymore.

Motorola also ships ~no crapware.

Why is that possible on android but not iOS phones? Serious question - I assume it’s because of the way android is built but I don’t know How that works. Why is there preinstalled installed software on Android phones at all?

Edit: I’m not sure why this question is getting downvoted.

When a device manufacturer makes a phone that uses android they can do a lot of stuff with Android without any issues (beside UX), other than messing with APIs and legal things. iOS is exclusively made by Apple and nobody can release their own iOS, so they always have prevented others (even the carriers) from putting their own apps on the phone before the user gets the device.

Could google change the terms and say that device manufacturers can not preinstall custom specific types of apps or services?

They've made multiple attempts to do this.

Manufactures really hate the lack of flexibility and there is a small amount of justification: new hardware often does need new controls.

And of course many people like the flexibility of Android.

Why would you buy an LG versus a Samsung? Too many android manufacturers to compete on just hardware alone. Even less so than Windows laptops and PCs. Customizing Android is the differentiator.

I personally hate it, but I understand why they do it. I just wish we could get a class leading vanilla Android phone. Pixel isn’t it.

Because the comparable phone to iOS phones aren't "Android phones" but "Pixel phones". Phones where the OS vendor also builds the hardware and controls everything.

It's just a different model. Single corporation stack gives you more consistency and less bloatware and OEM based stack gives you more market choice and greater accessibility.

It is Android's problem because Apple has proven it's possible to tell vendors and OEMs that they can't do that shit.

It's not an Android problem, as you only have the issue if you buy from a shitty oem.

Get a device with stock Android ROM and there is no issue

Frankly, i think the ONLY thing worse than Android (which you correctly peg as terrible) would be a linux phone OS.

I sometimes dream of an Arch Linux Android OS. If only...

Worse in what sense?

Nothing working consistently?

Things breaking randomly?

Nothing looking consistent?

Aping all the bad parts of the MS ecosystem while missing most of the good (I firmly believe desktop linux peaking with KDE 2 and has been consistently downhill ever sense)

Are Apps on android sufficiently consistent or don't "break randomly"? I don't think I see much of material UI outside of Google's own apps (from the times I look at my friends' phones, I use iOS).

No, like I said, Android is terrible, I just think given history a random linux phone os would somehow manage to be worse.

I consider iOS to generally get the job done pretty well.

I've had all these issues on iOS and Android. I'm dreaming of Gentoo/Xfce on my phone.

I had an n900 and it was amazing to use. the only reason I switched to android was that nokia stopped delivering updates and bugfixes to maemo/meego and then of course there was never another good linux phone.

Already there are some linux phone, like Librem 5 and pinephone.

There have been Linux phones before, like the Nokia N900. But there hasn't been the combination of marketing push and, perhaps, polish required for them to succeed commercially against other platforms.

https://en.wikipedia.org/wiki/Nokia_N900

Android is so shitty it has zero chance to succeed as a mobile OS.

Er, if you want pure android why don't you buy a pixel?

I guess because they are only available in a couple of countries, are expensive, and Google isn't any better than their OEMs keeping old devices updated.

Hadn't noticed the expensive side. They typically got half off within a month or two of announce. Got my Pixel 4XL 128GB for under $500 because of the Google Fi deal.

I still have a pixel 1 from 4 years ago that I think just stopped getting major upgrades. Not great, but not bad. My samsung note 4 was around a year behind on updates, and felt very slow because of all the crapware. I switched to a nexus 5, with a much lower spec and it felt MUCH better. Even simple things like hitting the home button had much less lag.

I did end up installing Cyanogen on the Note 4 which made it feel quite a bit snappier.

Whats sadder is they could invest resources into Kotlin Native and then build a Kotlin Native SDK (maybe built on top of NDK).

To paraphrase them, "it looks interesting and it is something that we are following on", which means nothing to me.

In any case Kotlin/Native doesn't bring nothing to Android itself.

ART makes use of AOT/JIT with code cache, which is much better than straight AOT on languages with reflection, dynamic dispatch and dynamic loading everywhere.

This is why they gave up on pure AOT introduced during Android 5 and 6 lifetime.

Then the NDK is tailored for writing native libraries for consumption from ART, only exposing C bindings, even though most of the code is actually C++.

So hardly a win having Kotlin/Native there.

Some of the newer stuff seems mostly well-designed, e.g. Room, LiveData. Lot of the older stuff is horrible. Kotlin is just slightly better than Java in my experience.

Overall I wouldn't say Android development is aweful, I think it's iOS is just marginally better. Swift is a nicer language than Kotlin but creating UI layouts sucks on iOS.

Even with SwiftUI?

I’ve been working on a MacOS app with Swift UI and I can say it has never felt easier. I love it.

How well does it scale in complexity though? These easy declarative UIs tend to have a hard ceiling in complexity and then you're forced to rewrite everything. How does SwitftUI scale to complex and animation heavy UIs?

Animation is very well thought out, and quite easy.

As for complexity, you hit the ceiling very fast, and the solution is to break up in smaller and smaller custom views and modifiers.

I haven’t gone too far down the rabbit hole yet but I find it similar to React in complexity ceiling. I’ve built some extremely complicated UIs in React. You just have to break up your views as complexity grows.

I haven't used SwiftUI but it looks great on paper.

The documented examples showing how LiveData “should” be used comprise a masterclass on overengineering.

In this context of disparaging the state of Android development, I must plead: take a hard look at Flutter/Dart. There are quite a few wins with it, including a pleasant developer experience. Declarative, composable, JIT compilation in dev, AOT compilation in production. The list goes on.

+1 for Flutter. Fast iteration, few gotchyas, decent documentation, a growing community, very fine control, but forgiving to those learning the framework.

I wish they'd dump Dart and replace it with basically anything else (Typescript? Swift? Kotlin?).

I'm not going to learn a new language which isn't used anywhere else AND a new UI toolkit just because Google's internal team structure has put them in a position to keep Dart going.

Back when Dart came out, it made sense. But Typescript came along, filled basically the same niche and got significant mindshare.

This horse has been beaten to death. They wrote an article about their choice of language, anyways: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf

And now, Swift, C# and naturally Kotlin are coming up with similar tooling, which kind invalidates the reasoning why it had to be Dart, above all languages.

Not to mention that Flutter experience isn't nothing more than cute to anyone that has experience doing UI design on Common Lisp or Smalltalk environments, which I reckon all of us are quite old for SV standards.

EDIT: Or if you really want to be amazed go play with SELF.

> And now, Swift, C# and naturally Kotlin are coming up with similar tooling...

That may be true, but right now, none of them has something as polished and usable as Flutter. And it looks like it will be many years before they do, all the while Flutter keeps getting better. So, if you have time to wait for these other platforms to catch up, go ahead while people who need to write code right now can enjoy something else.

> EDIT: Or if you really want to be amazed go play with SELF.

Oh come'on, are you really suggesting something that looks straight out of the early 90's is something that would amaze anyone today? Or there's something that actually looks and behaves modern out of the Self and Smalltalk world (certainly was not the case last time I checked, a few years back)?

Yes they have, language ecosystems with decades of battle field deployments in production, while Dart still tries to make itself relevant.

What I am suggesting is that the reasoning why Dart instead of something else is flawed and can only be naively bought by those that lack experience in UI domain.

How pretty those UIs used to look like is secondary.

Flutter is being positioned to rescue Dart, and make it meaningful beyond the AdWord team, the place where it landed when all Dart designers eventually left Google.

Where is the "Google's Commitment to Dart" blog post?

Personification of a programming language, nice. Flutter is ready to use, and is very rewarding for quickly building a specific use application; try it.

I think those reasons are entirely valid.

I don't see any reason why Typescript (for example) couldn't be made to meet them (relatively easily).

> I disagree: they should just dump the whole ecosystem. Kotlin is a shabby bandaid, not because the language isn’t good (no comments there) but because the substrate is a mess of bloated, terrible, OO Java nonsense. Android development is just awful no matter the language.

They should dump the most widespread mobile operating system ecosystem... because some people think API's are "OO nonsense"? Would you also want Microsoft to abandon whole Windows ecosystem just because WinAPI dates back to Win16?

This is insanity and completely ignores the reasons why ecosystems get popular.

On Android's case, free beer for OEMs above all.

The Android ecosystem got popular primarily for two reasons: the massive marketing effort by google and the plentiful dirt-cheap labor market in the kind of development paradigm Android is (awful, bloated Java where desperate $5/hr devs are plentiful).

If any of that would be the cause, Windows Phone would be a massive success.

Don't let your fanboyism blind logical thinking.

Windows Phone wasn't free beer for OEMs.

Kotlin has its own stdlib which runs on multiple platforms other than JVM.

I've used Java, Python, Ruby, Go and Kotlin. Kotlin is def my favorite and goto. Do you have any specific examples/complaints?

Interesting, I find Kotlin just marginally better than Java. It doesn't have checked exceptions which is annoying. You can't use a simple return in lambda functions.

As for other languages: Python is ok for smaller stuff. I don't like Go. My favourite languages are probably Swift and Julia. And recently, I've grown to really like C++ although I used to hate it.

What do you mean by simple return? If you need granularity you can `return@scope`

> Kotlin has its own stdlib

Barely. You can't even read a file without java.io.

They just announced a bunch of additions to the stdlib (including I/O) at KotlinConf in order to better support multiplatform

Agreed. I don't have any secret insider facts, but perhaps Oracle rubbed Google in a way that was not entirely pleasurable with the 10-years-and-still-going-on Java lawsuit..

Then adopting a JVM language is probably not the cleverest idea.

They also have Flutter and it uses Dart and is not dependent on old java libraries.

Flutter has similar tradeoffs as other cross platform tech such as React Native. Its great for simple apps that don't need platform specific UI or services.

Android is going the way of Google Reader. Kotlin is just to keep developers happy in the meantime before explicit deprecation. Fuchsia + Flutter is the new platform. Android Runtime will be emulated to allow backward compatible Android apps at a performance penalty, but Fuchsia will only have first class support for native compiled languages like Dart, Go, C++, Swift, similar to iOS.

</speculation>

You're assuming Flutter has buy-in from the Androidd team. Nothing shows that's true though.

I think it is more management having fun and watching which dog fights better, what Android team thinks is less relevant.

Jetpack Composer is obviously they fighting back to the continuous flow of Flutter questions at Android conferences.

Worse of all it that they don't acknowlege how bad it is for Kotlin as well.

What good is Kotlin's FFI to Java, if everything that you have at your disposal are out-of-date java libraries?

Even the new desugaring being done in R8 and D8 can only go as far as what ART is capable of, sometimes with worse performance, because the Java libraries rely on new JVM bytecodes and intrisic APIs.

So the only long term solution, assuming they keep ignoring modern Java, is to rewrite the world in Kotlin.

Arriving there, means that they could just rename ART into KVM and be done with it.

> At this point, I feel no language can compensate for the platform's out-of-date java libraries. I think Google has its priorities wrong: first should be recent java, second should be kotlin.

Kotlin works on all Android versions. Java updates don't. That doesn't mean Google shouldn't update the JVM on Android, it does however mean that any update to Kotlin immediately translates to wins across whole ecosystem, including people supporting Androids back to versions like 4.x, while Java updates don't.

It's a significantly better tradeoff - similarly like using TypeScript and polyfills gives you more powerful language on the web without restricting you only to newest browsers.

> Today, we’re proud to say nearly 60% of the top 1,000 Android apps contain Kotlin code

^^ This precise phrasing looks like an OKR.

OKR = Objectives and Key Results.

I had it look it up: ""collaborative goal-setting tool used by teams and individuals to set challenging, ambitious goals with measurable results"" -- among other definitions and graphs.

Is this management speak about vanity metrics? What do these measurements even mean?

https://library.gv.com/how-google-sets-goals-okrs-a1f69b0b72...

For example:

O: improve the usability of Kotlin

KR: 90% of top 1K Android apps have Kotlin deps

Q4 score: 67% (achieved 60%, goal was 90%)

The use of OKRs goes back to Andy Grove at Intel and while, like any tool, they can be misused they're definitely not just for vanity metrics. Some more useful OKRs might be things like:

- Increase number of signups for our app by 10%.

- Decrease the rate of customers churning off our platform by 20%.

- Reduce the median time it takes to ship a product out of our warehouse from 3 to 2 days.

I would be interested to know how much of that code is not boilerplate just pulled directly from google’s site explaining how to interface with X.

the problem with Android is the god awful API, not Java

this says it all: https://cdn1.hubspot.net/hubfs/2564010/The%20activity%20and%...

and it gets worse with every release

How is that Bad? Any Activity you have need to have proper lifecycle.

Every UI Toolkit has something similar.

Same events for IOS: https://developer.apple.com/documentation/uikit/app_and_envi...

no UI toolkit I've used has anything nearly as complicated or error prone

it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS

as a result you need to implement masses of error prone boilerplate crap for each and every activity, and nearly everyone gets it wrong in subtle ways

rotate your screen? better implement that serialisation perfectly else the user will lose state when they rotate their device

a lot of apps just disable features like rotation, because they're too time consuming to implement (and a nightmare to test)

I've never understood why rotating the app resets the state like this without writing code to handle it. I mean even a lightweight website can change its interface on rotation using only CSS without losing any state. It's been several years since I messed with Android development. I assumed it would be fixed by now.

Maybe that's because the website already has a serialized state - the HTML?

Because the alternative is not resetting the state and having to deal with the fallout. iOS does this and it's a source of even more strange bugs and side issues (based on doing cross-platform development across several teams).

This even led to the point where a huge amount of iOS apps simply banned rotation support to not deal with it.

It's just a different tradeoff. The underlying issue is that developers don't want to deal with storing the state which causes issues on lower end devices, which start to break as users multitask. The Android tools for that also aren't all that great - although I also haven't really seen any other toolkit do it better.

I'm an iOS developer and I'm not sure what you mean. Auto Layout provides enough hooks to take care of rotation. Why would rotation be a source of strange bugs and side issues?

Because not all the state and layout is handled by AutoLayout... and it has its own set of bugs. Heck, iOS apps themselves (iMessage, Springboard) and riddled with rotational layout bugs in iOS 12 and 13.

But how bad is it, I mean how many have you encountered so far? I don't doubt it, but in my years of iOS development, I haven't seen them.

Because web has “unlimited” memory. Mobile devices don’t, especially if you have an OS that aggressively kills apps to maintain decent battery life.

That said, I agree. Rotation should not be conflated with general app suspension. They are two different concerns. iOS does this.

And Symbian did as well.

> it was designed for phones with 4mb of memory that need to serialise their entire state everytime a form (activity) disappears because they don't have enough memory and google were too lazy to implement it in the OS

This is literally how iOS and other mobile toolkits work as well.

Windows CE and Symbian weren't as complicated and yet had even less memory to play with.

I agree and include the Toolchain mess as well.

e.g. Look at this issue[1] of Fragments in the LinearLayout, every now and then with the update of the SDK; the order of fragments changes i.e. with one SDK version the fragments are displayed in the order it was added 1,2,3,4 and with an update to SDK the order is 4,1,2,3 or any other.

For issues like this, every time I updated the SDK I had to spend lot of effort in testing and mitigating issues which were unwarranted. Meanwhile, my colleagues(whom I trained) who developed the same application for iOS didn't face such issues with API/Toolchain i.e. in iOS development what doesn't work, don't work and there is no hidden surprise with each SDK/Build Tools/NDK etc. updates because they are not updated separately.

[1]https://issuetracker.google.com/issues/37086731

I don’t see the problem with that diagram. It’s a consequence of your activity/fragment potentially being killed at any time, something you need to be aware of on mobile devices. iOS has same diagram.

When will we have a proper LSP implementation for Kotlin that is maintained not by a single person but a full blown team?

JetBrains is very short-sighted about this[1], putting their own IDE-s success over the success of Kotlin: not healthy for the language if you ask me.

A lot of developers using Kotlin are also gaslighting everyone who doesn't want to use IntelliJ for Kotlin as if using the editor of your choosing is some sort of madness.

Kotlin needs to be a foundation, it clearly has a big community to drive the language and its accompanying tooling and integrations. Kotlin needs to be completely decoupled from JetBrains to succeed outside the JVM/java legacy areas.

[1]https://discuss.kotlinlang.org/t/any-plan-for-supporting-lan...

Java, use any IDE you feel like it without any extra tooling.

Kotlin, here have InteliJ, oh yeah there is also this 2nd class plugin for Eclipse, and nothing else for the others.

I write Kotlin in vim, so it's not all devs using Kotlin.

Kotlin is a palliative that makes android dev nearly tolerable. Flutter is way better, even though Dart is not as good as Kotlin.

If Android is "Kotlin-first", why is flutter development done in Dart?

This is the Android Dev blog. Flutter is completely separate competing team

Flutter is an Android competitor that happens to be made by the same company.

Flutter is for those who want to use the same code on both Android and iOS... it's not a competitor to either, it wouldn't exist without them.

So Kotlin/Native then.

I’m a bit surprised Google hasn’t bought JetBrains. I bet they could get it for something like $2bn, which seems like an entirely reasonable price to pay to help improve the Android ecosystem.

On the flip side, Apple could buy JetBrains and seriously mess with Google, although that acquisition wouldn’t really make as much strategic sense.

> although that acquisition wouldn’t really make as much strategic sense

I dont know... maybe if apple bought jetbrains they could get them to rewrite xcode for them. :/

They already did, https://www.jetbrains.com/objc/

All of this is flowing in from the ongoing #KotlinConf

Jetpack Compose - a react like paradigm to build apps - is the future of android app development. And I could not be more excited.

Kotlin Multiplatform is on track (https://twitter.com/zsmb13/status/1202507590674112513) and will let ios apps be built using android studio without a Mac.

Kotlin 1.4 is touting upto 3x compiler improvements.

The question here is about the future of Flutter. Why do Flutter/Dart when Android is officially throwing its weight behind Kotlin and Compose is going to be every bit as react-y as Flutter or SwiftUI.

Same applies to why ChromeOS when Android? Politics.

Management is throwing money at them and watching who brings the best numbers back home, kind of thing.

Although like ChromeOS was forced to eventually support Android, I imagine that Flutter will eventually loose the battle.

Betting on Dart was never a clever option to start with, and now with Xamarin/WinUI, JetPack Compose and SwiftUI all demoing Flutter like experiences, it is clear that the reasoning for Dart being a special case isn't really the case.

I read Jetpack Compose will be able to support multiplatform as well. It will be a kind of flutter possible with Kotlin.

Well, it’s no surprise that google can run multiple projects that solves more or less the same thing.

I hold no grudge against Kotlin as the language. But underlying platform ... I'd rather prefer for them to switch to some native thing. It is really depressing to compare situations when I could whip up high performance small native GUI application and that atrocious monstrosity called Android studio produces regurgitates fat resource hogs.

It seems pretty likely that Flutter become the preferred stack at some point in the future given that it's used as the primary UI toolkit for Fuschia. That is still probably a few years away though.

This is as likely as Qt becoming a primary toolkit for Windows.

Truth is Kotlin and Swift are just a form of developer lock-in. A webapp written in React inside of a chromium webview is fast enough for most apps use cases. (NO REACT NATIVE PLEASE) The fact that Javascript is improved by many parties made the tooling and the performance of Chromium very fast. Babel+Webpack are years ahead of the build systems for both Android and iOS. Sublime and Atom are much leaner and better for coding than Android Studio and Xcode.

> are fast enough for most apps use cases.

If that's the case, then you don't need an app in the first place, and shouldn't develop one.

We don't need apps for every online store and every website.

But Android is slowly limiting the power of apps further and further, until there won't be any need for apps anymore.

The whole point of apps is to interact with hardware browsers don't support, to interact with files and provide high-performance functionality. To speak protocols browsers have never even considered supporting.

The point of apps is also to deliver a decent user experience that web pages just can't deliver.

PWAs and mobile web can deliver a decent user experience, if the developers actually bother delivering it.

No, not at all. A decent user experience requires using the native toolkit and behaving like an actual app, not appearing in the browser. Everything else is garbage.

> don't need an app in the first place

You need a native app if you need native features not offered by the browser but you can still use chromium webview for the UI. That's my use case at www.waiterio.com. A webview with React is fast enough for the UI but my app needs to speak with hardware using USB, TCP sockets and Bluetooth sockets.

I'm fully aware of WebUSB but it doesn't work well with the hardware I use. WebUSB seems like a prototype built to work for a demo with Arduino and that's it.

> But Android is slowly limiting the power of apps further and further

I believe Android is adding more fine grained control of apps power permissions but I'm not sure about the reduction in power.

> The whole point of apps is to interact with hardware browsers don't support

I agree on this, I don't criticize apps interacting with native API/SDK. I criticize the UI systems of native apps. On paper swift/kotlin should be fast but in practice Google put so much work in optimizing Chrome and Facebook put so much work on React that Chromium+React is faster than the native UI kits.

What about Dart and Flutter framework?

So if Google wins the Oracle case, does Kotlin support cease, or is there no going back at this point?

at the rate its going there is no stopping. Kotlin is a much nice experience that Java and far more projects are starting today with Kotlin rather than java

Then they better rewrite everything in Kotlin/Native.

Android, aka Kotlin Virtual Machine.

Nowadays I keep waiting for the JetBrains acquisition news story to pop up.

The main problem with java is oracle though which lobby patent trolls its way towards almost zero progress for java in the past 10 years. Sure they release java 13 now but compared with the feature-set of Kotlin and swift it's rather pathetic. Especially considering the planned price model of java 9+.

Reply on news.ycombinator.com