Why Kotlin: A Note From a Java Developer

This blog is about sharing my experience and what I love about Kotlin. I worked with two applications that are entirely written in Kotlin in a year. I had exposure to two ways of using Kotlin in our applications: Writing a new application from scratch and migrating the existing legacy Java app to Kotlin.

Let's start with what we love about Kotlin.

Why Kotlin (and why do we use it)?

One of the tangible and essential things is that Kotlin language came from the industry, not academia – It was developed "to solve programmers' difficulties" and operational challenges. We wanted to pay special attention to Kotlin features that Java does not have (at the time of this exercise) to evaluate if it will help the projects. The result is, we could fill an entire book about the things we like about Kotlin. Here is a run-down of highlights.

How does It Change the Way We Code (compare to Java)?

Kotlin is really "Java's best practices" put into a language. It solves problems faced by working programmers today.

• Kotlin costs nothing to adopt in two aspects!
  • It's Open-Source.
  • One-click Java to Kotlin converter tool, and a strong focus on Java binary compatibility.
• Lean Syntax: Kotlin focuses on readable, at the same time, concise syntax, which makes code-reviews/understanding-the-code painless.
• Complete Interoperability with Java: Kotlin is 100% interoperable with Java, having many similarities in the structuring and functionalities.
• Ease of interchangeability: The shift from Java to Kotlin is smooth and swift. One can have Kotlin and Java both alongside each other in the same project.
• Improved Code Maintainability: Being a concise language, Kotlin drastically reduces the boilerplate code required, enhancing productivity and reducing error. Less code makes easy learning.
• Lower Instances of Application Crashes: Kotlin is designed on the concept of fail-fast.

Kotlin brings a myriad of language features. It is worth noting that most of the features are meant to bring best practice to the coding (comparable to how frameworks guide developers in the right direction)—listing down the top the fifteen features, which will make a huge difference compared to how we code in Java.

1. Null Safety: Kotlin as a whole has a much bigger emphasis on overall null safety.
2. Arrays in Kotlin are invariant: Arrays in Kotlin are not built on native types but are instead based on a Java array, which means that an array of a specific type cannot be assigned to an array of its parent type. It is not possible to set Array<Integer> to Array<Any>. 
3. Extension Functions: Ability to extend a class with new functionalities without modifying it
4. No checked exceptions: In Java, exception handling is tedious and controlled by strict rules. Whenever we are dealing with checked exceptions, we can either handle exceptions in try…catch blocks or be declared to be thrown. In this case, the code is repeated. 
5. Data Class: Unlike in Java, where, when creating classes only meant to hold data (models or POJOs to be specific), we are required to write all of the fields, setters, getters as well as a constructor; In Kotlin, we can define all of these things on a single line.
6. Default Arguments: Removes a lot of the need for overloaded methods with the introduction of default arguments
7. Named Arguments: Avoids Client confusion in passing Parameters to Method or Constructor calls. It improves the readability of the code.
8. Delegation: Provides native support for the delegation pattern
9. When Expression: Provides the better version of Switch Statement 
10. Function Literals: Provides the concise version of Function Interfaces
11. Operator Overloading: This allows you to simulate a DSL
12. Immutability: Native support for making things immutable
13. Type Aliases: Improves readability and makes code succinct
14. String Interpolation: Easier way to concatenate a string together without excessive syntax
15. Better Generics & Coroutines

I know what you're thinking at this moment; "Wait! this is just a bunch of key distinctive features, and anything new gives something like that. Still, why Kotlin? You can't just sell it by showing a fancy list of features ".

I will tell you this, "There is a way to look beyond just features."

Let's change the scenery now and go to defensive programming valley, then it will be evident 'Why Kotlin'.

Defensive Programming

Think of defensive programming as analogous to "defensive driving", which would help if the term is not very familiar.

