I’m not chuffed about Kotlin coroutines.

Software development is as close to art as I’ve been able to come as an individual in terms of the way an application can be structured. There’s no one right way to do something, and depending on your application needs, you can mix and match solutions to different problems, like an artist with a paintbrush whisking lovingly away at their canvas.

Like artists have a variety of tools at their disposal to evoke the kind of emotional response they want from their audience, acrylic or oil based paint, perhaps even digital, software developers also do in terms of how they want to manage their application presentation and business logic.

I personally have fallen in love with functional reactive programming, and RxJava is my tool of choice. I tend to visualize my applications now as streams of state, data, or even UI interactions. As a bonus benefit, I can easily map my application state to a UI state, pass that along to my reactive views and they quite easily morph to the new state they ought to represent. I feel like Merlin honestly, I push a new state and viola, the View knows how to react to it. Prior to RxJava, my mechanism was more imperative. If state is this, then View should look like that, else if state is this, then…

This makes little difference to the computer. It does the same thing regardless, but I find the reactive stream version a lot more pleasurable to read and digest. This is where I find coroutines to be a bit “eh”.

My understanding of a coroutine in Kotlin can be summarized thus:

“Simplify the confusion and round about logic of asynchronous programming by flattening callbacks into code blocks that read pleasantly and synchronously, but still work asynchronously”

That’s a really nice thing, but my code still is asynchronous, it’s just made to look synchronous. It’s also rather imperative leaning. I’m working again in code blocks and method bodies, I don’t have my beloved stream abstraction. Say I invoke a method in a coroutine that returns some Type A that corresponds to UI State A. If an exception occurs and that exception corresponds to UI state B that requires further asynchronous processing, I need to call a different coroutine with the exception, then get UI state B. If however, I received Type A in a reactive stream, I can with RxJava onError resume some other reactive stream that would map my Exception to UI state B. I’d imagine it’d also be more readable and more concise. My code is reactive, the way I like it.

I program primarily in Java and Javascript. Coroutines in Kotlin look a lot to me like async/await in Javascript, and I don’t particularly care for those in Javascript either. I prefer promises, as if the result of a promise requires additional processing, I can just return another promise that will eventually return the final state I want.

The whole stream paradigm and easily mutating objects from one type to the next, wether in Java with RxJava or in Javascript with promises in node.js or RxJs for Angular really sits well with my software craftsman. Coroutines are nice in that they play well with RxJava, and more choice isn’t a bad thing, but I don’t necessarily want to mix the two, much like if I painted I wouldn’t want to mix water color and oil paint. Well, unless my painting required it.

So yeah, Kotlin coroutines are nice, I’m just not chuffed about them.