
Kotlin, the Swift of Android - tilt
http://blog.gouline.net/2014/08/31/kotlin-the-swift-of-android/
======
lvillani
I tried Kotlin to write the first version of a small internal application used
at the company I work at. On the plus side is IDE support and the fact that
you can mix and match Kotlin with existing Java code.

In the end though, I found the syntax "funny" in some places and slightly less
verbose than Java but not enough to justify using it. The underlying Android
API is so verbose that Kotlin by itself is nearly useless.

We ended up dropping Kotlin and rewriting the thing in Java. In terms of lines
of code both versions are nearly the same.

~~~
higherpurpose
Google really needs to begin rewriting all Android APIs in Go. Not an easy
task, but beats doing nothing, and also using something like Kotlin to make
Android development _slightly_ better.

~~~
gruvector
Go is pretty low level compared to (even) java, not much of a win in terms of
expressiveness or error handling. Seems like a lot of effort with minimal
benefit.

~~~
vorg
> Go is pretty low level compared to (even) java

I've found Go and Java to be at the same level of abstraction. Go has
interfaces and structs, but leaves out implementation inheritance because its
authors feel that's one of Java's bad points. Go also leaves out method
overloading which causes us to think hard about what to name the numerous
methods.

I don't know about the suitability of Go for Android though. Does Google have
a secret project going on?

~~~
on_and_off
Officially, Java is the language of Android. Have a look at the last I/O
fireside chat if you want to hear from them. Again, officially, they "don't
see what rewriting all the API in another language would bring". Google is
deeply involved in improving Java with projects like Guava, Dagger, ..

There is a project to make Go run on Android, but it is only a hobby project
from one of the Go engineers and only target the NDK (so no access to
Android's APIs).

We have no way to know what they are working on under the covers, we need to
assume that as far as we know, Java is here to stay... IMHO, with Dagger,
Guava, EventBus and a couple other niceties, it is possible to be productive
with Android. For me the biggest weakness of the platform from a dev point of
view is that many things that are part of the platform on iOS (like elements
of a ListView animating themselves when added/removed) need to be coded (with
dirty and lengthy hacks). This part is improving (I am looking at you
RecyclerView & RenderThread) but there is still a lot of ground to cover.

------
bad_user
Android apps tend to be compressed for distribution by means Proguard and
Pack2000. Not perfect, but it does tree-shaking and so normally you pay only
for what you use.

I don't really buy the small JAR size argument. In a real project, you care
about not reinventing the wheel, so you end up importing needed dependencies
anyway, like from apache commons or guava, or stuff for
serialization/deserialization, or whatever - I would rather have a couple of
hundred KBs extra than having bugs or spending effort on reinventing the
wheel. Scala's library for example is pretty big (can't remember the size, 10
or 20 MB?), but it has things I want in it and with tree shaking it can be
translated in a dependency of very reasonable size (couple of hundred KB), a
technique which also makes feasible Scala.js, a Scala to JS compiler.

------
pavlov
It's an important point in Kotlin's favour that it's developed by JetBrain,
the company that makes Google's official Android IDE.

If/when Google decides it's time to sanction a Java replacement on Android,
the language designed by their tool provider seems like the obvious choice.

~~~
hhariri
Minor correction. We don't make Android Studio. Android Studio is based off of
the IntelliJ IDEA platform, which is what we develop.

~~~
pavlov
Oh, thanks for the correction. I had assumed that JetBrain develops Android
Studio and Google just puts their stamp on it.

~~~
IshKebab
Well that pretty much is what happens. JetBrains wrote IDEA and the Android
support for it. Google made some small modifications (some good, some
detrimental), and packaged it with the Android SDK.

The biggest change was to switch to gradle which is a more powerful build
system but also much buggier (at least in the current Android Studio). They
also lots of useful Android-related tools and lints, and a fair helping of UI
bugs.

Still, beats Eclipse by a country mile.

~~~
pjmlp
Only when it offers better support than CDT for the NDK and all those Grandle
bugs get properly fixed.

------
V-2
I have been fiddling with Kotlin for last few days. It is trivial to get it
working in Android Studio, which is a plus already. It's not nearly as verbose
as Java, and for one thing, it gives me LINQ that I've been missing from C#.

~~~
sitkack
How well does the bytecode convert with RoboVM?

~~~
talloaktrees
Kotlin works very well with robovm. In fact, there is a game written in kotlin
on the iOS store called True Fool that uses robovm

------
simplestyle
How does Kotlin compare to Groovy for Android development? Are they similar
beasts when used for Android development, as in they both need to import their
runtimes?

~~~
masklinn
The article touches upon that: Kotlin has a runtime you need to import, but
it's significantly lighter-weight than Groovy's or Scala's, and the method-
count overhead is relatively low (half that of Guava without proguard).

