Live data from Hacker News

Android now supports Kotlin

venturebeat.com

191–200 of 225 posts

Re: Android now supports Kotlin

#191
post #163

Earlier quoted context omitted.

For better or worse, Gradle is the official Android build tool, so why spend resources in something else?

Because Bazel produces faster, reproducible builds, and can far better combine native and JVM code. It’s a huge improvement.

But isn't part of the Android SDK, Gradle is.

As I learned through the years, anyone that decides to step outside the SDK tooling accepts the lack of productivity that entails the extra work, making the unofficial tools fit into the SDK expectations.

So why should JetBrains spend development resources (work time * salary / hour) into something that isn't a standard tool just to get brownie points?

Re: Android now supports Kotlin

#193
post #191

Earlier quoted context omitted.

Because Bazel produces faster, reproducible builds, and can far better combine native and JVM code. It’s a huge improvement.

But isn't part of the Android SDK, Gradle is. As I learned through the years, anyone that decides to step outside the SDK tooling accepts the lack of productivity that entails the extra work, making the unofficial tools fit into the SDK expectations. So why should JetBrains spend development resources (work time * salary / hour) into something that isn't a standard tool just to get brownie points?

Because Bazel is partially already supported. Google uses it internally a lot, and a lot of the Android buildfiles have been / are being migrated step by step either from Make to Ninja, or from Make to Bazel, long term.

Re: Android now supports Kotlin

#194

Earlier quoted context omitted.

I have a project with Kotlin + Dagger + DataBinding. Annotation processing works fine with kotlin. First setup can be a pain though, especially if you are not familiar with Android or the gradle build system.

I'm hopeful that with official support this process will become smoother

It was rough because I had to write the script myself (one year ago). You need to know some things that are not obvious at first glance, like the fact that the databinding compiler is versioned with the android plugin for gradle.

Nowadays, you can just copy paste it from an existing github project.

Re: Android now supports Kotlin

#195
post #176
post #23

Earlier quoted context omitted.

I don't see what it has to do with relationships. Convince us why Scala would've been a better choice?

Objective-sounding reasons: Scala has got a large library ecosystem, it's demonstrated an ability to retain backwards compatibility while evolving the language (Kotlin may yet get this right (well, no it won't, but that's getting into a more technical argument) but many languages don't, and Kotlin simply hasn't been around long enough to see whether it's any good at handling change). Developer reasons: Scala is a muc…

> Scala has got a large library ecosystem

Kotlin has the entire java ecosystem to work with.

Re: Android now supports Kotlin

#196
post #176

Earlier quoted context omitted.

Objective-sounding reasons: Scala has got a large library ecosystem, it's demonstrated an ability to retain backwards compatibility while evolving the language (Kotlin may yet get this right (well, no it won't, but that's getting into a more technical argument) but many languages don't, and Kotlin simply hasn't been around long enough to see whether it's any good at handling change). Developer reasons: Scala is a muc…

> Scala has got a large library ecosystem Kotlin has the entire java ecosystem to work with.

So has Scala (to exactly the same extent as Kotlin, despite what Kotlin pushers will tell you), it's just got a better additional library ecosystem than Kotlin has.

Re: Android now supports Kotlin

#197

Earlier quoted context omitted.

I call Kotlin Android's Swift.

Heaven forbid they just support Swift instead.

You'd need to rewrite Swift to run on the Android VM (a big undertaking) or fork the Android frameworks to work well with Swift. That's a much bigger undertaking than supporting a language which was created for the JVM and specifically made for interoperability with Java.

Re: Android now supports Kotlin

#198
post #101

I hope this will change Jetbrain's attitude towards supporting Kotlin Android rules in Bazel (or anything other than gradle). Last time I asked, they are not very interested[1]. [1] https://discuss.kotlinlang.org/t/android-support-in-kotlinc-...

Don't forget you can use Kotlin to write your build files for Gradle (since Gradle 3.0 was released almost a year ago) which Android Studio auto-completes 100% of the time (rather than 80% of the time as with Apache Groovy). Gradle 3.0 also switched to Kotlin as its "preferred" language for writing addins, so conceivably you could use the Kotlin language for everything in the Android build chain.

Huh, that's a really useful tip, thank you.

Re: Android now supports Kotlin

#199
post #18

Post in JetBrains/Kotlin blog: https://blog.jetbrains.com/kotlin/2017/05/kotlin-on-android-...

I really wished they would choose Swift. It's open source now, and many developers would definitely enjoy having to learn only one programming language for developing native apps. Unfortunately, corporate policies and hubris matter more in these things.

And the massive technical undertaking of making the Android framework work with a none Java interoperable language?

Kotlin was already mostly working with Android thanks to a community effort. This announcement just gives it Google's blessing and gives you all the Kotlin tools by default in Android Studio. Going forward they'll likely be working closely with the Kotlin developers, but this was primarily community driven.

Re: Android now supports Kotlin

#200
post #191

Earlier quoted context omitted.

But isn't part of the Android SDK, Gradle is. As I learned through the years, anyone that decides to step outside the SDK tooling accepts the lack of productivity that entails the extra work, making the unofficial tools fit into the SDK expectations. So why should JetBrains spend development resources (work time * salary / hour) into something that isn't a standard tool just to get brownie points?

Because Bazel is partially already supported. Google uses it internally a lot, and a lot of the Android buildfiles have been / are being migrated step by step either from Make to Ninja, or from Make to Bazel, long term.

It isn't neither part of the Android SDK nor NDK, or even supported in Android Studio, which actually matters to Android developers.

Actually the NDK is not even finished migrating from makefiles into CMake, let alone switching to even something else.

As you describe it is work in progress, not fully done, without any perspective if it will ever be part of the official SDK.

Also last time I checked AOSP sources where actually slowly being migrated to GB, the only place where Go is kind of used in Android.

So what is again the business value of supporting an unofficial tool, spending development resources, just for getting a few brownie points?

Post reply on HN