Why you should start using Kotlin for Android today ?

1. Language and environment are mature.

The IDE plugin works smoothly, and already allows many of the features that you love and use in Java. Therefore, working with Kotlin is awesome in that sense.

It’s interesting to know that before its final version, the language spent several years in alpha and then in beta. And that even before the beta came out, there were people using it in real projects.

2. Android development much easier

The only viable alternative to Java for developing great apps on Android. Other alternatives such as Scala are tremendously heavy, and compilation times and tools can’t be compared.

Android 2.3 you just need to install a plugin, and in 3.0 the whole process will be seamlessly integrated.

And from there everything works just like if you were working with Java: you can run from the IDE, debug without issues, do refactors, use instant run … Everything you can imagine is still there and can be used.

3. It’s (way) More Concise Than Java

the biggest advantages of Kotlin over Java Android development: you are able to solve the same problems using fewer lines of code that can only translate into a more reliable code with fewer bugs and crashes on the UX side.

This is not to mention all the other benefits that derive from code conciseness, including code that is:

• Eeasier to maintain
• Easier to read
• Easier to apply changes to when needed

Some of Kotlin’s features that are “responsible” for its code conciseness are:

• Data classes
• Smart casts
• Type interface
• Properties

 4. It’s much safer than Java

We can’t only talk about nulls. The whole amount of code we save on Kotlin reverts to:

• Less errors: If there is less code, it’s more difficult for that code to fail, and therefore becomes more stable.
• When the compiler helps you detect those errors at compile time, they never happen on runtime.
• The code is easier to understand when someone else reads it and, again, it’s more difficult to introduce errors.
• It’s clearer what the code does (and not how), because we avoid any boilerplate that only serve to overcome the lacks of the language.

Definitely, it translates into more work done in less time, more stability, and less time spent in fixing bugs.