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.
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'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.
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.
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!
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.
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...)
