zlacker

[parent] [thread] 4 comments
1. fireyn+(OP)[view] [source] 2024-01-19 22:53:16
I may be the outlier but sync and async are both tools in the tool belt and ignoring one or the other is mostly silly?
replies(3): >>Yujf+i1 >>topspi+u2 >>omgint+z3
2. Yujf+i1[view] [source] 2024-01-19 23:00:50
>>fireyn+(OP)
What does this have to do with the article? The problem is for libraries: they want to support both sync and async use cases, without having to think about think about it, so that the user of the library can decide what is right for them.
3. topspi+u2[view] [source] 2024-01-19 23:08:00
>>fireyn+(OP)
This story is about not ignoring either sync or async...

It's great that the work finally led to both being supported. The cynic in me wonders if it's also async runtime agnostic, and not just Tokio. If that's possible.

4. omgint+z3[view] [source] 2024-01-19 23:13:52
>>fireyn+(OP)
My friend, did you jump to conclusions here? ;)
replies(1): >>fireyn+hv
◧◩
5. fireyn+hv[view] [source] [discussion] 2024-01-20 03:34:02
>>omgint+z3
I meant to more distill it like, any time you are making a choice between async or sync, you are making the wrong choice!
[go to top]