How do you call staying on the same coroutine (e.g. `delay(1000); print("hello")` vs. forking `launc...

# coroutines

[reactormonk]

How do you call staying on the same coroutine (e.g. delay(1000); print("hello") vs. forking launch { delay(1000); print("hello") }? Can't really say it's on the same thread, right?

[Joffrey]

Synchronous vs asynchronous

[Sam]

😄

[Sam]

Synchronous vs asynchronous

Now that's a can of worms

[reactormonk]

Yeah, I've opened a bit too many of these, but what can you do when you've got two independent state machines operating

[Sam]

I would call a single coroutine "sequential" and a group of coroutines "concurrent".

[Sam]

I agree with @Joffrey that it would be reasonable to call launch an asynchronous operation, since the coroutine it starts is asynchronous with respect to the caller. But the resulting terminology gets super confusing since coroutines make traditional asynchronous calls non-concurrent by default 🤯. I think most people would call a suspending function like delay() asynchronous even when there's no concurrency.

[reactormonk]

Maybe ordered vs. unordered?

[Sam]

That works, but I think sequential and concurrent are more commonly used terms for ordered and unordered.

[reactormonk]

Good point, I think that'll help conveying intent. Thanks.

[Joffrey]

> Can't really say it's on the same thread, right?
By the way, about this, definitely can't. After delay() the same coroutine could be resumed on a different thread. But if you want such terminology, "running in the same coroutine" is totally valid and implies sequential execution, where each instruction or function call behaves like a synchronous call from the point of view of the caller.

[Joffrey]

> I think sequential and concurrent are more commonly used terms for ordered and unordered
Agreed. I would even argue that you could have concurrent things that are eventually ordered. For example, a concurrent map operation that runs a transformation of each element in a collection concurrently can still guarantee that the results are ordered with respect to the original collection.

But I have to admit that technically the transformation operations themselves are unordered, only their results is ordered. I just think using concurrent vs sequential avoids confusion in this case.