Hello Marek,
I’m the sole developer in a startup creating a web platform for music. Around two to three months ago I invited Kotlin to help write code faster, more effectively. Overall, Kotlin has been a benefit above all else. It take the verbosity of Java and minifies it, functional concepts can be expressed more easily (if you are not using Java 8 Lambdas) and many features of the language make programming a joy.
The Good
- Json Conversion: No problem because you can use a Java library. I used Jackson, but use whatever suits your fancy.
-
OOP: A breeze and joy. No longer having to write equals, hashcode, toString, etc because the data annotation does it for you automagically. Traits are BEAUTIFUL and delegates are a strong capability which I admittedly don’t use enough in my code. Solely the use of multiple inheritance is one that eludes me.
However, I find the single constructor restriction too restrictive. Be aware of that and read this StackOverflow post on how to circumvent this issue.
-
Unit Testing: Doesn’t get in your way, but doesn’t add much. Kotlin has a small unit testing library which is nice because you can write nifty code like:
failsWitch(javaClass<IOException>()) {
// Your failure code here
}
but that's about it. It doesn't have it's own mocking library, but Kotlin can very well use an existing one. I use Mockito without problems, and the code ends up nicer than in Java (except that static imports are a pain in Kotlin and something I avoid)
Large Codebase: Not sure, but positive outlook. Our project is at 10k loc and growing, but not at the scale you’re using it
The Bad
- Documentation. It's not great. Bad, in fact. For example, the only reference to the splat operator (*) is found in a very old blog post from Kotlin. You need the splat operator when you want to interface with Java vararg... functions
-
The IDE isn’t on par with Java. For example, to write an injectable constructor in Kotlin, do:
class Foo [Inject] (val toInject : Bar)
Fine enough, but if I, say, optimize imports, then IDEA actually removes the import! Not a deal breaker, but definitely a nuisance. For some reason, Kotlin also takes longer to update the code. What I mean is, when I import a class in Java, the change is reflected almost immediately, all red references going away. In Kotlin, this takes up to two seconds. This is not a negligible amount of time.
-
It doesn’t always reduce boilerplate. Instead of Foo.class, you write javaClass<Foo>(). For the most part, however, this is a non-issue. This is honestly the only place I encountered where Kotlin is more verbose than Java.
-
Barely anybody knows how to program in Kotlin. I have to tell most of my potential hires about Kotlin. I usually present them with the choice of continuing to write Java-code since this project is about 50/50 Java and Kotlin. This will change in favor of Kotlin over time, but I’d assume you have to expect some resistance here.
-
Immature plugins. I’ve had more trouble with the maven-kotlin compiler plugin than I’d like to admit. It wasn’t possible for me to use an external jar and Kotlin at the same time. The solution was to cherry-pick the relevant files and discard the .jar afterwards. If you only use maven and no other .jars, great. Otherwise, meh.
-
Sometimes wonky syntax. For example, when I wish to restrict access to a certain method:
public Response getAudioFile(@RestrictedTo({ Authority.Artist, Authority.Approved }) Account account)
in Kotlin:
(default public) fun getAudioFile(RestrictedTo(Authority.Artist, Authority.Approved) account : Account)
or when a Set is necessary
fun getAudioFile(RestrictedTo(setOf(Authority.Artist, Authority.Approved)) account : Account)
Maybe it's just me, but I find it a little counterintuitive.
-
The Java to Kotlin Converter isn’t great. Yes it converts your code, but in doing so makes it horrendously ugly. You will undoubtedly spend time refactoring and beautifying the code. A lot of times it creates noisy code, a lot of which can be deleted.
Overall
I heartily recommend Kotlin and will continue to use it in future projects.