Looking at the relevant jars, groovy 2.3.6 is 4.3MB[0] while Kotlin 0.8.679 is
353KB[1] (there's also a 503KB kotlin-stdlib, not sure what the comparison
should be to but it compares very favorably even including both)

For other references, Scala 2.11.2 is 5.3MB and Clojure 1.6.0 is 3.5MB[3]

[0]
[http://mvnrepository.com/artifact/org.codehaus.groovy/groovy...](http://mvnrepository.com/artifact/org.codehaus.groovy/groovy/2.3.6)

[1]
[http://mvnrepository.com/artifact/org.jetbrains.kotlin/kotli...](http://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-
runtime/0.8.679)

[2] [http://mvnrepository.com/artifact/org.scala-lang/scala-
libra...](http://mvnrepository.com/artifact/org.scala-lang/scala-
library/2.11.2)

[3]
[http://mvnrepository.com/artifact/org.clojure/clojure/1.6.0](http://mvnrepository.com/artifact/org.clojure/clojure/1.6.0)

------
PudgePacket
Just a side question, the author mentions method count as a downside of
introducing alternate JVM languages. Does the method could slowdown/bloat apps
somehow?

~~~
masklinn
It's way more fucked up than that, Dalvik is limited to 65k _invocable_
methods per dex file: [https://medium.com/@rotxed/dex-skys-the-limit-
no-65k-methods...](https://medium.com/@rotxed/dex-skys-the-limit-
no-65k-methods-is-28e6cb40cf71)

> You can reference a very large number of methods in a DEX file, but you can
> only invoke the first 65536, because that’s all the room you have in the
> method invocation instruction.

> […] the limitation is on the number of methods referenced, not the number of
> methods defined. If your DEX file has only a few methods, but together they
> call 70,000 different externally-defined methods, you’re going to exceed the
> limit.

~~~
michaelcampbell
Is this limitation going away (or otherwise obviated) by ART?

~~~
myko
Yes, but not just yet:

[https://plus.google.com/107130354111162483072/posts/VEy3JChn...](https://plus.google.com/107130354111162483072/posts/VEy3JChn3N2)

Mentioned at about 27:55 in this podcast where a member of the ART team is
interviewed: [http://androidbackstage.blogspot.se/2014/08/android-
develope...](http://androidbackstage.blogspot.se/2014/08/android-developers-
backstage-episode-11.html?m=1)

~~~
masklinn
You're talking about a similar but different issue: there's a fixed-size meta-
information buffer, if you go above you crash. Increase the size of the buffer
and you're good to go (which is what more recent android versions have done),
the new ART might make the buffer dynamic instead of static (no idea).

The 65k method problem is a problem of the dex format itself, because method-
invocation instructions take "the method" as a 16-bit index, it can't be fixed
by the runtime, the dex format has to be changed to fix it (either by adding
new opcodes or by changing existing ones).

~~~
myko
I think you are mistaken - in the audio:
[http://storage.googleapis.com/androiddevelopers/android_deve...](http://storage.googleapis.com/androiddevelopers/android_developers_backstage/Android%20Developers%20Backstage%20Ep%2011%20ART%2C%20pART%202%20%28Trash%20Talk%29.mp3)

Around 27:55 they discuss that they plan on lifting the limit. Indeed
modifying the dex format is talked about and it is mentioned that it is a
future goal.

They also speak about multidex, the interim backwards compatible fix which
does not require modifying the dex format (but uses a hack) and will make
modifying the dex format easier in the future.

~~~
masklinn
> I think you are mistaken

The question was whether ART would fix the issue. The answer is not "yes but
not yet", it's "no" because the runtime has no bearing on the issue.

------
krschultz
Kotlin looks like a very nice addition to Android ecosystem. It meshes pretty
seamlessly with Java and takes a few of the obvious syntactic pains away.

I think as the Android build system improves using other languages will become
more common.

------
u124556
Built in Singletons? I'd like to see built in Dependency Injection instead.

------
kryptiskt
Swift has algebraic data types and pattern matching, this doesn't. It just
seems to be Java with a paintjob and some bells and whistles tacked on. I
don't see the point of such a timid new language.

~~~
emmanueloga_
Ceylon does better in this regard [1]. Ceylon and Kotlin share some features
and aesthetics but Ceylon provides a lot more power over java8 than a nicer
syntax for lambdas, e.g. algebraic types. I'm also excited about Ceylon's
module system [2].

1: [http://ceylon-lang.org/documentation/1.0/faq/language-
design...](http://ceylon-lang.org/documentation/1.0/faq/language-
design/#language_features) 2: [http://ceylon-lang.org/blog/2013/04/11/about-
modules/](http://ceylon-lang.org/blog/2013/04/11/about-modules/)

------
richardwhiuk
It would be nice if more of this was folded into Java itself, rather than
existing as a new language - as the author notes a lot of it is in Java 8.

~~~
hhariri
Java 8 does introduce a few features that are available in Kotlin, but AFAIK
Java 8 won't be available for Android for some time. In addition, Kotlin makes
a lot of constructs more succinct, including but not limited class
definitions. So it's not only about what it adds, but what it "takes away" too
IMHO.

~~~
higherpurpose
> AFAIK Java 8 won't be available for Android for some time

Pretty sure it will _never_ be available on Android. Best case scenario Google
moves away from it. Worst case, it will add some new, similar features to
Dalvik VM. But I doubt they are considering adopting Java 8.

~~~
dtech
Do you have any basis for these claims? Java 8 contains many useful language
improvements and Google has shown with Java 7 that it will adopt these (albeit
incredibly slowly)

~~~
rst
Remember the Google/Oracle lawsuits over the use of Java technology in
Android? Bringing in JVM changes from newer Java releases risks giving Oracle
grounds for another lawsuit (covering the patents and whatever copyrights may
apply to the new features), and it's not likely Google wants to run that risk.

(This is why the Java 7 features that they have adopted are the "syntactic
sugar" that _doesn 't_ require JVM changes, and leaves the code running in the
phones as-is.)

------
wasyl
Does anyone have some performance comparison betweend projects written in pure
Java vs straightforward Kotlin? I don't feel that method count is performance
measure, I'd rather see some fps, method calls/sec or something like this. Or
I'm wrong about method count?

~~~
mike_hearn
There was someone from JetBrains doing profiling and chatting about it in
#kotlin (freenode IRC) the other day. Oddly, he found some things got faster
in Kotlin for no obvious reason. Some JVM optimisation magic, I guess.

Kotlin is a much more pragmatic language than many such new ones. They are
building it for use in their own products including performance sensitive
products like IntelliJ. For example it has an inline method attribute. This
may seem remarkably low level for a modern JVM based language intended for
industrial use, but there's a point to it: it lets you use lambda functions
and misc features that rely on them without extraneous memory allocations.
Applied consistently this sort of thing can make the difference between "a
lovely language that's too expensive to use" and "a lovely language that is
deployable". It's not auto-inferred because otherwise you wouldn't be able to
make libraries that have stable ABIs with Kotlin.

Generally they seem to be targeting zero performance degradation over Java
even when using the advanced features, which is nice to see.

~~~
orangy
Yep, I agree. Mostly because it was me digging into JMH :) Indeed we are
measuring and optimising. This is still early work in progress, but we have
some good results already:

    
    
        inline fun calc<T, R>(value: T, fn: (T)->R): R = fn(value) 
        inline fun identity<T>(value: T): T = calc(value) { it } 
    
        // This is optimised down to loading constant value 1 into variable x
         val x = identity(1)
    

Besides having nice syntax for lots of everyday things Java developers are
doing, we want to provide means for doing it effectively, clearly and
maintainably.

------
aikah
Any reason to use this over Groovy ? Will Groovy has a few drawbacks, i found
it much simpler and easier to use than scala.I personnally prefer a quick java
over something that has to much features.Anybody tried both and can compare?

~~~
gruvector
Groovy performance is pretty poor in general and is mostly used for writing
build scripts. It's a scripting language whereas Scala and Kotlin are better
suited to writing large systems. Groovy seems to have stagnated outside of its
use with gradle, whereas Scala continues to grow.

~~~
rufugee
I'm curious...why do you say it has stagnated? Seems to still be pretty
popular...especially in the gradle and grails spaces.

I've done quite a bit of groovy and have really enjoyed it. After years of
doing java, and then years of ruby, and then trying to go back to java, I
really struggled with rationalizing the move to myself given the immense
amount of extra work java required to do anything productive. Groovy made the
jump palatable, and in many ways I prefer groovy to ruby.

That said, I haven't written any code which is particularly performance
sensitive yet. However, groovy now has @CompileStatic, so you can statically
compile the perf sensitive bits. I'm sure that doesn't completely solve the
problem, but it's an option.

I really do hope Kotlin succeeds thought. Having something in the middle of
groovy and scala syntax-wise with no performance concerns and the great java
integration groovy brings would be spectacular.

~~~
vorg
> the great java integration groovy brings

I recently wrote some scripts using Clojure to test some Java I'd written. It
worked great, and I could use a macro to get rid of some duplication that
functions couldn't.

------
niutech
Nope, the Swift of Android is called Xtend: [http://blog.futurice.com/android-
development-has-its-own-swi...](http://blog.futurice.com/android-development-
has-its-own-swift)

------
seanhandley
You can write shared functionality in pure Ruby using RubyMotion then write
your view layers for iOS and Android and have them each compiled correctly to
native apps for each platform.

I'd rather use Ruby than Swift or Kotlin.

~~~
klibertp
> I'd rather use Ruby than Swift or Kotlin.

Yeah, but there are people who'd rather use Haskell, Clean, Agda or Idris.
Kotlin, Swift, Rust and other such things seem like a reasonable middle ground
from this perspective.

------
talloaktrees
I've been looking a lot at Scala and kotlin recently. Other differences aside,
Kotlin has an 800kb runtime compared to Scala 2.11's 11mb runtime. That's
quite a difference

~~~
frowaway001
How do you come up with 11 MB?

Even the whole library jar file which is much more than just the runtime is
only 5.5 MB.

But even then it doesn't matter anyway. Android apps are ProGuarded before
deployment (regardless of the language used) and the overhead in Sclaa's case
is a few dozen kBs.

~~~
lvillani
The less code has to be converted to the DEX format, the better. Sure, build
tools have improved somewhat (incremental DEX compilation comes to mind) but,
still, every time I pull in some rather big (~1 MB) .jar file in my project I
get noticeably longer build times for non-production builds.

With a 11 MB dependency, even production builds take considerably more time to
complete and that gets in the way when you want to test the app on a
production setting and you have to wade through a lengthy build process each
time you fix a bug.

~~~
frowaway001
There. Is. No. 11. MB. dependency.

And even if there was, it wouldn't matter because it would be done once and
then deployed directly on the development device.

Really, can we just stop making stuff up?

------
morazow
Scala for Android,
[https://news.ycombinator.com/item?id=8192406](https://news.ycombinator.com/item?id=8192406)

~~~
V-2
I gave up trying to set it up for Android. It just sucks, and there is nothing
but random blog entries on how to get it done. If someone pointed me to
reliable resources on how to get it to work, I'd appreciate it very much (as I
like the language itself)

~~~
eeperson
Have you looked at the usage guides for the various plugins [1][2]?

[1] [https://github.com/jberkel/android-plugin/wiki/getting-
start...](https://github.com/jberkel/android-plugin/wiki/getting-started) [2]
[https://github.com/pfn/android-sdk-
plugin#usage](https://github.com/pfn/android-sdk-plugin#usage)

~~~
V-2
I can't remember anymore what I tried and what I didn't :) At the end, I
mostly tried not to bang my head against the wall.

Anyway, even your second link stresses: "The primary IDE recommendation is
IntelliJ, not Android Studio nor Eclipse". My IDE of choice is Android Studio,
and it not being particularly recommended is a red light to me already. Maybe
I'm just traumatized.

I'm surely lazy. I wish Google made Scala support for Android official and
integrated it seamlessly.

~~~
Nullabillity
> Anyway, even your second link stresses: "The primary IDE recommendation is
> IntelliJ, not Android Studio nor Eclipse". My IDE of choice is Android
> Studio, and it not being particularly recommended is a red light to me
> already. Maybe I'm just traumatized.

Seriously? Android Studio is just a stripped down IDEA with an extra plugin
anyway. If you already use AS, there is zero reason not to just import your
config into IDEA instead.

------
izolate
A lot of these things are already in Dart, which has a much nicer syntax. If
they're going to switch from Java, I'd want them to choose Dart.

~~~
seanmcdirmid
Dart supports shared memory multi threading?

~~~
tkubacki
DART has Erlang style actors that support concurrent threads of execution - so
yes. Shared memory no AFAIK, but Dart seems to have nicer syntax.

~~~
seanmcdirmid
If dart doesn't support ordinary threads, it might be meant for the web and
not as a language for writing android apps.

------
dodyg
Java 8 is not coming to Android anytime soon or ever. Kotlin is quite a nice
alternative language for the platform. And the IDE support is superb.

------
serge2k
> This means that if text2 is null, the replace() method call is ignored and
> no NullPointerException is thrown.

I don't understand why this is preferable.

~~~
tjdetwiler
It's intended to be shorthand for:

    
    
      if (text2 != null) {
        text2.replace()
      }
    

Essentially they're moving support for @Nullable and @NotNull into the
language and compiler.

[https://www.jetbrains.com/idea/documentation/howto.html](https://www.jetbrains.com/idea/documentation/howto.html)

------
V-2
Extension functions:

"For those familiar with Objective-C, this is similar to categories."

Or just the same as extension methods in C#...

------
benjamins30
Does this have the interactive programmer-friendly tools that Swift has?

~~~
rsynnott
It doesn't have anything like Playgrounds, but, as it's from Jetbrains, it
does have very good IntelliJ support.

------
Void_
Are there any projects for Swift to JavaScript?

------
knwang
Can Swift be the Swift of Android?

------
LeicaLatte
Clickbait?

