Can Kotlin coroutines be used in production, and what does their experimental status mean?
86
votes
1 Answers
114
votes
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.
