This may be a stupid question, but does anyone know why coroutines in kotlin were designed the way they are? It seems like concurrency in other languages is much simpler with easier to understand syntax (im thinking async await). To me it seems coroutines in kotlin have a higher learning curve than what I have seen in other languages and im wondering if this was something done on purpose or if it will get better as time goes on.

The way Kotlin has implemented coroutines is more flexible, because you can do more than just `async`/`await`. See the

sequence

builder. Async/await are just implemented as a library on top of coroutines.

I really recommend you take a look in the Kotlin coroutines API and the possibilities that it can achieve, then compare with the others languages that you have use coroutines, then you will know...

So far I have only used it to run db and network operations asynchronously. I have also taken a look at Flow and Channels but those seem to just be an Rx abstraction on top of coroutines

There is amazing talk about designing coroutines by Roman Elizarov, who works on kotlin coroutines and libs. https://twitter.com/relizarov/status/1157398580170252300?s=19

Thank you! I will definitely watch that!

Btw, in the talk async await was mentioned if I remember correctly, so I think you should get answers for most of your questions :)

ya that talk looks like it answers my question. I will check it out. Btw I assumed there was a good reason for the way they were designed, I just wasnt sure what the reason was xD

This might a better intro talk, also has async/await comparison

Thank you Roman! I will watch both

intro to structured concurrency https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

@Stephan Schroeder Wow, that blog post is amazing

yeah, I’m pretty sure that’s the fundational article on structured concurrency.