Our other favourite K

Kotlin is taking over our lives (in a good way)

Last time, I wrote about Kubernetes revolutionising ops at Quartic. We’re habitually picking technologies starting with K; lately it’s been Kotlin.

In truth, we’d all been thinking about the tools we want our team to settle on (despite being less than a year in) — running our own shop means we’re allowed to take risks and make radical changes. And importantly, to find our own technical identity.

We’d laid our platform foundations with Java 8. But something felt old-fashioned. Nothing you haven’t heard before — too much boilerplate, mutability by default, tedious composition due to lack of a delegation mechanism. APT workarounds (such as the wonderful Immutables library) provided lift, but introduced problems of their own.

What’s more, we found ourselves writing code in an increasingly functional spirit. We’d heavily adopted RxJava in our computation engine (more on that in future posts), to the point that explicit control flow and state had become anomalies.

Decisions

So: (1) scope to try something radical, (2) a JVM-oriented codebase, and (3) a strong functional bias. Orthodoxy suggested we pick up Clojure. Or Scala perhaps.

However, some important context is that I’m a blub programmer. A self-aware blub programmer. Recasting the way we think about everything (I like my types) felt like too much effort/risk at this stage. And frankly the baroque kitchen-sink complexity of Scala scared us.

Enter Kotlin. It’s the new kid on the block — it only 1.0-ed early last year. It has a powerful static type system, zero-overhead null safety, type inference, immutability by default, delegates and extension functions, a relatively powerful standard library, and tight Java interop. But it still reads more like Java than say Clojure or Haskell, lowering the psychological barrier to entry (important, given my blubness). It nominally ticks all the boxes.

So off we set.

Crossing the chasm

Madness would have ensued if we’d rewritten everything. Instead, we picked a couple of smaller microservices to use as a test-bed. It took less than a day to sort out the build and CI, and rewrite the code in what felt like a Kotlinesque way. And we were impressed. 700 lines of Java boilerplate disappeared in our first PR alone!

We continued to be impressed as we wrote our Android app exclusively in Kotlin. Impressed not just with the core selling features, but also the language documentation, the nice touches (need to create a modified copy of an immutable object? person.copy(age = 27)), and the strong emphasis the Kotlin team places on community input on upcoming language features.

That said, we expected some rough edges, and those expectations were met. Some of the tooling is still clunky — the IntelliJ plugin is slow, and the Kotlin/Android/Gradle/IntelliJ (KAGI?) integration is awkward. The Kotlin compiler has quirks — there’s a longstanding issue that breaks parallel compilation, for example.

And there’s a frequent reliance on wrappers to achieve idiomatic Kotlin with existing Java libraries (though that’s not really Kotlin’s fault). Take Mockito as an example. We immediately adopted Niek Harmaan’s great Mockito bindings, but also needed an incubating Mockito feature to mock final classes (everything in Kotlin is final by default).

But

Despite all the gushing, we still have a major existential concern. Literally — will Kotlin continue to exist? It’s a young unestablished language, and we all saw what happened to Groovy a while back. We can’t afford for our entire codebase to be in Latin in a few years’ time.

Luckily, the evidence is that the community is growing from strength to strength, and the backing of a major player like JetBrains can only be a good thing.

In conclusion

Startups aren’t defined by the quality of their code, nor the languages they use, nor beautiful microservice architecture. Focus too much on those and you’ll die. But that doesn’t mean you can’t do things to improve your velocity, quality of life, and internal tech culture. Kotlin has done that for us so far.

We think a lot about its future (much like we think about our own), so for now we’re hedging. But we’re continuing to place those bets.

About me

I’m Oliver, head of engineering at Quartic Technologies. We’re building a platform to bring real-time business analytics to operations in the field.