AAAAAgh! When will people see the light? I'm talking about Jython, of course. I just took a first look at a Kotlin tutorial: boo! Curly braces.
Jython is THE BEST LANGUAGE EVER.
Personally I think a bit of blame must attach to the developers for the fact that Google adopted another JVM language for Android that wasn't Jython. Don't get me wrong, the Jython developers are genii, but sometimes seem a little unworldly, perhaps. Jython should have been adopted for Gradle (rather than Groovy) and then for Android development.
All sorts of red herrings get in the way of people's appreciation of THE BEST LANGUAGE EVER: for example, people complain about slow start-up times... but in fact this is because so many Java classes are loaded into memory ... and it wouldn't take much to keep them in memory between runs.
Messing around with Java classes in ways you're not intended to (it feels a prim Victorian lady dressing in a bikini at times), with the brilliance of Python behind it all, is just the best thing you can do with your clothes on at a computer terminal. Oh, and throw in multi-threading, etc. And integrate pure Java whenever you like...
Is it too much to expect the world to one day wake up to its folly???? I fear so. Kotlin... bah!
Lorefnon
Open Web Enthusiast
Strictly speaking, Kotlin is not intended to be an evolution over any of these languages. It's true intent is to be an evolution over Java (and javascript) while being seamlessly compatible, and given the massive adoption of these languages it is a very pragmatic objective.
It is however, comparable to all of these because it directly competes with them across realms ie. JVM, Javascript (except Groovy) and even native (only scala).
Kotlin is a lot more focussed than Scala, which IMHO is practically a kitchen sink of academic ideas. Unlike attempting to reinvent how you would program, or giving you an overwhelming array of paradigms to pick and choose from, Kotlin identifies and fixes the pain points that plague java development: null pointer exceptions, explicit casts, generics with no type safety whatsoever, verbose beans etc.
It is opinionated in the sense that it assumes that the programmer is happy with object oriented development and brings in proven ideas from other paradigm (like pattern matching, lambdas, co-routines) conservatively to enrich the developer experience and solve problems (esp. concurrency) where traditional strategies have proven ineffective.
This is great because you neither end up with an anaemic featureset (eg. Golang) nor a multiverse of competing paradigms in the same language (eg. Scala, C++).
Conservatively including features implies the compiler authors can keep compilation times under check, ensure errors are sensible and it is easy to work through into a new codebase (compiling a large Scala project, or C++ project that heavily uses templates takes forever, Complex C++ templates result in horrendous compilation errors when things go wrong etc.).
And of course, this is a product coming from Jetbrains - who are probably among the most competent professionals working on language tooling.
Clojure and groovy are dynamic languages. JVM has evolved into a great platform for dynamic languages, and that is a great thing. But here we have a team which is way more focussed on tooling as opposed to facilitating the paramount flexibility of lisp world. It is only natural that they invest into a language that is designed to facilitate sophisticated tooling.
Many things that make Clojure great (homoiconicity, metaprogramming etc.) are simply not in radar of kotlin developers because they make assistive tooling incredibly hard.
It is not a coincidence that there is simply no tool in existence that can do complex automated refactorings for languages like ruby or clojure, in the same way Java IDEs have been doing for years.
Having said that, Kotlin does recognize that dynamic programming languages offer a level of productivity that is usually not found in compiled languages - and it does bring in some nice features from these languages vis. Groovy like DSLs, an REPL. Decent type-inference and smart casts alleviate much of the redundant boilerplate which is so common in java projects.
In an ideal world type systems will grow flexible enough to facilitate the same level of succinctness and flexibility as dynamic languages but languages like Scala clearly demonstrate that it is not an easy task and some really interesting problems and a steep learning curve hinders us from getting to that point just yet.
I strongly believe that compiler authors and language developers will keep working in this direction and this is evidenced in newer languages like Crystal which brings to the table an interesting approach towards transparent type safety .
For the rest of us, who need to get stuff done today, Kotlin aims to find a sweet spot in between overwhelmingly flexible dynamic languages like lisp and arcane languages with complex type systems, as well as between everything-should-be-a-class object oriented paradigm and side-effects-are-pure-evil functional paradigm.
And in that respect, it seems to have done a much better job than other mainstream languages eg. Java, C# and Javascript.
P.S. I am a full time javascript developer and have done most of my programming using dynamic languages.
P.S. I am also not claiming that Kotlin language tooling is at par with java tooling yet, but I do believe it has the potentially to be so.