Why Every Java Programmer should switch to Kotlin

Few Reasons why you should switch to Kotlin today, especially, if you are stuck in an Enterprisey situation with Java 8.

1. It lets you write modern code even on Java 8. Functional programming concepts on collections alone is worth the switch
2. It’s an easy switch. You don’t need to make an all or nothing transition. You can move over one class at a time. This is possible due to Kotlin’s excellent interoperability with Java
3. Your existing build and CI/CD pipelines do not change at all. Just add Kotlin dependencies to build.gradle or pom.xml and start coding Kotlin!
4. A whole class of problems related to NullPointerExceptions simply go away! Thanks to Nullable Types (e.g. String?), you are guaranteed to not have NPEs in kotlin code written by you. NPE is still a possibility if you call Java APIs and do not pay attention to outputs.
5. Freedom from mundane Java drugery:

Map<String, String> map = new HashMap{{ 
    put(“warren”, “buffet”); 
    put(“jack”, “ma”); 
    put(“elon”,”musk”);  
}};
List fruits = new ArrayList<String>();
fruits.add("Apple");
fruits.add("Banana");
fruits.add("Grape");
Compare with: 
val map = mapOf(
    "warren" to "buffet", 
    "jack" to "ma", 
    "elon" to "musk"
)
val fruits = listOf("Apple", "Banana", "Grape")

6. Type inference. Although this ispresent in later versions of JDK, it’s not available on Java 8:

val name = "John"
val age = 20
val salary = 100.1
instead of
String name = "John";
int age = 20;
double salary = 100.1;

7. Read Only variables using ‘val’. It’s an established fact from Functional Programming that immutable variables eliminate many coding errors.

8. Expressions. if/try/when are expressions instead of statements, allowing elegance like this:

val isOk = try { 
   doSomething() 
} catch(e: Exception) { 
   doSomethingElse() 
} 
val value = when (a) {
 "one"    -> "1" 
 "two"    -> "2" 
 "three" -> "3" 
  else   -> "0" 
}
This would also force you to account for all branches in an ‘if’ or ‘when’ eliminating another class of bugs.

9. Destructuring. Pairs/Tuples and data classes can be destructured making code easy to read:

data class Person(
   val name: String,
   val age: Int,
   val salary: Double,
)
val (a, b) = Pair("hello", 30)
val person = Person(name = "john", salary = 200.0, age = 30)
val (name, age, salary) = person
println("name: $name, age: $age, salary: $salary)

10. Data classes! Create Immutable Data classes easily. No need for Lombok and other dependencies. This encourages developers to create Immutable objects as much as possible bringing all it’s associated benefits.

11. Co-Routines. Although this might take a bit of getting used to but co-routines are the way to go if you are into Reactive Programming. With focus on Cloud expenses, Developers are being asked to squeeze performance from every bit of code. Co-Routines make it quite a bit easier to do Reactive programming (compared to Project Reactor etc)

12. Multiline Strings are possible. Compare :

String longString = "this is a long " +
                    " and multiline string " +
                    " in Java. It's error prone and" +
                    " cumbersome to type";
vs
val longString = """this is a long
and multiline string
in Kotlin. It's easier to type
and understand."""

13. Kotlin REPL. The REPL is built into IntelliJ (Tools/Kotlin/Kotlin REPL). This is quite handy in evaluating code fragments. The REPL comes up with your gradle dependencies included making it even more useful. Give it a Try!