When you drive defensively, you assume that the other drivers are not careful. You must be cautious yourself: you must give yourself extra room on the road to make emergency manoeuvres. You assume other drivers may ignore red lights and stop signs; therefore, you look both ways and are ready to stop when you approach intersections. You anticipate problem areas up ahead – dense traffic, impaired visibility, and other potential impediments. In any case, you devote a lot of time, energy, and resources to the infrequent and unlikely event that you will encounter a dangerous situation.

"Okay, I got it". "Adding NULL checks and other checks is Defensive programming"

"No! Please stop that thought – we are not giving enough credit to the art of defensive programming if we are thinking that way".

"Okay, then, what is defensive programming?"

As I said, it is an art. what I believe to be the motto of defensive programming is:

"If you have to defend, you already had lost the battle."

For example, adding Null-Checks is Defensive-Coding; instead, coding so that you do not need to check for null is the real art. This comparison is just one example to illustrate defensive programming; there are many – we can have an exclusive blog for visiting that valley later. Let's get back to Kotlin Valley now.

When we use Kotlin, without the developer being aware, they use many defensive programming styles naturally. It is by design as a default setting; e.g. all classes are final unless stated otherwise, the default behaviour of type is non-nullable…etc…

Dev Journal

In 2018, We worked on a Greenfield project, which allowed us to take a step back to question popular thinking a few years back.

When we think of developing an application, Java is one of the top programming languages that come to mind for various reasons, including its robust and secure nature and the independence of its platform. Kotlin is designed to be interoperable with Java, meaning Kotlin can seamlessly co-exist with Java. We can add Kotlin to our existing applications, and we can use Java-based frameworks for application development. With this bi-directional use of Kotlin, we can invoke Java constructs from Kotlin or Kotlin constructs from Java.

Although Java and Kotlin are both JVM-based languages used for application development, there are several differences between them, as covered in an earlier section. Kotlin has addressed some of the limitations previously associated with Java. The more we learn about the things Kotlin support, our pressing question of why-kotlin turned into why-not-kotlin.

We had exposure to two ways of using Kotlin in our applications:

1. Moving legacy Java written project to Kotlin language
2. Project development on Kotlin from scratch While developing a new application, in general, when time-limit holds the gun to the head, we tend to copy over the setup from an existing application; sometimes, we don't realize that we are reproducing some legacy stuff along with it. For these projects, we tried not to do that.

"Is there any impact on the way we test or write the test? "

"Yes, very positive one. The two applications built in this stack have around 80+ and 90+ as unit test coverage."

"Did we notice any significant performance degrade?"

Though we have not tested the performance of the Kotlin in an experimental condition like implementing the application both in Kotlin & Java and bench-marking it, however, we did compare the performance with legacy (now dead) wherever applicable. The performance was at par, and sometimes it was even better.

"What is the learning curve (and how did we learn)?"

There are many ways you can build new tech skill; most of us followed the below.

• Step 1: 4Hrs Video Training to start the cold engine to enter into the Kotlin Valley
  There are a lot of courses available on Pluralsight & Udemy; we started with Pluralsight: kotlin-fundamentals. At that time, when we began learning Kotlin. Pluralsight course was open for Free. Lucky Us.

• Step 2: Kotlin Koans to get familiar with Kotlin by doing small exercises. Kotlin Documentation is good to look back at any time.

• Step 3 & 4: Then, Code & Write Unit Tests (have a printout of Quick Reference Card while coding)

What is the Maintainance overhead post-production ?
These two applications are running well in production over the last 3+ years without any technical or maintenance issues related to the stack being Kotlin; thus, we see high stability in these two applications.

We enjoyed learning something new (in 2018). From a Java developer perspective, the learning curve to Code in Kotlin is close to flat. Once the integration of the stack was ready to provide a skeleton for the project, we managed to gain speed in Kotlin within a week and write more idiomatic code within a couple of weeks. If you find it interesting, learn about best practices and go for it to fit your application nature.

Summing-up

Kotlin, "You Had Me at Hello" (here, the Hello means "to solve programmers' difficulties"). Overall, it was a positive experience.

P.S: This is a page from my devjournal 2018. And, I feel this is still relevant.