3 ms·

As somebody working all day with java in Android's context, Kotlin seems to pretty much address all my gripes with Java (again, java for Android, so no java 8 o

As somebody working all day with java in Android's context, Kotlin seems to pretty much address all my gripes with Java (again, java for Android, so no java 8 or 9 here). The only issue is that the Android framework code is still written in java, so it might not be that useful for the parts of an app that are deeply embedded in the android framework. I really hope that the google people take notice of Kotlin and decide to adopt it. Judging from the public commits in AOSP, java 8 & 9 seems to be the current official focus, but there is no way to know what is going on under wraps.

rattray 11y ago
> The only issue is that the Android framework code is still written in java, so it might not be that useful for the parts of an app that are deeply embedded in the android framework. Kotlin promises 100% interoperability with Java, and Android appears to be a particular area of focus (Android Studio is based on Jetbrain's product, and Jetbrains makes Kotlin).
- on_and_off 11y ago
  it is indeed. Kotlin has gained some popularity among Android devs and is focusing on it. Still, it is hard to use all of Kotlin's features when you have to dialog with a java framework. So eg for UI code, you might end up with quasi-java code. I would still love to see Kotlin pushed as the platform's language or alternatively a Rust inspired language. Another big challenge of such a move would be the back compatibility story.
  - rattray 11y ago
    For UI code, consider checking out anko: https://github.com/JetBrains/anko https://github.com/JetBrains/anko
  - mike_hearn 11y ago
    Check out Anko. It's a good demo of how to use Kotlin's features to extend native Java frameworks. For instance you can define the UI using a Kotlin DSL rather than XML.
    - on_and_off 11y ago
      yeah, I have checked that out. As much as I dislike xml, I don't think I want to place my layouts in my code though. From what I have seen, Anko's answer to how to handle buckets is 'just do it by code'. I need to see how it works for very complex layouts. I have written several very complex UIs that I don't think would be expressed easily with Anko. Again, I should really have a try, it seems to bring some niceties that I would have to write custom ViewGroup code to do with the base framework. However my argument had more to do with the Android's API surface area than the UI in particular. How much does having to deal with a pure java API for something like Chromecast (again, insert any android API instead) hampers Kotlin code style ?

rattray 11y ago

> The only issue is that the Android framework code is still written in java, so it might not be that useful for the parts of an app that are deeply embedded in the android framework. Kotlin promises 100% interoperability with Java, and Android appears to be a particular area of focus (Android Studio is based on Jetbrain's product, and Jetbrains makes Kotlin).

on_and_off 11y ago
it is indeed. Kotlin has gained some popularity among Android devs and is focusing on it. Still, it is hard to use all of Kotlin's features when you have to dialog with a java framework. So eg for UI code, you might end up with quasi-java code. I would still love to see Kotlin pushed as the platform's language or alternatively a Rust inspired language. Another big challenge of such a move would be the back compatibility story.
- rattray 11y ago
  For UI code, consider checking out anko: https://github.com/JetBrains/anko https://github.com/JetBrains/anko
- mike_hearn 11y ago
  Check out Anko. It's a good demo of how to use Kotlin's features to extend native Java frameworks. For instance you can define the UI using a Kotlin DSL rather than XML.
  - on_and_off 11y ago
    yeah, I have checked that out. As much as I dislike xml, I don't think I want to place my layouts in my code though. From what I have seen, Anko's answer to how to handle buckets is 'just do it by code'. I need to see how it works for very complex layouts. I have written several very complex UIs that I don't think would be expressed easily with Anko. Again, I should really have a try, it seems to bring some niceties that I would have to write custom ViewGroup code to do with the base framework. However my argument had more to do with the Android's API surface area than the UI in particular. How much does having to deal with a pure java API for something like Chromecast (again, insert any android API instead) hampers Kotlin code style ?