# Phantom of the Coroutine

DevFeed: [Phantom of the Coroutine](<https://devfeed.tech/articles/phantom-of-the-coroutine-26025.md>)

Original publisher: [Read original article](<https://elizarov.medium.com/phantom-of-the-coroutine-afc63b03a131?source=rss-4762e889f8fc------2>)

Author: Roman Elizarov

Published: 2020-05-10T07:53:50Z

Content type: tutorial

Language: en

Sources: [Stories by Roman Elizarov on Medium](<https://devfeed.tech/sources/stories-by-roman-elizarov-on-medium.md>)

Topics: [Coroutines](<https://devfeed.tech/topics/coroutines.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [coroutine](<https://devfeed.tech/tags/coroutine.md>), [coroutines](<https://devfeed.tech/tags/coroutines.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [kotlin-coroutines](<https://devfeed.tech/tags/kotlin-coroutines.md>), [programming](<https://devfeed.tech/tags/programming.md>)

## AI overview

The article explains why coroutines are ephemeral rather than manipulable objects like threads. It introduces coroutine transparency, showing how concurrency can be added with coroutineScope and launch while remaining largely invisible to callers, and discusses immutable coroutine context as a consequence.

## Source excerpt

Photo by Linus Mimietz on Unsplash Threads are heavy-weight and have substance. With threads, we can get a reference to some kind of current Thread object, examine its properties, modify its thread-local variables, and otherwise manipulate it. It is no surprise that people with the thread-programming background and education, who are coming to programming with coroutines, are looking for some kind of Coroutine object they can get hold of. However, there is none. Coroutines are phantom, ephemeral, insubstantial. There are good reasons for this state of affairs and some non-trivial consequences. Let's dig in. The rule of coroutine transparency Consider the following suspending function foo that performs some work and then writes the resulting data to a database and sends a message with it over a message bus (both use network and are suspending, too). suspend fun foo() { val data = doSomeWork() writeToDatabase(data) sendMessage(data) } We can speed foo function up by calling writeToDatabase concurrently with the rest of the code that does sendMessage. It is straightforward-- just delimit a scope for this concurrent operation and use launch function: suspend fun foo() = coroutineScope { val data = doSomeWork() launch { writeToDatabase(data) } // concurrent now sendMessage(data) }We don't have to explicity wait for writeToDatabase operation to complete before returning from foo because coroutineScope builder does this wait automatically. The rule of coroutine transparency states that neither the caller of foo nor the function writeToDatabase should be aware of or be affected by this introduction of concurrency. Having a separate coroutine should be completely transparent. Stated more narrowly, replacing a direct call to writeToDatabase(data) with a call from another coroutine viacoroutineScope { launch { writeToDatabase(data) } } should have as little noticeable effects as possible. Of course, all software abstractions are leaky and we only have an illusion of true transp