Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though.
So, you can have Kotlin on iOS via RoboVM. But that's kind of expensive. Also, RoboVM brings its own heavy runtime environment with its own class hierarchy, garbage collector, and the need to bridge between that world and the ObjC runtime.
Or you can have RemObjects's almost-Swift (http://www.elementscompiler.com/elements/silver/) on Apple platforms, Android/JVM, and .NET as well. I call Silver almost-Swift because some permanent differences from real Swift are documented here: http://docs.elementscompiler.com/Silver/DifferencesAndLimita... For that reason, though I like the Elements compiler's approach of targeting each platform in the most native possible way, I'd recommend using their C# front-end or even their Oxygene language (a Pascal derivative) instead.
> Having two similar languages on different platforms isn't as useful as having the same language on both platforms, though.
Sure, but as we've seen from the WebKit/Blink fork, Google and Apple aren't capable of sharing stewardship of something that central to both of their platforms in the long run. So it's not going to happen.
iOS and Android both disappoint me as being one-language-dominates platforms; I much prefer the paradigm of Windows, Linux or OS X, where you can have apps in Python, apps in C, apps in VB or Lisp or FORTRAN or Brainfuck, all running as first-class citizens. It feels like a real step back for me.
It's a step back just as the walled garden ecosystem is in general, but it did make it easier to find documentation and hire developers, and thus grow the platform.
>How well does Kotlin perform on Android? Can you use all the native stuff?
Not only is Kotlin a great language, it is also a good fit for Android since it outputs bytecode and is entirely interoperable with java.
The only cost of using Kotlin are the 6k methods that it adds to the apk. You can call all the native Android APIs. Of course they are not idiomatic kotlin code, but you can cope with that, especially since the Kotlin team has written some Extensions methods in order to facilitate this process.
>Are there some successful apps written in Kotlin?
I know that Expedia uses some Kotlin for its new features (since there is full interop, you can switch gradually).
I am working alongside 12 or so other engineers on a successful Android app. Most of us (especially the more experimented) would like to switch to Kotlin but we get a lot of resistance from an extremely change averse team leader (we have just convinced him to start using EventBus and are still pushing for Dagger 2 & Rx).
This kind of move is always complex for a large team though. You need to get everyone on board and up to speed with this new language. Even though I think that kotlin is very easy to learn (especially for a java dev), this is still a significant effort.
Personally I think a good way to set a foot in the door (with Kotlin) is to use it for unit tests. Hey, unit tests aren't production code, so what's the worst that can happen, right? Plus in many projects - sadly - tests are still perceived as an optional thing.
And Kotlin is very well suited for tests, because it's so expressive, DSL-friendly etc. There's also this pleasant framework: http://jetbrains.github.io/spek/
If you can't convince your team (or bosses) to switch to Kotlin, start writing unit tests in Kotlin. They can even coexist with Java ones, so I believe this is an easy way in. And once people get to see it at work...
we already have started making more and more tests several months ago (the code base we inherited is awfully architectured and entirely untested), I will try to win over our test engineer with that idea.
JetBrains has been using Kotlin in production of IntelliJ IDEA, YouTrack and other products for quite a long time now. We have more than 250’000 LOC of Kotlin in production at the moment (plus about as much in the Kotlin project itself). While some of our projects are entirely written in Kotlin (account.jetbrains.com), others have introduced it to existing Java codebases, as we planned initially. We reached the level of interoperability where freely putting Kotlin alongside Java is transparent for Java clients: Java can be called from Kotlin and vice versa, sources can be mixed in one project, resulting .class files are totally compatible with Java tooling.
Some folks use Groovy (I've attended a talk about it on one of the DroidCons), although the tooling is a bit lacking, and there are some other drawbacks such as long build times.
Groovy for Android isn't being maintained. The programmer maintaining it was retrenched by Pivotal 12 months ago. Groovy's used quite a lot for scripting, but the more recent statically-typed additions for Java and Android aren't being used much and have QA issues.
Yeah you've got full interop with Java. There is some overhead in terms of executable size, but not significant. As for commercial apps written in Kotlin, I have no way of knowing, but there's a lot of open-source projects. It wasn't long ago that Kotlin reached 1.0, and prior to that I would myself err on the safe side not recommending it for production yet. It's been improving very fast though.
