I will be sharing my experience using Kotlin for an intensive, 24-hour project. I hope that this post helps to give exposure to the pragmatism and benefits of using Kotlin, a programming language developed by JetBrains.

Twenty-four hours of drinking Red-Bull and hammering code onto the computer have passed this weekend. The Opportunity Hackathon was created by PayPal and the Silicon Valley Code Camp to serve organizations that help the community. This event was an amazing chance for young developers like me to show others that even people who code for hours every day can create solutions of moral value. In addition to that, I had the wonderful opportunity use pure Kotlin for my team’s Hackathon project (for my individual contribution). It was no doubt a positive experience that I would like to share with you all. Below is the result of my Android app after the final submission:

* I seriously don’t know where that 5% Java comes from, so let’s round Kotlin up to 100% :)

Why Kotlin?

To give some background on my experience with Kotlin, I have been following Kotlin and learning the JVM language for months now. Coming from Java, it was very easy learn and fun to use, especially when it came to Android development. I have finished reading Ch. 1–9 of the official “Kotlin in Action” book through the early access program, completed most of the Kotlin Koans exercises, and converted all of the Java code in one of my projects to Kotlin. So while I am no expert in Kotlin, I have had enough exposure to it where I was confident enough to use Kotlin for a 24-hour coding marathon.

Kotlin meets Android.

Due to my skill set, I was responsible for creating the designs and beautiful animations for the Android app while the rest of the team were busy working on the backend. All team members were very supportive in my decision to use Kotlin so it was a chance for me to see how productive and beneficial Kotlin can be in a collaborative project. Given that I had one day to maximize Kotlin’s use to make a great product, I got started right away.

I had no Null Pointer Exceptions…

until I was about eight hours into the Hackathon (at runtime, that is). Keep in mind that this was 24-hours of fast-paced, intense and messy coding. One reason for the lack of NPEs could have been from the careful project planning and requirements specifications that my team went into prior to the Hackathon. Or maybe it was due to our target customers helping define our requirements early, allowing us to work on components of the project knowing it will not need major reworks. One thing was for sure, Kotlin’s null-safety was definitely the one of the major ballplayers in dodging NPE’s halfway through the project. Things were going so well in those first eight hours that I was completely blind to how productive I was. I just kept working and enjoying the smooth ride of productivity (until the lack of sleep kicked in). Even when I did start running into NPEs, Kotlin’s type-system and compiler made it easy to quickly pinpoint the cause of them. This allowed me to spend most of my time actually building key features of the app.

Kotlin.numLines < Java.getNumLines()

“If I had used Java, it would have been a thousand lines of code instead of a few hundred.”

When I converted one of my Android project’s code from Java to Kotlin, I saw anywhere from 20% to 40% reduction in lines of code. This is not an accurate figure for all projects, but this is what I observed when I did this for a project with over 15 different files containing hundreds of lines of code. When I first reached 600 lines of code at the Hackathon, all I could think of was: “If I had used Java, it would have been a thousand lines of code instead of a few hundred.” This may be an overstatement, but it does not take away the fact that Kotlin code is cleaner, more readable, and easier to maintain than its Java counterpart. All developers spend a huge chunk of their time reading code, so less code and more readability is always a plus.

Extra Goodies From Using Kotlin

It’s important to mention that without Kotlin, I would not have been able to use the Anko libraries to boost my productivity even further in the Android project for my Hackathon.

With Anko, you can do this to implement listeners:

button.onClick { /* Implement me */ }

or you can do this to easily use the internal SQLite Database:

Context.database.use { /* SQLite instance */ }

Go ahead and search up the Java way on how to set listeners and or use open an SQLite database. Be warned though, it’s ugly.

It may sound as if I hate Java, but I am just expressing the idea that you should use what works better for you. I still think it’s important to understand your Java concepts and how useful methods like Context.database.use { } work behind the scenes when it is converted to Java. I love coding on Android and using whatever tools are available to get things done quickly and effectively. And Kotlin does just that.

People Were Interested

Many people were very interested to see that I was building a complete Android app in nothing but Kotlin.

Hackathon guy: “You programmed in what!?” Me: “Kotlin. Just plain Kotlin.”

I had to answer this question so many times throughout the Hacakthon. Nevertheless, it felt great to give Kotlin some publicity. Not one person knew about Kotlin so I couldn’t help but feel a little special being the only person there who was crazy enough use Kotlin.

Before I conclude:

Things I wished could have happened at the Hackathon:

Work in Kotlin collaboratively. And by this I mean reading Kotlin code written by other people, criticizing it and have the exact same thing done to me. Working with fellow Kotlin enthusiasts is one of the things that I (hopefully) look forward to doing when I graduate this upcoming Spring. Find someone else who knows Kotlin. I know the language is still being adopted and discovered at the time of this writing but it would have been nice to have an in-person chat with someone who shares my interest in Kotlin.

Conclusion

I completed the submission for the app of my team’s Hackathon project with under 30 minutes left on the clock. This was a complete app that was ready to be used by a non-profit organization. No shortcuts, no bullshit. Had I used Java, I would NOT have been able to finish a complete project of that extent unless I took away key features of the app. There are lots of things to consider when deciding on using Kotlin for a project such as method count and apk size. It’s all about making the right choice for the right situation. Furthermore, I’m not happy with all of the Kotlin code I wrote at this Hackathon. If this wasn’t a 24-hour event and I had the chance to go back to change some code, I definitely would. For me, I’ll continue to learn Kotlin and use it for future projects. I am very proud and satisfied to have chosen a language which allowed me to complete a full project within 24-hour. There is much more to Kotlin and the benefits that it brings to the table than what I described in this post. I see a promising future for Kotlin and hope to use it professionally in the near future.