Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> If you are ten layers deep in a stack of synchronous functions and suddenly need to make an asynchronous call, the type signature of every individual function in the stack has to change.

well, this isn't really true - at least for Rust:

runtime.block_on(async{});

https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.htm...

 help



See my other post about the point. If you "just" turn an async back into a sync call by completely blocking the async scheduler, yes, you've turned the async call back into a sync call, but you've done that by completely eliminating async-ness. That's not a general solution. That is exactly what everyone back when Node was promoting this style spent paragraph upon paragraph warning you not to do, because it just punts by eliminating the asyncness entirely. "Async is great when you completely discard it" is not a winning argument for async... which is OK, because it's not the argument anyone is making.

> If you "just" turn an async back into a sync call by completely blocking the async scheduler,

I am not doing that. The caller (which is the only one being blocked here) is sync anyways and just wants to call an async function, so no async scheduler is blocked.


In Kotlin, it’s runBlocking {<asynchronous-code>}.

This is a language specific problem, not a language pattern one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: