Kotlin vs Java: 10 Years In
Then there is Kotlin --- released 10 years ago when Java became too much of an overall headache with its NullPointerException and security vulnerabilities. Kotlin learned from the mistakes of Java and came out from JetBrains as the better alternative statically typed, general-purpose programming language with a type interface.
But how good is Kotlin really? And how do the two programming languages compare? This is where we find out.
Java is a multi-paradigm, class-based object-oriented, imperative-style programming language that first appeared in 1995. Java's syntax is influenced by C++ and C, which means that developers can easily jump between languages without much friction, leading to a lower barrier to entry.
The idea behind Java was both ambitious and simple --- to be able to write the code once and run it anywhere. This makes Java a cross-platform language and instances of implementation can be seen in spaces that range from native desktop applications to mobile phone games. Java is often paired with other frameworks such as Spring, Hibernate, Struts, and Grails to give it structure and increase development speed.
Beyond mainstream consumer-based apps? Java can also be seen in spaces like big data through the Hadoop MapReduce framework. According to GitHub's Octoverse 2020 report, Java is ranked 3rd in the 'Top languages over the years' category.
Kotlin came into the world in 2011 and got its first stable release in 2016. Kotlin is a cross-platform, statically typed, and general-purpose programming language with type inference.
In 2017, Android Studio 3.0 incorporated Kotlin support as the alternative to Java. In 2019, Kotlin became the preferred language for Android application development. The push by Google is helping propel Kotlin's usage and is ranked 4th according to Stackoverflow 2020 Developer Survey.
With Android shifting its gears over from Java to Kotlin, it leads us to question why? Here is a comprehensive list and how it impacts the software development process.
When we dig into the language differences, a major standout is that* Kotlin allows for both object-oriented and functional programming paradigms*. In contrast, Java is limited to class-based object-oriented only. The major perk of being multi-paradigm is that it allows for greater flexibility in how code is structured. This equips a developer with a better ability to apply practicality over purity during the software development process.
While the idea of object-oriented is a solid one, it does not solve every business logic required in the most efficient way. The ability to incorporate functional programming flows into your code's architecture allows for the structuring and demarcation of domains based on context. While it is not impossible to do in a purely object-oriented and class-based system, the solution produced is not always the most elegant.
If you're coming in from a Java perspective, Kotlin's lack of static member support may feel strange. The purpose of static members is that they act as a global and shared variable within the scope of its creation such as the method of a given class. They are mutable and stored only in one place.
In contrast, Kotlin replaces this complete with companion objects, top-level functions, and extension functions. Rather than having to declare static everywhere followed by the method, Kotlin changes the format of the code's flow by creating definitions based on the intention of the code. This allows the developer to write declarations outside of the class-based system.
Semicolons can be seen as code syntax grammar in many programming languages. It marks the end of a line and physically separates one declaration block from another.
Java requires semicolons while Kotlin does not.
Why? Kotlin views semicolons as syntax sugar --- something which ultimately does not add to the logical structuring of the code but merely exists to help with readability. In Kotlin, semicolons are optional. Kotlin uses a system of semicolon inference, where if a semi-colon is not present, it is still possible to terminate a declaration. The general lack of semi-colons makes it lighter to code and line breaks are significant.
Kotlin's portability factor is increased by its scripting capabilities. This means that you can use Kotlin directly in your Gradle build scripts, allowing developers to create smaller programs on the fly without the need for compiling. In contrast, Java does not allow this as it needs to be compiled.
However, it is not exactly impossible for Java scripting. For Java 9 or later, you can do this via jshell from the command line, but this does not come with a built-in grepping and file system. The purpose of scripting is to create short snippets of code that can be run quickly. In Java, if you want to do some scripting, the JVM startup time will most likely outweigh the benefits of the scripting you want to execute.
Kotlin's in-built scripting abilities make it much more efficient and lightweight than Java's forced scripting processes.
NullPointerException errors are the cause of many security vulnerabilities, stuck and crashed applications in Java. It occurs when null is assigned to an object reference, and then it is later used in the application.
Kotlin cuts out the issue by implementing null safety --- that is, null itself still exists but it cannot be set against non-null types. Unlike Java, where there is no separation between those that can hold null and those that shouldn't, Kotlin sets up clear categories for nullable and non-nullable types.
Top-level variables such as a String is a non-nullable type. The only way around it is to explicitly set them with a ? behind the declared type, such as String?. This forced explicitness means that the developer is expecting to deal with null at some point in the program and has made provisions for it. In Java, this option is not available, which can lead to unexpected results in the event a null is set and the program needs a non-null value.
Kotlin's growing popularity is mostly due to it being familiar in syntax and style to Java, but without the same common issues and errors that its predecessors face. There is less learning overhead required when it comes to learning Kotlin, especially if you're already a Java developer. It is more lightweight to code and requires less setup to get a program up and running.
Being multi-paradigm allows Kotlin to be much more flexible than Java when it comes to architecture and code composition, in addition to the ability to create primary constructors, first-class delegation, singletons, range expressions, and create separate interfaces for read-only and mutable collections.
Java, on the other side of the ring, has had ample time to address the issues that these features address --- but have decided not to. Despite this, Java still remains the predominant programming language over Kotlin due to its legacies and established applications. Kotlin's support has only exploded recently, but there are still plenty of Java-based applications around.
It is good to note that Kotlin was created to work with Java, which means that there is still a transitional period before Kotlin becomes the predominant programming language over Java. Google's support of Kotlin in Android development is contributing to its steady rise in uptake.
Overall, Kotlin is a programming language that can be seen as taking the best bits and fixing up the bad bits of Java. It has learned from its predecessor, borrowed ideas from other programming languages, and created its own unique way of translating business ideas into functioning and efficient software.
Originally posted on Lightrun