https://kotlinlang.org logo
Join Slack
Powered by
Why is it bad in c# and fine in kotlin?
# coroutines
a
Why is it bad in c# and fine in kotlin?
w
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
d
C# is concurrent by default but Kotlin isn't.
C# aync code tends to be littered with awaits. Kotlin isn't as much.
Also Kotlin doesn't have async/await 😛, just suspend. 
kotlinx.coroutines
provides an async/await mechanism.
a
Kotlin async is definitely concurrent - if you launch two - they are both happening simultaneously
Kotlin 100% has async await and it is used - even in the readme and docs
w
check starting at page 221
maybe not super helpful since it's missing the talk part of the context but...maybe helpful 🙂
I think page 227 particularly is the issue
d
@asad.awadia I should have been clear about referring to 
suspend
not async/await.
The PDF doesn't show page numbers. 😞 . (sigh) I'll have to download it.
w
you can text search for "why no await keyword in kotlin"
d
Too late but thanks anyway.
a
We dont have an away ‘keyword’ but there is a method - what difference does that make? Its still the same functionality
w
gotta look at the PDF I linked
i
C# is like "You should have to await on this function" while Kotlin doesn't.
Intellij IDEA gives "Inappropriate blocking calls" without quick fix.
w
it also uses the absence of the "await" keyword to indicate concurrent behavior, which could be dangerous
The idea behind coroutines has always been being sequential by default, where as C# is concurrent by default. You opt-in by using async/await in Kotlin
b
the biggest (and most important) difference is that concurrency in kotlin is structured: https://medium.com/@elizarov/structured-concurrency-722d765aa952
b
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#
a
Well c# has async too tho
d
Same idea. Different semantics. They are not the same.
âž• 2
b
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
i
Developers have to worry about CPU-bound or IO-bound code in Kotlin, while C# does not.
d
Have to worry?
You mean "Can worry".
i
I guess. not many developers know which dispatchers to use.
b
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)
If you don't care. Simply use 
Default
OR 
IO
for everything, but there's a cost for not caring
i
My concern about "inappropriate blocking calls"
j
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.
3 Views
Open in Slack
PreviousNext
Powered by