Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can "experimental" Kotlin coroutines be used in production?

Can Kotlin coroutines be used in production, and what does their experimental status mean?

like image 226
Roman Elizarov Avatar asked Sep 15 '17 13:09

Roman Elizarov


People also ask

Are Kotlin coroutines experimental?

Kotlin Coroutines, even though already quite stable as in bug-free and ready to use in production code, were deemed experimental, which meant its API could change at any time.

What are Kotlin coroutines good for?

On Android, coroutines help to manage long-running tasks that might otherwise block the main thread and cause your app to become unresponsive. Over 50% of professional developers who use coroutines have reported seeing increased productivity.

Are coroutines stable?

Coroutines were already available in previous Kotlin releases, but version 1.3 makes them stable, meaning that their API will not change in future releases.

Are Kotlin coroutines concurrent?

Kotlin coroutines & structured concurrencyIn Kotlin, we can create coroutines using builders such as launch and async , which return a Job instance. This Job may further contain nested coroutine builders that create children Job instances that are computed concurrently.


1 Answers

UPDATE: Kotlin coroutines are no longer experimental as of Kotlin 1.3.

Kotlin coroutines can and should be used in production. That was the chief reason to officially release them in Kotlin 1.1. Having released them, the JetBrains team had committed to maintain backwards compatibility with respect to any changes that are introduced to them in the minor releases as they evolve, while allowing people to safely try them in complex production applications.

In short, the difference between “experimental” and “normal” features, is that for normal Kotlin features new stuff cannot be added in minor updates, because there is a "full compatibility" guarantee, while for experimental features new stuff can be added, but nothing can be removed (because of the backwards compatibility guarantee).

Experimental coroutines use a separate kotlin.coroutines.experimental package name, so that when coroutines design is finalized and they move to kotlin.coroutines package, old compiled code will not break, but will continue to work via a separate support library.

Further discussion (long-read) about why they are "experimental" and what does this mean can be found in this forum post by Andrey Breslav.

The same question applies to coroutines support libraries.

The current version of kotlinx.coroutines is designed for production use. It is pretty well covered with tests, lots of things are already optimized, all the changes are made considering the issues of backwards compatibility with previously compiled code. It certainly does serve as a test-bed for various coroutine-based things, so there are some parts that are clearly marked as "work in progress" or "unstable" in the documentation of the corresponding functions and classes. However, by default, all the public APIs in kotlinx.coroutines are considered to be stable and are being evolved, if needed, with appropriate migration aids.

like image 88
Roman Elizarov Avatar answered Sep 23 '22 12:09

Roman Elizarov