Kotlin is recommended in all circumstances where you would use Java. It largely uses the same concepts and libraries, however, it offers many new syntactic constructs which streamline common boilerplate patterns a lot. This often results in up to 25–35% less source code, but the generated bytecode remains about the same size and efficiency, and there is no loss of clarity.

There are many pros, but I would like to emphasize just a few features I find particularly useful:

  • Null-aware type system allows complete control over this aspect of JVM programming and prevents a lot of typical annoying mistakes. The benefits are largely the same as using the Optional class from Java 8, however, Kotlin offers a much more concise syntax for this via null-safe dereference (?.) and default value (?:) operators. Also, you declare explicitly what can or cannot be set to null (String vs String?)
  • Inline arguments make String generation so much less painful, because you don’t need to use either arcane formatting strings nor awkward concatenation.
  • Kotlin has functions as first-class citizens, which means that not everything is forced to be a part of a class, which means you don’t need to store your utilities in some awkwardly named container class.

Here is some code that shows off these particular points:

// Java 7
System.out.println("Hello, " + (user != null ? user.getName() : "Anonymous") + "!");
 
// Java 8
System.out.println("Hello, " + Optional.ofNullable(user).map(User::getName).orElse("Anonymous") + "!");
 
// Kotlin
println("Hello, ${user?.name ?: "Anonymous"}!")

Some more advanced topics:

  • Data classes (i.e. classes you only use to store some data, much like structs) do not need you to write the boilerplate equals/hashCode/toString/set…/get… methods that are always mindless boilerplate.
  • There is limited operator overloading, which is much better than the typical free-for-all other languages allow, turning your code into hieroglyphics
data class Complex (val x : Double, val y : Double) {
    operator fun plus(other: Complex) = Complex(x + other.x, y + other.y)
}
 
// ...
 
val c = Complex(0.0, 1.0) + Complex(1.0, -2.0)
  • Extension functions and properties allow for easy DSL creation, patching in missing functionality, separation of concerns:
val Int.days : Duration
    get() = Duration.ofDays(this)
 
val Duration.ago : LocalDate
    get()  = LocalDate.now().minus(this)
 
// ...
 
val yesterday = 1.days.ago
  • Inline functions allow extracting very common code patterns into convenient units without any overhead, as they are inlined directly at the call site:
inline fun  usingDatabase(db: Database, actions: Database.() -> T): T {
    db.openConnection()
    val answer: T = db.actions()
    db.closeConnection()
    return answer
}
 
// ...
 
val record = usingDatabase(db) {
    select(table, id)
}
 
// ... which actually compiles into this, without any 
// ... closure objects or an extra function call
 
db.openConnection()
val answer$$1 = db.select(table, id)
db.closeConnection()
val record = answer$$1 
// a bit of duplication, but we have abstracted connection management
// away from our core code, which is a huge gain in readability
// and one less source of bugs
  • Kotlin has an interesting way of calling functions with lambda parameters, which makes those function calls look more like built-in language constructs. Indeed Kotlin does not have a built-in synchronized keyword, because its functionality is completely covered by a standard library function of the same name, but you couldn’t tell anything is different from the way it is called:
synchronized (lockObject) {
    doStuff()
}

Cons

I covered a lot of how Kotlin is a very expressive language which has a lot of interesting tools to do away with typical Java boilerplate. So, what could go wrong? Not much but I would avoid diving straight into the deep end of the language at once. While Kotlin is nowhere near complex as Scala is, and the tools it offers are largely orthogonal to one another, it is still quite a bit to digest if one is aiming at idiomatic usage of everything. The good thing is, Kotlin and Java classes inter-operate really smoothly among themselves, so you absolutely can take those small steps and slowly convert your code base class-by-class from one language to another, and immediately see the benefits of reduced boilerplate and increased clarity.

As a Java replacement language it works very well. Although not completely perfect, it still has reduces many headaches. Any decent Java 8 developer who is curious and willing can pick up and be more productive using Kotlin in a matter of weeks.

There are some disadvantages you’ll need to keep in mind:

An app built with Kotlin will likely result in a larger file package size than one built purely in Java. That’s because The Kotlin standard library and runtime that’s added on top of Java’s standard library.

Since Kotlin is a relatively new language, the Kotlin community is still fairly small, particularly compared to the community surrounding more established languages like Java. At the time of writing, searching for Kotlin on Stack Overflow returns just over 16,000 posts tagged with Kotlin—compared to the whopping 1,300,000+ posts that contain the Java tag.

This question was referenced from Quora