Hi guys, can someone comment on how true this comm...

# coroutines

[Hong Phuc]

Hi guys, can someone comment on how true this comment is https://www.reddit.com/r/Kotlin/comments/1kko2s7/comment/mrytehj/?utm_source=share&u[…]m=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button?

The commenter talked about why they wouldn't use ktor/coroutine, one of the issue they mentioned is that debugger doesn't follow the coroutine, but the carrier thread, which I have experienced before, another issue is that parameter will be marked as "optimised out", also the fact that code is "colored" with coroutine. I can't confirm about other issues that was mentioned, so I'm looking for everyone's opinion. Thanks in advance.

[Sam]

I largely agree with the Reddit thread, but I would say that many of the issues mentioned are problems with all forms of asynchronous programming, not just with coroutines. Asynchronous programming in general (whether with callbacks, coroutines, futures, etc) is a hefty trade off: it solves certain specific issues with UI programming and multitasking, but it's also harder to work with than ordinary threaded code. Coroutines reduce some of the friction that comes with asynchronous programming, but definitely not all. If you don't have a specific problem that you need to solve with asynchronous programming, you'd just be getting the downsides without the benefits.

[Hong Phuc]

How would such problem(s) that need to be solved using asynchronous programming look like? I came to choose using coroutine due to the fact that it is intuitive to read, write and understand (compared to something like Future), and I want my thread to be free to do something else instead of doing nothing and wait for data to be returned from network request, or just about anything that cause a thread to wait. Is that not enough of a problem to use coroutine/async programming?

[Sam]

If the cost of thread creation and switching is causing a bottleneck in your application then yes, reducing total thread count is a good use case for asynchronous programming. And yeah, I'd agree in choosing coroutines over futures. The Redditor is arguing that if you're on a modern JVM, the whole problem can be better solved by virtual threads. In general I think they're right, although if I was going to be handling a lot of multitasking directly in my own code (as opposed to via a framework) I still might lean back towards coroutines for their better structured concurrency tools.

[Sam]

Their claim that virtual threads "don't infect your code" is a bit of simplification, though. Launching any kind of background task (coroutine, thread, callback) "infects your code" in the sense that it creates the potential for a task leak. Coroutines just make that very visually obvious by trying to make it as hard as possible to create background tasks that don't obey structured concurrency.

[Hong Phuc]

Yes, seems like the redditor just hate writing the word suspend

[gildor]

Coroutines structured concurrency is a way better model IMO

[gildor]

I also like to have suspend and make it clear what is non blocking what is blocking

[gildor]

because even with virtual thread, one can easily block code anyway (with heavy computation for example) and I really prefer explicit marking

[Hong Phuc]

Structure concurrency with coroutines is definitely better, though I still wanted that I can just use debugger, profiler and get stacktraces the same way as java

[gildor]

Depends what you mean by the same way

[gildor]

There are trade-offs similar to any other async code

[reformator]

I still wanted that I can just use debugger, profiler and get stacktraces the same way as java

I take this opportunity to advertise a library for restoring the call stack in coroutines https://github.com/Anamorphosee/stacktrace-decoroutinator.

[Seri]

Yes, seems like the redditor just hate writing the word suspend

I see this criticism a ton. Folks hate bringing in a library/dependency and needing to adapt to that libraries own asynchronous language. In coroutines, that means needing to call suspend functions from your own suspend functions, hence "infecting" your codebase.

But in your case, you're developing your own application, not distributing a library. You get to have opinionated because you and your team are the only ones consuming it. If someone like this doesn't like whatever pattern you use, let them create an issue on your open-source project and fix it themselves.

[gildor]

> needing to adapt to that libraries own asynchronous language
It's also true for all async frameworks. Everything outside of CompletableFuture may not fit to specifc project
But I feel that coroutines are a way easier sell for any Kotlin project.
If library intended to be used not only for Kotlin but Java and other JVM languages in this case of course coroutines wouldn't work (UPD: for public API. Internally it's still fine)