KotlinConf ’18: Kotlin all the things
A few days ago, a little over 1300 Kotlin nerds (Jan, Gerard, Remco and me included) were drawn to Amsterdam for the yearly KotlinConf.
While we at Craftsmen currently use Kotlin for backend projects, we noticed a very large number of mobile and frontend developers. Heck, the Friday keynote was even fully focussed on an iOS app (inspiring story, btw)!
What happened, you might ask? Well; turns out that while Kotlin started as a JVM language mostly popularized by Android developers, it aspires to be everywhere.
Kotlin. Kotlin everywhere.
With the announcement of Kotlin/Native last year, this year JetBrains officially announced the release of Kotlin/Native beta in Kotlin 1.3’s release. Kotlin/Native will compile to native code for iOS, Android, Windows, Mac and Linux.
And while I still have my doubts about it, they might be onto something.
At the beginning of app development, there was only native code and all was good. Until we found ourselves having two or three, mostly similar, codebases for both Android, iOS, Windows Phone (R.I.P.), etc.
Then we created hybrid frameworks, and we were happy again. Until we found performance to be lacking, and the platform-dependent “look and feel” to just be… off.
Gradle 5.0: Now type-safe with Kotlin
Talking about Kotlin being everywhere; a notable place where Kotlin is definitely going to start helping you is the soon-to-be-released Gradle 5.0 Here we finally see the production-ready Gradle Kotlin DSL 1.0.
I’ve tried to migrate from Maven to Gradle a few times, but was always annoyed by “trial and error” process. Mostly due to the untyped nature of Groovy and the unpredictability of the build scripts.
Gradle’s founder Hans Dockter gave a great introduction to Paul Martin’s “Type-safe build logic with Gradle Kotlin DSL” talk. In it he was really passionate about the move from Groovy DSL to Kotlin DSL due to its type- and null-safe nature.
Be sure to try it out on your next project!
Be like Kotlin, don’t be blocking: coroutines
For us as backend folk, the 1.3 release of Kotlin also has a pretty neat feature that was extensively covered in the second day of the conference: coroutines are no longer experimental.
In a trend started by NodeJS, a lot of backend frameworks have started to shift away from “just give this request a thread and please return it when you’re done, kind sir” type of deal, to an asynchronous, non-blocking paradigm.
We’ve seen the interest in this coding style in the popularity of our “Reactive programming” workshops, but also in innovations like Spring Boot 2’s Webflux. Which uses Reactor to transform requests into responses in a non-blocking way, using non-blocking web servers like Netty or Undertow.
One of the downsides of the reactive programming paradigm is that it’s a completely different coding style compared to the imperative style we’re so used to. Getting to know all the reactive operators and when to use them presents a steep learning curve.
Coroutines promise the same asynchronous, non-blocking behaviour as reactive code, but with the imperative style that we’ve come to know and love. And with nice exception handling too! It makes sure you can do multi-threading without the shared mutable state (the root of all evil and headaches). It does so using the power of channels, and it offers some nice abstractions on common patterns.
I’ll write a more in-depth post about coroutines soon, but it’s a nice alternative to the reactive programming. Or, even better; they play nicely together. At the end of Konrad Kamiński’s talk on “Coroutines and Reactive Programming – friends or foes?” he shows the power of Kotlin’s extension functions. With a single call we can transform our channel to an Observable, and our Observable to a channel, allowing you to use the most readable form of asynchronous code for your use case.
If you want to play with it now, I suggest taking a look at Ktor; JetBrain’s backend framework using coroutines for it’s request handling.
Kotlin continues to be a developer-friendly, reliable, type-safe language for more and more platforms. It tries to offer easy(-ish) solutions to hard problems like concurrency and nullability. And it improved its smart casting (now using Contracts for the more tricky situations).
Therefore it remains one of my favourite programming languages to date.
Oh and conference organizers take note? I loved the sweater vest instead of conference T-shirt and a wide selection of M&M’s 👍. Curious to see what you have in store for next year!