Kotlin Native Coroutines Preview

kpgalligan profile image Kevin Galligan ・3 min read

Very recently, a draft PR (#1648) landed in the kotlinx.coroutines github that will enable multithreaded coroutines in Kotlin Native (KN). This is a big deal for the technology, and a lot of people have been waiting for it. I tweeted a little screenshot, and just that got a fair bit of attention

It is not a stretch to say a lot of developers have been waiting for this, as one of the tweet replies highlights:

To be clear, as much as this is a good thing technically, I think it's a big deal psychologically. You could achieve concurrency before multithreaded coroutines, and there are certain to be issues as the implementation emerges. However, a lot of people were waiting for this. There are technical reasons people were waiting, but in a more general sense, it's a reality signal. Multithreaded Coroutines make Kotlin Native more "real". In the JVM world, coroutines have been dominating the conversation around concurrency, so the lack of "full" coroutines in native was a signal that it's wasn't ready, or not a priority. That is changing.

What does this mean? In short, a big block to adoption has been removed. There's a lot of library work around architecture and concurrency that hasn't been happening because those implementations would largely be obsolete once multithreaded coroutines emerged. That block has been removed. We should expect a lot of follow-on library work, tech talks, and blog posts. Shortly after that, a lot of production deployment.

In short, a big block to adoption has been removed.

There has also been uncertainty around the threading model. Going back to the summer, the Kotlin Native repo got an experimental addition. Relaxed mode. It essentially let you access shared memory just like you can in the JVM. Whether that is a good thing or not is a much longer debate (which I'll be talking about at Kotlinconf). However, a lot of the community assumed relaxed mode existed in preparation for multithreaded coroutines. If relaxed mode became popular, it would probably end strict mode, but it was unclear which way things would go. There was a lot of uncertainty.

The uncertainty around Kotlin Native's state model is gone. Multithreaded coroutines work within the strict state model of Kotlin Native. That means although relaxed mode may be supported in the future, it is not the primary direction of the platform. Strict mode is here to stay.

The uncertainty around Kotlin Native's state model is gone.

We are currently in the middle of November. PR #1648 is still working it's way through completion. I would assume there is some release by Kotlinconf, which is ~3 weeks away. Just in time for people taking holidays to poke around. I'd expect to see a bit of activity in the community before the new year.

We will be doing an update to the DroidconKotlin app, using a few new libraries and, of course, multithreaded coroutines. Hopefully, we'll have a version of that out before Droidcon SF, but if not, sometime in December.

This is also a good time to tell you about our KaMP Kit. We've been talking to orgs evaluating Kotlin Multiplatform who have had some trouble getting started. The platform is moving fast, and there's a lot of conflicting or outdated info out there on the web. The KaMP Kit is a set of starter repos and documentation to get you set up for success quickly. Our first version will be released in mid-December. Go here to sign up for early access.

Touchlab is hiring mobile engineers excited about Kotlin Multiplatform. We are a remote friendly org. Come check that out if interested.


Editor guide