Kotlin, a beautiful back-end mess

Kotlin gained popularity in the last few years, thanks to its refreshing syntax and strong Android support. Java, after all, has never been a good looking yet concise language.

Some companies are adopting Kotlin over Java also for back-end development to improve productivity and readability.

In my experience, however, this less likely to happen, and the reason is a few misconceptions about enterprise software development:

That productivity is about delivering fast, rather than making the code maintainable.

That readability is about writing less, rather than making the code self-explanatory.

Productivity

As I wrote in a previous article, about 2/3 of development in long term projects is spent on maintenance, and the initial implementation is just about 1/3.

Some languages (e.g. JavaScript, Python) excels at rapid initial development, while other languages (e.g. Java, Go, .Net) excels at long term maintainability.

If a language is well known to empower some of the most complex and maintainable back-ends, there are reasons, and breaking the underlying (Java) mechanics does not guarantee the same benefits.

The biggest problem I have noticed with Kotlin for the back-end is consistency. Also, some constructs can impact readability and safety, two things that Kotlin paradoxically attempts to improve.

Example by coding

This Java line would probably make many developers wonder, “why do I need to write so much just to get a logger?”

In Kotlin apparently, we could just write this, more concise and readable.

But this is not the same thing. We have a couple of options, one more natural to Kotlin and another more Javish:

The point here is:

A language which attempts to create something new on top of another language and yet needs to be seamlessly compatible, will eventually require patches and workarounds.

Readability

The general feeling I have with Kotlin is “the faster I write, the better”. A lot of Kotlin features, after all, are meant to write code faster. We also have a multitude of operators in order to save a few lines of code, e.g. also, apply, let, run, with.

Even if a developer can write good or bad code with any language, I found more often cryptic one-liners abusing operators in Kotlin than languages like Python, Java, Go or Dart.

This real world code will hopefully get the idea:

Maintainability

Often non-back-end or inexperienced developers join the team because interested in learning Kotlin.

Reusing development resources can be helpful, but it is sometimes counter-productive when we want to follow the best programming practices. This is especially relevant to Kotlin, because:

A permissive language, that does not enforce specific coding practices and offers potentially double edge operators, can be more challenging to be used with discipline.

Important principles like decoupling, consistency and reuse of the code can quickly fade away, like in this real-world example:

Conclusion

Is Kotlin a bad option? Absolutely no! It is a more full-stack friendly alternative to Java, and it is quite popular in Android.

Before switching to Kotlin, however, companies need to consider that:

• A significant part of Kotlin success is thanks to Android. Google however is pushing for cross-development with Flutter and Dart, which is a really good stack. This will likely take away several Kotlin developers from the market.
• Kotlin somehow improves Scala, yet it shares its fundamental issues. It can lead to excessive minimalism, abuse of magic and pollution of operators. Not that Java is hassle-free, but Kotlin sometimes takes things to the opposite extreme.