Recently, a blog post entitled “The Case Against Kotlin” was published on Medium. The title could have been more descriptive, and I appreciate that it doesn’t tout Kotlin as rainbows and unicorns, but it did bring up a few points that I’d like to address.
The Learning Curve
Whenever I hear about learning curve as a consideration for using new technologies, I approach the argument with a bit of skepticism. As technologists we have to continue to learn and evolve in order to stay relevant. It’s the nature of the field, which is still innovating and changing at a rapid pace. It can, indeed, take time for teams to come up to speed on a new technology, but ultimately it’s critical for most people if they wish to have a long fulfilling tech career. Having spent some time in stodgy enterprise Java corporate environments, I recognize that the learning curve is often touted as a reason for not wanting to adopt new tools and languages.
In one egregious example I recall an enterprise architect’s recommendation for a team to use GWT instead of a more modern Javascript framework for a web project. The main reason cited was not because GWT offered better support for the product or provided a better way to implement product features; it was because they felt it was unrealistic to have the team learn a new toolset and language. This type of culture is unfortunately all too common in the enterprise Java community. The QT framework takes this even further. With QT, you can use C++ to create applications for iOS and Android, but you end up writing more lines of code. Maybe that feels safer for a C++ developer, but the reality is that most developers will need to learn a number of different programming languages throughout their career.
Even if they revert back to a language they’ve used before, it offers them new perspectives on how they write code. For example, I spent a number of years in enterprise Java before taking a detour into Ruby. When I started doing Android development, I wrote Java very differently from the way I did before I switched to Ruby. Then, once I discovered Kotlin, it was a no-brainer to change languages again, because I love Android but hate Java! Eventually, after doing some projects using Swift and Typescript, the Kotlin experience made these languages easier to learn. To be fair, if we were, in fact, talking about learning something like Haskell, the learning curve may have been much steeper, but in this instance, we’re talking about a language that was designed with Java developers in mind.
Build Time
This is a current problem with toolsets. In the short-term, you can throw hardware at the problem (if you haven’t already), but in the long-term, as Ryan stated, it will be optimized. It’s simply part of using a newer language.
Development Stability
Again, this is something that you always have issues with when using you adopt a newer tool. For that matter, from time to time, I see stability issues even with established tools. If you’re new to the language, some issues may not be readily apparent and could send you down a few rabbit holes. As more developers use the tool, more articles will be published, and tools will improve.
Static Analysis
While there is some improvement that needs to be made to this in Android Studio, it does highlight a larger issue with tools, and Java, in general. After I had spent a number of years doing enterprise Java development, I found myself getting very dependent on development tools. Many of my co-workers felt the same way. While the tools are great, I’ve seen them make mistakes, even with Java. When I switched to doing development in a dynamic language, I was forced to break away from that dependency, because some static analysis that is possible in languages like Java are just not possible in Ruby and Javascript. I’ve also seen Android Studio do some strange things when it automatically makes changes based on static analysis of Java code.
Better analysis is definitely possible in Kotlin, but even without that, you end up writing less lines of code. Less lines of code means less lines of code to review. Do automated tools make things easier on a big team? Absolutely! But, if humans have less code to parse, it’s probably not making an enormous difference.
Reversibility
Kotlin is one of the few languages I’ve seen with IDE integration which will automatically convert another language to it in a fairly seamless manner. If you’ve ever done any iOS development, you’ll know that there is no automatic code converter built into Xcode that will convert your Objective-C code to Swift. If you convert some code and don’t modify it, you can always use source control to get the original version back. That said, it’s best to understand the limitation and what you’re getting into.
Caveat Emptor
Why are you using the tool?
I could spend some time advocating for using newer tools, but you first need to understand why you are using them! I’ve seen teams cargo cult new tools and technologies without understanding why they are using them. Enterprise Java earned this reputation which is how FizzBuzzEnterpriseEdition was created. Though this project is, of course, a joke, anybody who’s worked on enterprise software has seen this. Some parts of Android were arguably influenced by the enterprise mindset. The long-time Google-recommended practice of using content providers for local database storage is one of those concepts that they are now moving away from.
Kotlin is going to be with us for a while
Although Kotlin doesn’t have as much traction as some other languages, the signs all point to it gaining popularity in the mobile space. Whether it gains popularity on the server side or in other domains is an open question, but Android development is driving its adoption. Why? First, it has first class support in Android Studio, thanks to JetBrains. Second, with its new features and the reduced code footprint, it does give you long-term productivity gains (each line of code is a liability to a project.) Third, even before it was officially endorsed by Google, it was really the only reliable alternative to Java for native development. Finally, it is officially supported by Google.
Having done native iOS development in Swift as well, my biggest complaint about Kotlin is that my Android programs are still larger than their iOS Swift counterparts. Some of that is due to the design of the Android framework, but it’s also because the language is not as big of a step forward as Swift was from Objective-C.
Conservative development is detrimental in native development
Are there times when it makes sense to be conservative with your platform? Absolutely! But, mobile is changing rapidly. Each year, a new version of Android is released. If your apps are being run by consumers, that means that each year more users will be upgrading to new versions of the OS, with new features that need to be implemented. Tools are coming out that make use more productive and we are refining how we organize our applications.
Blaze the trail, but be ready for a few bumps
Before you use any new tool, understand why you are using it. For most new applications, I tend to use a MVVM architecture with data binding, Java RX etc. While there might be a good reason to go with MVP, most projects that start this way today have more to do with developers not wanting to learn the tools around MVVM than with MVP actually being a better choice.
Sometimes there are instances where an older architecture/technology/tool/language might be more appropriate for technical reasons. For example, when people need to develop native platform code that is optimized on Android, they use C++, which makes sense. But most applications don’t need this kind of optimization in the same way that most Android applications really don’t need extra Java-based optimizations. Things will certainly be a bit rougher around the edges with a newer technology. At times it might even be a bit of a white knuckle experience!
As soon as you write a line of code, it becomes legacy code. The older the tools you use to create your code today, the older the code will look when someone has to maintain it in six months. If it’s majorly unstable, or there is some edge case that the technology is not covering today that is critical to your applications, then wait. But, if there are a workarounds, these growing pains are investments in the future. When Swift first came out, a lot of Objective-C developers scoffed their noses at the new language. Now Swift is far more popular than Objective-C. The same thing was true with Java and C++.
In conclusion: Are there some few risks associated with blazing a trail with Kotlin? Of course! But what happens if you decide to arrive later to the party? As an organization, it means that you’ll be playing catch-up with your team, and an individual developer, it also means that you’ll be playing catch-up with your skillset. Legacy technology can be just as much of a liability, and Kotlin, compared to other technology changes I have seen, is a pretty safe bet and has a much lower barrier to entry.
