Heads-up: on 10 July, we’re hosting a free live se...

# feed

[Halina]

Heads-up: on 10 July, we’re hosting a free live session with @marcinmoskala on common Kotlin coroutines mistakes.
If that’s up your alley, details are here 👇
https://webinar.kt.academy/common-mistakes-07

[Bogdan Vladoiu Lbs]

i think this person gives horrible advice. how about people learn about coroutines from https://kotlinlang.org/docs/coroutines-guide.html
the more institutional body of knowledge and practices for kotlin. must people sell classes and books even here?

[Bogdan Vladoiu Lbs]

is linkedin nott enough for the slop?

[marcinmoskala]

Hey @Bogdan Vladoiu Lbs, if there is anything you disagree with, I would love to hear about it, so I can improve my learning resources. I am always open to be convinced for different points of view.

[Bogdan Vladoiu Lbs]

hope you learn from the linkedin comments.

"In Kotlin coroutines, the environment is optimized for structured concurrency, which means you are generally supposed to hang on to the scope and burn through coroutines (i.e., launch and complete them within that scope)"

The only backwards advice with code examples that create and throw away a new scop on a getUser() method is from kotlin experts on linkedin. In a ktor server implementation even where performance dont even matter that much.

I dont have it in me to vet all your material. Some basic static quality tools that flag "garbage/allocation on accessor method" may point out to you some more inefficiencies in your code. Or people maybe can just learn from kotlinlang.org and not risk anything.

[marcinmoskala]

I understand you oppese using external scope in suspending functions, like in this example:

suspend getToken(): Token {
    val token = generateToken()
    applicationScope.launch { saveTokenToDb(token) }
    return token
}

I completely agree with that staying on the same scope should be the most basic way of operating in coroutines. Still, as a pratcicioner, I often meet with business requirements (especially on backend) where it is requested to start a process of doing something without waiting for its completion. I also regularly meet with cases when processes should outlive coroutines that started them. Do you have any better suggestion for those cases rather than using external scope?

[Bogdan Vladoiu Lbs]

does runBlocking{} speak to you?

[marcinmoskala]

Excuse me?

[Bogdan Vladoiu Lbs]

i dont think i know all the synchronization methods available in kotlin. there are that many. all of them not involving creating and throwing away a scope. do you feel this is good advice? i am going to not entertain this conversation further. i hope they call me to fix the applications and servers in the second or third year of development when none of them are working anymore.
i wonder why people buy one or two android phones and then some switch to an iphone because "the apps are more qualitive". its just the way life is and there is nothing we can do about it. people should learn from every class and book they find on the internet. except the official documentation of android and/or kotlin which also have free code labs

[marcinmoskala]

If you want to disciss it, feel free to send me a private message. I truly do my best to make applications (Android and backend) work better. I worked on some applications that were so screwed that were literally unusable, and fixing them to make them work like a charm. That is why I spend so much time on teaching now, because I know I cannot fix everything, people need to understand coroutines or they will make stupid things.

BDW the following code would not only await saving token (what is contrary to the requirement I mentioned), but it would also block the UI thread on Android (so result with ANR for some time), and on backend (depending on what dispatcher is used) it would likely end with thread starvation pretty quickly

suspend getToken(): Token {
    val token = generateToken()
    runBlocking { saveTokenToDb(token) } // NO-GO!
    return token
}

[Bogdan Vladoiu Lbs]

suspend fun getTokenBadExample(): Token {
    val token = generateToken()
    coroutineScope { // A new, temporary scope is created here
        saveTokenToDb(token) // This call runs directly within this temporary scope.
                             // It's a suspend function, so the coroutineScope block
                             // will suspend until saveTokenToDb completes.
    } // The temporary scope implicitly completes (and is effectively "thrown away")
      // as soon as saveTokenToDb(token) finishes.
    return token
}

this was your example. and they way you flipped it here is called sometimes, gaslighting. just like assuming people make mistakes when they use coroutines.

[Bogdan Vladoiu Lbs]

im out. happy sales

[marcinmoskala]

I do not remember this one, but it shows well a nonsense code. The name getTokenBadExample suggests that pretty clealry.

[marcinmoskala]

Comments also explain that this works just like:

suspend fun getToken(): Token {
    val token = generateToken()
    saveTokenToDb(token)
    return token
}

[marcinmoskala]

I will check out this post and make sure it is absolutely clear. I feel you have a problem with the fact that some of my learning materials are paid. Believe me, I could make much better money spending all my time on contracts than on selling books or courses. Many times I considered that, as it would be much easier live, but I feel mission in teaching, and I especially feel that teaching Kotlin Coroutines is important, as (just like most other concurrency frameworks) it is vastly misused.

[Bogdan Vladoiu Lbs]

not what i have a problem with. fixing broken servers and applications in the second or the third year. and having broken apps on my phone is what i have a problem with!

[marcinmoskala]

I have a problem with this one as well 😛

[marcinmoskala]

I absolutely hate the fact so many applications are pushing into new features and breaking existing functionalities. However, for that I believe better testing is essential.

[marcinmoskala]

BDW coroutines provide amazing testing capabilities most people do not know how to use.