Originally published on Hackernoon.
I hear what you are saying. There is that buzz around Android actively adopting Kotlin as a primary programming language. And trends don’t look good either.
Things on a web-development front are not by a bit better. Most popular web-framework in Java supports more and more idiomatic Kotlin as we speak by providing suitable APIs.
You can feel they are making their bet for the future.
And it seems that this future is closer than you think.
Now you are thinking. Should I make that bet, as well? Or is it just some hype that will die out in a year?
That little mixed controversial sensation in your heart. It just keeps worrying you.
You are unsure and afraid that if you don’t do something, then that new hire who is excited about Kotlin will convert your code base to Kotlin, and you’ll lose your productivity as a result.
That makes you worry about your job position.
On the contrary, you felt disappointed in previous programming language attempts to replace Java. You feel discouraged to trust new such attempt. There is no chance a new language can make its way to most of the legacy code bases or is there?
Perhaps, you feel curious about why tech giants (such as Google and Spring Team) place their bet on Kotlin.
Could it be that you are new to the code base, and still learning some new technologies you haven’t used before? And there are few Kotlin enthusiasts on your team, who have already started converting Java code to Kotlin code?
And the rate of said conversion is alarming?
That makes you feel confused and angry. You already have a lot of moving parts that you have to learn on your plate. That just adds more.
If you don’t spend time learning Kotlin, you are afraid that you’ll have to transfer to a different project, which still uses Java. For now.
If you do learn Kotlin, you are terrified it will be time wasted, as it will not take off as everyone promises.
I know, right?
How Can That New Team Member Convert The Whole Code Base to Kotlin in a Few Months?
So can one team member make such a drastic change to your legacy code base?
I mean, it is huge! There is no way a person can convert it all in the new language. So I can always stay mostly productive because the majority of the code will be in Java, right?
Wrong!
For you to understand how quickly Kotlin can consume your legacy Java application, I’m going to attach this image. It describes perfectly what I’ve seen so far:
“How quickly Kotlin consumes Java applications.” (source: https://www.pexels.com/photo/blue-clouds-color-danger-268774/)
Kotlin is the programming language built by JetBrains. They have quite a vast Java code base, as well. They made it their mission to create a language that they can use today in their code base. Not just for the new features.
How do you convert a Java file to Kotlin then?
Probably, you write the same thing again in the new language. Then make all tests pass. That is pretty time-consuming. No way your project manager will allow such effort without a strong reason. Right?
Nope.
One hotkey.
You’ve heard me right. It takes one keypress in IntelliJ to convert the Java file to Kotlin file. And in 99% of the cases, all the tests will still pass.
You know what’s scarier?
That works for the whole package, as well…
Let me tell you a story.
I have joined the project that had such a Kotlin enthusiast. They have convinced other team members to “try out” Kotlin for a single feature.
The project was two and half years old. The size of a project was big enough to have multiple Gradle modules, and start extraction of some independent services.
In two months nobody on the team was writing any Java anymore. Any Java file that needed to be changed to implement a user story was converted to Kotlin on sight.
It is important to say that team’s velocity didn’t drop during these two months, as it didn’t take much time and effort to do the conversion. Especially, for Kotlin enthusiasts. They do such conversions all the time.
Let me tell you another story.
This time it was a non-successful conversion to Kotlin, for a change. But there is a catch, though.
A few Kotlin enthusiasts joined the team at the same time. As they were already pretty experienced in converting Java to Kotlin, they just started doing it.
The other half of team members were still learning the tech stack, as they were quite new on that code base. Kotlin was just adding other moving parts.
They have resisted the change to Kotlin. The team agreed not to continue the conversion, as it will slow down getting these team members up to speed with already existing technology.
But here is the catch.
Upon one-on-one conversation, these team members liked Kotlin. And they were open to continuing the conversion once they feel more comfortable with the tech stack.
I’m pretty confident in about half a year they will stop writing any Java, as well.
Let me tell you the last story for today.
It was a long-running project. Quite big and complex. I would consider it a legacy Java code base with more than ten macro-services (notice “macro” — not “micro”).
One day, two team members asked a Kotlin enthusiast to help them try out Kotlin. They were curious because of all the buzz on the internet. And because that Kotlin enthusiast radiated passion about Kotlin.
You can guess what has happened.
In five months, nobody was writing Java code anymore on that team. Same story.
And you know what is even more terrifying about that conversion? Once you’ve converted to Kotlin and started using Kotlin-exclusive features, it becomes hard to convert that code back to Java.
There were enough of these would-be Java replacements in the past. And they’ve all failed to deliver on that promise.
So what so different about Kotlin?
How is This Java Replacement Attempt Different From Previous?
A few words.
100% Java interoperability.
You can easily have a mix of Kotlin and Java files in the same directory.
Java can import Kotlin classes and use them as if they were Java classes without any weird syntax or tricks. The same goes for Kotlin. Kotlin code can import any of your Java classes and use them regularly as if they were Kotlin classes.
There are no weird things like object.field_$eq(value) to set a value.
To invoke a Java setter from Kotlin, you will use Kotlin syntax: object.field = value. And to invoke a Kotlin setter from Java, you will just use normal setter method: object.setField(value).
Kotlin code can implement Java interfaces and Java code can implement Kotlin interfaces.
Kotlin has that interoperability as a top-priority feature of the language. That is because JetBrains team wanted to use Kotlin on their vast Java codebase right away. And without any pain.
That enables you to convert only a single class from Java to Kotlin and not trigger humongous cascading changes. Sometimes you would still want to convert a few related files, but you don’t have to.
Another reason why Kotlin is more likely to deliver on the promise of replacing Java is build tooling.
Kotlin doesn’t need any unique build tooling. A Maven or Gradle plugin is sufficient.
Moreover, Kotlin’s build times are extremely fast. It can be even faster than Java if you have incremental compilation enabled!
Alright. As you can see, there are not so much of negative points on the scale of the trade-off with Kotlin.
So what is on the positive side of the scale? What do you get when you stop writing Java and start writing Kotlin?
So why tech giants like Android and Spring are placing their bet on Kotlin?
So Why Tech Giants Are Placing Their Bet on Kotlin?
Kotlin language is concise. It is concise without losing the readability of Java. Kotlin removes all the boilerplate that you see in a regular Java or Android application.
Ever wanted stream API to be available directly on collection objects? Kotlin has that. Its standard library extends quite a few standard Java classes with additional functionality.
That reduces boilerplate by a lot. Where you had to create five different classes to read a stream, Kotlin allows you just to do what you expect. To read that stream.
Kotlin is safer than Java. It promotes nullability to the type system. That means that compiler can statically analyze your code and if you have a chance of a null-pointer exception somewhere — Kotlin code won’t compile.
And these nullability checks are not even annoying like they are in other languages.
That is thanks to smart casts. Let me show you an example:
Compile error because quiz variable can be null
Because quizStorage.load(quizId) returns Quiz? (a nullable Quiz) the compiler complains that you can’t directly call methods on quiz variable because it can be null.
So to make the compiler happy you will need to add a null check:
By adding null-check we are fixing the compile error and making quiz “smart-casted” to non-nullable
As you can see, quiz.moveToNextQuestion() is highlighted in a “special” way. If you hover over that variable, it will tell you that it has been smart-casted to Quiz type.
Because compiler knows now, that quiz variable cannot be null at this point.
In different languages with nullable types, you typically need to unwrap the nullable value to non-nullable. Even after you made a null-check!
Such unwrap operation is unsafe. And therefore, another programmer (including your future self) won’t be warned if they remove your null-check.
Smart casts are cool with that. As soon as someone removes the null-check — there will be a compile error.
And there is a much more concise way to write the same thing — elvis operator ?::
Most null-checks can be eliminated using elvis operator to further simplify the code
By the way, these examples are from my Ultimate Tutorial: Getting Started With Kotlin. It is a three-part tutorial in the form of e-book totaling 260 (and more in the future) pages of hands-on content that you can follow along.
By this point, if you are interested in learning Kotlin, download that Ultimate Kotlin Tutorial as a PDF here.
Not only you are going to get hands-on content from which you will learn to program in Kotlin. You will be able to ask me any question when you are stuck, and I will help you.
Anyways. What is there more to Kotlin benefits?
Apparently, if you spend enough time writing Kotlin, you will start writing more readable and robust Java code, as well.
That is an interesting side-effect, isn’t it?
A few friends of mine, even told me, that they would prefer to hire Kotlin developer over Java developer for the project that is all Java and doesn’t have Kotlin at all.
Moreover, Kotlin took a lot of principles from “Effective Java” book and converted them to basic language concepts. So by just writing Kotlin for some time, you are going to learn how to write a better Java code. Not so bad, right?
So what about the tooling? Is it easy to use Kotlin? Or will I have to give up my refactoring and Intelligent powers of my IDE to code in Kotlin?
Am I going to have to write it like in a text editor again?
No.
Kotlin is made by JetBrains. It is the same company that made IntelliJ IDEA. They did their hardest to make sure you will feel at home when using Kotlin in IntelliJ.
Current support is humongous. All the essential refactorings are already in place.
And, as we speak, they add more and more.
So is it a good time to learn some Kotlin now?
Is it a Good Idea For You to Learn Kotlin Right Now?
Of course, you will need to decide.
If you were to ask me… In your shoes, I would go for it. Here is why.
Even if Kotlin doesn’t deliver on the promise of replacing Java in most of the legacy code bases (or even for new ones), I know I’ve become a better Java programmer.
Only that should make it worthwhile. Do you need more?
I have that for you.
For a programmer it is always worthwhile to be learning another language at any point in time. The only exception is if you are only just starting out.
So if you are comfortable with your language, tech stack, and everything, and you are not learning any other programming language at the moment, it is a great idea to get your hands dirty with Kotlin.
It is going to put things into perspective and take you out of your current bubble. It is always good.
Learning is a skill. So the more you learn, the better and more efficient learner you become.
Perhaps, you think you don’t have the time to learn a new skill because you have a full-time job, family, hobby, and everything else in your life?
Then you should learn how to find the time to learn a new skill when you are working full-time.
If you think you are up to the challenge of upgrading yourself from Java developer to Kotlin developer, download the Ultimate Tutorial: Getting Started With Kotlin.
I genuinely thank you for reading, and I encourage you to give Kotlin a try. You have nothing to lose, anyway. And you can only benefit from that.
If you want to make me happy, then you can share it with your friends, on social networks, hacker news, Reddit, etc.
Originally published on Hackernoon.
Top comments (3)
It really is that addictive. The more I use it the more I want to learn about it.
A fact.
One problem, though. Nobody ever answered to plain "why do we need to switch to Kotlin?" without repeating marketing stuff, from plain technical standpoint. Its features are not very convincing justification. Most of them either syntactic sugar or very convenient and easy to use ways to create a mess in project. "Null-safety" as it's implemented in Kotlin, is a fight with consequences rather than with a cause. Let's be honest: whole NPE "problem" is exaggerated and Kotlin guys are just exploiting it. Ease to write DSL results to fragile code which stops compiling if you try to reformat it. Not mentioning inconsistent syntax across code base, which makes it harder to read and maintain.
Note, that I know and use Kotlin at work every day, so it's not about fear of unknown or fear to change.