Do we need a whole new ekosystem?

There’s a joke that if you ask a developer to code a program to process widgets, they’d rather build a domain specific language and tool stack first to make life easier for when they might one day build the software that does the actual work.

A lot of development effort is under way to build a true Kotlin ecosystem: MockK for mocking, Kara for building web sites and Ktor for your obligatory asynchronicity. None of these frameworks let you do radically new things — they just do it the Kotlin way — but it’s proof that the language is gaining some real traction.

Going Kotlin all the way is good, if only because the seamless interoperability of JVM languages that we were promised is a bit more stroppy in the real world. In my recent hobby project I use at least two maven kustomisations — somebody stop this K-nonsense — to get Mockito and Jackson to behave more as you would expect. Pure Kotlin solutions can take away some of the pain of the mismatch. But it’s not all good news.

Firstly, it takes time for tools to become stable and mature. By their very nature they don’t live in a vacuum but have to inter-operate with other tools and frameworks that are bigger or more ubiquitous than themselves. A test mocking framework will have to integrate well with JUnit 5, which is why I have held off upgrading to JUnit 5 until my frameworks of choice fully support it. Early adopter? Ugly adapters! For Kotlin tools this is no different, and will add to the development effort to make these tools mature and stable in the firs place.

Early adopter? Ugly adapter.

All this new Kotlin goodness will probably be more elegant and make you eventually more productive, but only if Kotlin is your first language or if you come from a non-JVM background and don’t know the established Java toolbox. But that’s a minority, let’s face it. For experienced Java developers new to Kotlin the K-stack will add to the cognitive load at first. Maybe not too much for each individual tool, but the present-day full stack is a pretty tall one. Do not underestimate the learning curve towards it, even when these competing tools solve similar concerns.

Scala, by analogy, wants you to learn a new build tool (SBT) as well as a new testing framework (Scalatest) from day one. You can use Maven and JUnit, but it is discouraged. The argument runs that if you want to promote the best tools for the job, you mustn’t stick to the old workhorses. Sure, but if you want to stand a better chance to get a new language adopted in your company – let alone its whole ‘ekosystem’ -, you have to take baby steps.

While I agree that you should use the best tools for the job I also consider it a great selling point that Kotlin integrates so well, if not perfect, with granddaddies Maven, JUnit and Mockito. This way you can spend your precious time mastering the language itself, which I happen to find a lot more exciting than to grapple with a REPL. While I applaud the new K-stack, staying well-adapted to what comes out of Javaland is vital for survival.

This entry was posted in Blog, Kotlin and tagged , . Bookmark the permalink.

1 Response to Do we need a whole new ekosystem?

  1. Jarno Walgemoed says:

    Very interesting point of view, I have also pondered the relevance of new Kotlin specific frameworks and tools. While they fit better with applications built solely in Kotlin, they are at times not as mature as their Java counterparts and indeed do not always bring any significant new features to the table.

    At this point in time I’d opt for going the route Spring is going to name one: create a set of solid extensions on top of the Java codebase to provide Kotlin users a more compatible and fluent way to integrate. This means nobody in the ecosystem is left out when it comes to the functionality the framework offers, but some may just get to enjoy it a bit better.

Leave a Reply

Your email address will not be published. Required fields are marked *