Kotlin's brilliance is how much less it's trying to do. It's truly narrowly focused on fixing what's broken in Java—not introducing an entirely new language that happens to compile to the JVM. That'll make adopting it in organizations much easier, converting code to it much easier, and so on.

That said, I never figured out why Xtend (http://www.eclipse.org/xtend/) never caught on, and it delivered most of what Kotlin is now offering, but with an even more Java-like syntax right out-of-the-box. Since Kotlin and Xtend are very, very similar, I suspect that Kotlin's ability to genuinely succeed will be mostly based on JetBrains' popularity how strongly they push it.

> I never figured out why Xtend (http://www.eclipse.org/xtend/) never caught on....

> ... with an even more Java-like syntax

I think you have your answer right there.

The other reason is that nobody likes the idea of having a language which compiles to Java source code.

People have no real problem with languages that compile to C or JavaScript, so I'm not really convinced that's the problem as such. The lack of source maps/#line pragmas in Java didn't help, I'm sure, but these are solvable problems if there's interest (as demonstrated by #line and source maps).

> The other reason is that nobody likes the idea of having a language which compiles to Java source code.

Why not? It seems like a good thing if there is a possibility that you might have to go back to Java (if that make sense) or if some time down the road it is simpler for maintainers to go over to Java by reading the compiler output rather than dealing with xtend, if they don't know it. It could also be great if you want to quickly know what the equivalent of what you are writing in xtend is in java - just compile it. That seems more interactive than having to google or look up on StackOverflow.

Of course this assumes that the compiler output is actually readable.

I thing it's because of the pain you feel when you try to debug in Xtend (coz its compiling to Java)

To me Xtend seems like an ideal Java++. I actually like that it compiles down to Java.

The only hitch is that the Xtend is still very much a work in progress. It doesn't support inner classes and anonymous classes!

Because we don't know what Eclipse wants to do with it.

I'm not really seeing the case for Kotlin. If I want the most powerful language possible on the JVM, I use Scala. If I want a clean and elegant language, I use Ceylon - I don't think you can get that from a language that keeps the Java standard library. Prior to Java 8 I could maybe see the case for a language that's just Java with lambda and a few other niceties, but now that Java 8's out, if I'm going to go to the trouble of switching to a new language I want a bigger return on that cost than Kotlin offers.

A good alternative for Java on Android given Google's fork and not so good support for Scala and Clojure on Dalvik/ART?

Oh, I just wrote my (one, rather simple) android app in Scala. Are there problems with it?

Executables are slower and bigger than Java even with ProGuard, specially given how outdated Dalvik GC/JIT are.

Maybe this will improve with ART.

Maybe they are slower to some extend, but for most cases it won't matter too much. I wrote simple game in scala and it was easy to constantly get 55-60 fps on newer devices: https://github.com/pkukielka/stronghold-defense

That being said I agree that jars are bigger and scala generates much more anonymous classes. Even with ProGuard that could be a problem on Android 2.3 or older. And ProGuard is a bit slow (for my game it was taking 30+ seconds for every build). Also Typesafe doesn't have plans for making scala first class citizen of Android.

So while Android development with scala is certainly possible there are few inconveniences which one should be aware of.

Nice game!

It tends to generate lots of anonymous classes, which can make your jar bigger.

I think it's massively less ambitious, which is a good point in its favour.

It might be the least ambitious new language of the last ten years!

I think that trophy is won pretty handily by Go.

I wanted to say Go as well, but compared to any other possibly-mainstream languages, Go is very innovative - it has fibres/goroutines, channels, and structural typing/lack of class-based inheritance!

The bar for what counts as "innovation" in mainstream languages is strikingly low.

All of which are available in other languages...

In addition to the fact that none of it's features are particularly novel lets remember that Go's founding ambition was "compile faster than C++"

And people disparage them for it, which is nuts. Google had a problem that they determined could best be solved by creating Go. So they did it, and presumably, they've solved their problem. That seems like a perfectly good use of incremental improvement.

Which raises an interesting point: what to people on the outside looks like a paradoxical combination of insane hubris and deep technical conservatism is probably simply what to Google's eyes looks like steady-state, responsible technical problem-solving -- c.f., hhvm and Facebook for a similar approach.

> Go's founding ambition was "compile faster than C++"

And Kotlin's is "compile faster than Scala"!

Actually, Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick. (Which doesn't completely excuse the "C++ tried that and it didn't work for them so WE WON'T" foot-dragging on other matters...)

>Go's fairly successful melding of static typing and duck-typed interfaces was a useful new trick

For those that don't know this feature is called structural typing: http://en.wikipedia.org/wiki/Structural_type_system

Also, OCaml uses structural typing too.

No it was not, there are lots of languages that offer similar capabilities.

The fact that mainstream developers don't know it, does not make it something that Go designers invented.

OCaml already had structural typing. Scala does too.

Actually I think Hack might've just surpassed it.

You mean, except Dart.

Let's just agree that Google couldn't design a language even if its life depended on it.

How about "Google has a surprisingly conservative culture".

I wouldn't call "ignoring stuff from 1970" conservative.

They're using Java very widely, you don't get much more conservative than that.

Plus, its interoperation with Java is so seamless, that adoption is both gradual and natural.