Nice to see them dropping the silly "System.out" prefix for println. A minor point, but it was rather silly. See other Kotlin examples here:
http://kotlin-demo.jetbrains.com/
Kotlin copies much of its design and syntax from earlier Scala versions e.g. the use of companion classes, constructor syntax etc. but leaves out some of the most useful features found in Scala today. Kotlin, unlike Scala cannot make existing classes implement a new interface, nor can it do structural typing (http://codemonkeyism.com/scala-goodness-structural-typing/). It would be great if they added these features, without them I feel like I'm getting a poor man's Scala. The only consolation is that Kotlin does string interpolation, something which is being added to Scala 2.10 anyway.
I don't want to get into an argument over Scala, but let's just say that Scala has some really cool features from a language design perspective, but many of them come at a HUGE cost to ease of learning or reading code, or to IDE support. Scala's power, which is without a doubt very impressive for a statically-typed language, comes at a price which many organizations are unwilling to pay.
I just compare Scala's growth to that of Java or even Ruby (since RoR). I also think that this adoption is not the result of Scala's power features but in spite of them (really, there was little choice in the statically-typed JVM languages). But I really have no skin in this game, and Java does need a modern replacement to fill a certain niche, and I have a hunch it will be Kotlin.
Is this a theoretical thought or a practical consideration?
I think the Java ecosystem needs a good, mature language now ... and I fear Kotlin is still at least half a decade away from being stable. While Kotlin compares nicely to Java 7, we need to keep in mind that both Java and Scala won't stop being developed. So pragmatically speaking, it will need to compete against Java 12 and Scala 2.16.
The thing frightening me about Ceylon and Kotlin is that they both seem to have that the "language design is hard, let's go shopping" approach which burdens developers with stuff only the language designer should care about.
I will certainly have a look at the approach they take towards type constructor polymorphism.
