I’m afraid you are missing the point here. It’s not about better marketing, which I’m sure they will have, but if there was something that Groovy had was “marketing”, either through Grails or Gradle. Still remember people shouting “Gradle or die” in conferences.
Gradle ≠ Groovy
I’d like to avoid more sidetracking, hence just briefly addressing that.
Groovy is certainly the foundation of Gradle but has been DSL’d to an extent that you can hardly recognise it as Groovy, the programming language, anymore. If it were really ever backed by a similar marketing force as Kotlin is now, people would acknowledge Groovy in Kotlin a lot more and marvel at Kotlin less for all the “borrowed” elements but instead more for Kotlin’s more unique features. That is only partially the case though.
The point is that Kotlin has been designed to be fully bytecode compatible with Java bytecode. This means that your instrumentation based libraries will still work on that same bytecode without having to try to figure out if the code is Scala or Groovy and add more complexity to work around it. There are plenty of libraries out there that require this bytecode to stay the same. For example, and I haven’t tried this, but say you create a Groovy Swing application with a file menu in it and run it on Ubuntu, I bet that the menu will fail to be shown in Mac style (on top of desktop).
I am sorry but I fail to understand what you are referring to. The basic principle of any JVM language is that very compatibility — Kotlin is no exception here. If a language does not compile to bytecode, it won’t run on the JVM — plain and simple. Java is (surprise :)) compatible, Kotlin is, so is Groovy, and any other JVM based language. Particularly Swing is not only regular bytecode but comes with a “native” Java background. If a Groovy application fails to adhere to system standards any other JVM application will too — be it plain Java, Kotlin, etc..
I really don’t know where you’d get the idea from Groovy would make Java code suddenly behave any differently. Maybe you’d like to elaborate.
Or are you possibly alluding that Groovy tampers with bytecode of existing classes? That is not the case with Groovy and — hopefully — neither with Kotlin.
Groovy has been improved over the years and has taken advantage of latest JVM features. Kotlin is still bytecode compatible with Java 6 which means that will not take advantage of all features yet.
There is virtually no difference between the two languages in that regard. Both go back to 1.6 and both can optimise for later versions. But to be honest, I am not sure why you’d suddenly add JVM version compatibility to the discussion and how that would be relevant.
In the end, developers should use what makes sense to them.
Not arguing that.
I was merely amazed by a lot of the statements under the original article and in subsequent responses. That ranges from ominous compatibility issues to null-pointer safety where people changed the topic mid-sentence and shifted the focus elsewhere. Sometime it can be a bit tricky to keep up with a conversation if people throw in random, unrelated soundbites from all directions and start “reinterpreting” things :).