Why is it bad in c# and fine in kotlin?

IIRC the C# style is lazy by default, which was one of the reasons. I'm trying to think back to the coroutines masterclass I did about it

C# is concurrent by default but Kotlin isn't.

Kotlin async is definitely concurrent - if you launch two - they are both happening simultaneously

@asad.awadia I should have been clear about referring to

suspend

not async/await.

you can text search for "why no await keyword in kotlin"

Too late but thanks anyway.

We dont have an away ‘keyword’ but there is a method - what difference does that make? Its still the same functionality

gotta look at the PDF I linked

C# is like "You should have to await on this function" while Kotlin doesn't.

it also uses the absence of the "await" keyword to indicate concurrent behavior, which could be dangerous

the biggest (and most important) difference is that concurrency in kotlin is structured: https://medium.com/@elizarov/structured-concurrency-722d765aa952

In all of Roman's presentations he says "coroutines are explicit about being concurrent". You're right that you can explicitly launch 2 separate coroutines using

async { ... }

and then explicitly

await()

on them. Kotlin suspend function are written to look like regular code instead of shifting how you write code to use asynchronous programming. With regular code, a function is invoked and it either returns a value (or absence of a value, ie `Unit`/`null`) or throws an exception. With suspend functions it either returns a value or throws an exception. With regular code, if you want to run two things concurrently, launch two threads and call the code. With suspending code, launch two coroutines and call the code. But just as you did with regular code, you were explicit about doing things concurrently. The opposite of C#

Well c# has async too tho

Same idea. Different semantics. They are not the same.

Correct, and it makes you write and consider your code differently. C# only has async though. Kotlin coroutines don't need async to be extremely useful

Developers have to worry about CPU-bound or IO-bound code in Kotlin, while C# does not.

Have to worry?

I guess. not many developers know which dispatchers to use.

Using the correct dispatcher is optimizing your code.

Default

and

IO

share threads, it's just about the total pool size available to them. If you want your code to run at its best, you need to better understand of what you're telling your code to do (which is what all the presentations/articles that talk about the dispatchers are trying to achieve)

My concern about "inappropriate blocking calls"

Kotlin async is definitely concurrent - if you launch two - they are both happening simultaneously

This is not strictly true. The dispatcher may be single threaded which would not produce concurrent work.