If a language or tool is officially supported, then that means the project maintainers (Google, in this case) promise to support its use with official documentation, priority bug fixes (for example, if an Android update breaks your app which is written in Kotlin and uses only public, non-deprecated APIs, Google will consider it just as high-priority a bug as if it were written in Java), and first-class access to new APIs as soon as they're created.
JetBrains is doing this, not Google. Google is only going to collaborate with JetBrains to help with the Android support.
> Android update breaks your app which is written in Kotlin
then it also breaks the same app written in java. Because the good thing about kotlin is that it is transparent, it generates bytecode as java does. So from the point of view of the platform there is no difference between kotlin and java.
> first-class access to new APIs as soon as they're created.
This makes me think you don't know how kotlin works. You can mix java and kotlin files in the same app and call methods from one to the other without problems.
> JetBrains is doing this, not Google. Google is only going to collaborate with JetBrains to help with the Android support.
Jetbrains isn't doing anything differently with Kotlin from what they've been doing for the past 7 years. The headline here is "Google officially supports Kotlin on Android," and that is what has HN so excited. Regardless of how the work involved in supporting Kotlin on Android is split, this represents a guarantee that did not exist before. If all Jetbrains employees were abducted by aliens tomorrow, Google will now still have committed to first-class support of Kotlin through the next couple of major versions of Android.
> then it also breaks the same app written in java. Because the good thing about kotlin is that it is transparent, it generates bytecode as java does. So from the point of view of the platform there is no difference between kotlin and java.
They share the same compilation target, not the same semantics and idioms. Just because Go, Haskell, C and LuaJIT all target x86 assembly does not mean a Linux kernel update won't break a properly-written program in one of those languages but not the others. This in fact happens all the time.
> This makes me think you don't know how kotlin works. You can mix java and kotlin files in the same app and call methods from one to the other without problems.
I was answering their question generically. But first-class official support means that, for example, if Google adds a new feature to the [Java] Android Runtime, they will, where relevant, now ensure it's implemented in the official Android Kotlin compiler as well as the Java compiler.
It is JetBrains who support it, Google is only going to collaborate with them to help them out and keep the support up to date.
You don't have any idea about kotlin, the API is exactly the same. It is the Java API for both Java and Kotlin. The support is more related with the tooling, no with the API.
Go, Haskell and C are completely different things. Java and Kotlin compile to bytecode and the JVM runs the bytecode. Both uses the same API in the same language (the bytecode). You only have to guarantee they target the same bytecode version, which is something Google cannot do anything about, it is JetBrains who decide. This is not like Java and C in Android. C has its own API which calls the Java API. Kotlin uses the Java API, and the JVM in the Android device doesn't know if the app was written in Kotlin or Java.
P.S. Actually Android doesn't use the compiled bytecode directly as it make some modifications, but the idea still applies.
