<https://zsmb.co/on-from-java-to-kotlin-and-back-a...

# feed

[nfrankel]

https://zsmb.co/on-from-java-to-kotlin-and-back-again/

[janvladimirmostert]

I see the author back-pedalled after lots of comments on the original article. It seems they didn't spend 6 months with Kotlin as claimed in the original article, more like a day or two considering how many other things they were working on.

Great thanks Dan Simpson!
I'm also shocked. Some people are so touchy about the programming languages they use, that become aggressive after hearing something inconvenient.

I'm not criticising Kotlin per se. It's a good language. Even in this text, I mentioned a lot of pros of Kotlin: objects (singletons), null-safe types, data classes, type inference. There are more: type aliases, pure functional types, encouraged immutability.

This text is just a story - "I tried Kotlin, and I didn't like it". It didn't fit in the context of our team and our project.

More about the context.

The team
The team was built from 4 guys. Two guys with serious Java experience, and two guys with small to no experience with JVM.
And when you are not up-to-date with Java and when you don't know the history of Java (for example if you are a Python developer), the differences between Java and Kotlin might be blurred. If you don't know why NPE is such an annoying problem in Java, you don't see the reason to use null-safe types. Data classes are nice, but you also heard about Lombok. Lambdas are in both languages. Since Java 10, also both languages have type inference. So what's the big deal? Think about this different point of view.

The project
It's a system for managing A/B testing (experiments) in Allegro. We named it χ. Quite challenging job, because it goes through the whole technological stack of our platform. Frontend, backend, and big data. It's divided into the four subsystems:

1. χ core - rather small microservice with the domain model, database access, and REST interfaces. That is the place where we tried Kotlin.
2. χ client - a small Java library that is used by applications to integrate with χ system. General purpose libraries for JVM are written in Java to minimize dependencies.
3. χ admin - GUI app for managing experiments. Written in JS and Vue.js
4. χ analytics - big data module with PySpark scripts and Airflow scheduler. We calculate statistical results of experiments here.

Why didn't Kotlin fit in χ core?
1. As you can see, it's mixed architecture. There are three must-have languages: JS, Java, and Python. Kotlin was fourth and kind of optional. We were working hard to learn and develop in PySpark and Vue, as it was critical to our project. So we didn't have plenty of time to play with Kotlin and lo learn all the idioms.
2. χ client and χ core are closely related. There were a lot of tasks requiring changes in both modules. And for me, switching between Java and Kotlin few times a day was inconvenient. The syntax is very different. It makes context switching harder.
3. There is not much domain logic in χ core, so we didn't leverage the full potential of Kotlin's as a good language for domain modeling (data classes, type aliases, objects, and so on). In the same time, we had to fight with some interoperability issues between Kotlin and Spring, Kotlin and Java, Kotlin and Spock. These issues are not so hard to overcome, and probably they don't matter when you build a huge system in Kotlin. But in our case, these issues weighted. We were focused on creating PySpark jobs and a nice GUI and had some troubles with it. We didn't want more troubles in the most trivial part of the system - χ core.