Just 6 months ago, JetBrains Kotlin language hit 1.0 release and became the newest contender in the arena of JVM languages. Kotlin is interesting because it was released out of need for JetBrains, who was seeking a language to cut down on the size of their codebase in their products. This means that it’s here to stick around for a while, and tooling support is going to be first class coming from JetBrains.
Why did I use Kotlin?
I’ve never particularly enjoyed working with Java. Coming from a C# world, it’s easy to find features in C# that Java is missing or has an implementation that isn’t as well polished.
Extension Methods
I always seem to find myself missing the ability to write extension methods. While they’re only syntactic sugar at the end of the day, extension methods are really great for readability.
For example, I find it much easier to read and understand:
listOfObjects.processData(param1, param2);
vs
ProcessData(listOfObjects, param1, param2);
No Class Requirements
It’s not to say that I have anything against classes, but it’s nice to be able to write some free-standing code without the overhead of writing and calling a class. Free-standing code is great for writing some quick one-off script to test an idea or to build out some code that doesn’t particularly belong in a class.
Toolchain Support
I’ve already mentioned in above, but getting to work with a brand new language in a very mature tool ecosystem is rare these days. IntelliJ supports Kotlin just as well as Java, and Kotlin has interoperability with other Java tools like Maven and Gradle. On top of that, Kotlin is open source
Swift came out with decent support in XCode, but anyone who worked with it early on will remember SourceKit crashes among other problems that plagued Swift development. Since it was developed in secret (though now open source), it took a while for popular third-party Objective-C tools to support Swift, and in all it was hard to be on the ground floor of Swift development.
Collections
Java has lots of collections in the standard library, but they aren’t particularly intuitive for someone coming from most other languages. It’s not clear to someone reading Java code that a List<> is an interface and ArrayList<> represents the mutable implementation of that interface. Or that a HashMap<> is the mutable implementation of the Map<> interface.
Kotlin isn’t perfect in this sense, but naming is slightly more clear: MutableList<> and MutableMap<>. Beyond that, Kotlin makes it easy to initalize these collections with data through methods like mutableListOf(), which generally requires bringing in an external library such as Google’s Guava in standard Java.
Less Verbose
This is easily one of my biggest gripes with Java. Making every class use getters and setters is annoying to manage and feels counterintuitive. C#’s properties are a great example of a system done right, and Kotlin takes it a step further and allows what are called “data classes”.
Data classes get rid of almost all of the boiler plate code that comes from writing POJOs. Data classes can be as simple as one line:
data class Person(val name: String, val homeTown: String)
Without a single getter or setter, properties can be accessed as expected: person.name. Kotlin will even abstract away getters and setters from Java classes when writing mixed-language applications, and let you use the cleaner syntax.
These are just a handful of features among a huge list of reasons that Kotlin should be the newest tool in your kit. Many aspects of Java have been improved upon such as fixing the == operator, cleaner lambdas, inferred types, and so many more things. Since it works perfectly in Java projects, it’s easy to try it out on a small portion of an existing application where the stakes are low, and the potential for productivity gains can be very high.
comments powered by Disqus