Kotlin Outside Mobile
Since its introduction in 2016, Kotlin has taken the Android world by storm. Of course, it’s no wonder! It’s an approachable, modern language that is focused on usability, pragmatism and approachability. It took lessons from Java, Scala, Python and TypeScript and combined them to make a single, coherent language made by and aimed for experienced engineers and devs. But most importantly, it gets to hold on to over 25 years of Java tooling, because Kotlin is fully interoperable with Java! Imagine if a better language just popped up with ALL the same stuff you like to use. Well, it did. That’s what happened.
I can hear what you’re thinking now “Agh, another language that wants to unseat what already works. We don’t need to migrate to another language!” Well, both I and the developers of Kotlin agree. Migrating is horrible. Adopting new technologies for the sake of being “cutting edge” is not a recipe for robustness and flexibility. So, why am I writing this article? Because! You don’t need to migrate to Kotlin. Kotlin plays so well with Java that you can simply enable it in your project and begin using it. Not only that, but Kotlin is faster to write, feels better, and is growing rapidly without sacrificing any real benefits of the JVM.
Of course, naturally, there’s some concerns with adopting new technologies in an enterprise:
- We have code bases that need expertise and no expertise in Kotlin. That’s dangerous in production.
- Java is mature. Not only does it have 25 years of tools, but it has 25 years of answered questions.
- Our applications use matured toolsets that we don’t want to destabilize
- Java has support with IDEs and comfort tools that are unparalleled.
Well, let’s talk about some of these. We’ll start with the first one
Kotlin in Production
Putting Kotlin into production definitely seems daunting. After all, who’s going to handle the weird problems that pop up? Well, first I’d like to point out again that because Kotlin is interoperable in Java, you don’t have to refactor all your existing code. It will still work. You just start adding Kotlin to it. Meaning your organizational expertise grows proportionally to the likelihood of Kotlin-induced outages. That’s pretty comforting. But, you could draw the short straw and get one early.
So, why not start with non-production code to gain skill and comfort? You can start writing tests in Kotlin. Those internal tools that customers don’t see? The comfort scripts teams make? You could start putting Kotlin there, too. The POCs that teams make. Kotlin. All of this is without risking production code while developing quite a lot of expertise in Kotlin (not to mention getting things done faster at the same time!)
More importantly, as a Java guy, I picked up the basics of Kotlin within a few days. Idiomatic Kotlin took a bit longer, but the learning curve from Java to Kotlin is much smaller than you might think. The language was written by Java devs to improve and modernize the JVM. More importantly, it wasn’t just written by Java devs, it was written by Java devs at Jetbrains, the guys who make IntelliJ the premiere IDE for Java development. Which means the tooling and integration with IntelliJ is second to none. You can literally copy-paste Java code and IntelliJ will ask if you want to convert it to Kotlin. That’s not a joke. The two are that fluid. It will convert Java to Kotlin for you. Which leads us to the second point.
Community Support
So, the Android community snatched up Kotlin like a hungry dog snaps up a dog treat. In just a few years it went from brand new language to near-ubiquity in the Android world. You have that entire world to tap into. Though, Android doesn’t always relate to enterprise server-side development directly enough. This is where Jetbrains really was smart for their focus on Java interoperability. It’s not like the 25 years of examples, tutorials, knowledge and community are useless now. Like I said earlier, you can programmatically convert Java to Kotlin. Their IDE does it. I am not suggesting you do that, but it goes to show that there’s a direct line of logic when going from Java to Kotlin. So much so that you can program it. So, while your engineers can’t just copy-paste Java from Stackoverflow all the time (but often they could, if they wanted), they can still understand what they need to do from it. Between that and the thousands and thousands of Kotlin resources, I doubt any reasonably competent engineer would struggle for any significant amount of time over what they normally would. Not to mention, the Kotlin community is growing rapidly, even outside of Android.
Toolsets
We kinda touched on IntelliJ’s Kotlin integration (which I cannot over-emphasize is sterling). That’s without me mentioning the static analysis, type inference system, and ability to code-complete even from both Java and Kotlin libraries (at the same time!).
There’s more to toolsets than IDEs and developer tools. There’s frameworks. Java has some heavy-hitters there, like Spring. You can’t just plop a framework on a new language and expect it to work properly, right? Well…
Actually you can. Spring is fully Kotlin capable. So, on top of the snazzy new Kotlin frameworks like Ktor and such that are popping up and maturing at a break-neck pace, you keep what you already have. Kotlin works so well with Spring, as a matter of fact, that the Spring docs now give Kotlin alternatives anywhere they give Java samples. Here’s a random doc page, as an example. So, not only do you get the Kotlin tools, you get Java tools, as well. When we say Kotlin is Java interoperable, we mean it. You don’t lose any significant portion of Java tooling. All of your old stuff still works. This is why you can just write new code in Kotlin without mangling what you have that works. And we won’t even get into writing React in Kotlin (I’ll just leave that sentence for you to wonder about).
So, we’ve touched on major concerns one might have with adopting it in a working organization. While it’s not zero risk, it’s much less risk than you might imagine. Probably by quite a lot, at that.
Let’s talk about some of the immediate benefits of adopting Kotlin. This gets into the weeds (or code, more aptly). Be warned!
Type Safety
Ok, this is kind of a “duh” statement. Kotlin is type safe, but so is Java. Kotlin does take it a step further by adding null safety, though. What do I mean?
As noted above, you cannot just throw null around like in Java. You have to tell Kotlin where it’s allowed to be. Does that mean the old NullPointerException is a thing of the past? Well, nearly. It’s actually pretty hard to get them. They can still happen, but they are exceedingly rare. That null operator also works as a safe-call operator:
See, that last line uses the safe-call operator (also a ?). You can think of it as a null short-circuit. If the variable you put it on is null, anything chained after will be ignored and it will simply return null. I wish I could express to you how much easier this makes life. If you’ve used TypeScript before, you already know. Null checks are enforced for you. You don’t really have to think about them anymore. It will complain if you’re not doing the right thing, now. That makes our code safer, even when we’re on the 16th hour of writing that stuff that needs to be code reviewed in the next hour.
Of course, there’s Type Inference, just like TypeScript, as well. So, you see that at work (which is why it knows when you’re assigning String vs null). These two things together makes writing Kotlin just feel good.
Condensed Syntax
Java has a lot of implicit things we do. Like adding member variables from constructor arguments. It’s become so ubiquitous that we don’t even think twice about it. So, Kotlin just streamlines it.
There’s two things to note here. First, the values for a, b and c are member variables now (as we see when I print out ref.a). The constructor and the definition of the class are now a singular syntax. We declare a class, the constructor, and its member variables in a single line. Oh, so nice.
Secondly, note that ref is declared outside of the class. It’s declared at the top level. Kotlin still has full support for encapsulated OOP. But, it doesn’t FORCE it on you. Java forces you to encapsulate, even when it doesn’t make sense. We want to leverage encapsulation, not be constrained by it. Kotlin makes that happen in a sensible, pragmatic way.
Further, I added ‘data’ as a keyword at the bottom. This is for classes that only need to hold data (which we often need!). Adding this allows us to make guarantees about the class, and so we can have equals and hashcode implemented for us automatically! That’s right, because it’s only a data class (no functionality), Kotlin will do field-wise comparison for us, and also make it hashable. Again, I say “Oh, so nice”.
Open to Extension, Closed to Modification
We’ve all heard this mantra! Kotlin still adheres to it, just like Java. It does, however, like to make full use of it with extension functions:
This is an example of an extension function. We added a function to the String class. It just wraps the repeat function that’s already there on Kotlin String, but it demonstrates that we can extend things on-the-fly. No burdensome syntax needed! There’s also a comfort syntax at the end, but some developers might find it distasteful to mix syntaxes in this way, so if you don’t like it, you’re not forced to! It’s just an option to type a few less characters.
A TON MORE…
I could go on, giving examples of Kotlin benefits. There’s a bunch of other great features like lightweight threading with coroutines (which also have a concise and simple syntax), lambdas, when statements (switch statement on steroids), infix functions, etc. But, I feel like based on what you’ve read thus far you get the idea of how much you can do with just a little bit of Kotlin. You also, hopefully, understand how much easier it is to start adopting Kotlin because of a lack of need to explicitly “migrate” or support multiple environments, because it’s all one environment and it’s interoperable. That has very wide, amazing implications. Chief among them is that you don’t need to be reckless in order to start with Kotlin in your organization!
TL;DR
Kotlin adoption is not as painful as you think, and you lose very little, if not nothing doing it, while you stand to gain a lot of very modern, very slick features that increase productivity, maintainability, robustness and just general morale! Not to mention condensing a bunch of lines of code!
