News for hackers. Stuff that matters.

A comment on Tokio 1.0 – async runtime for Rust. Parent comment

Re:Tokio 1.0 – async runtime for Rust by artursapek on Wednesday December 23, 2020 @04:40PM (#25522543)
It's syntactic sugar that makes code a lot easier to reason about.
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by sanxiyn on Wednesday December 23, 2020 @04:48PM (#25522615)
Synchronous code is even easier to reason about than code using async syntax sugar.
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by nialv7 on Wednesday December 23, 2020 @05:26PM (#25523000)
No, multithreaded synchronous code is not easier to reason about than async. I think most would agree.
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by sanxiyn on Wednesday December 23, 2020 @05:33PM (#25523057)
I disagree, at least in Rust. async is hard. Threading is easy.
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by nialv7 on Thursday December 24, 2020 @11:26PM (#25534183)
Do you have something that backs up your belief?
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by akvadrako on Wednesday December 23, 2020 @05:44PM (#25523161)
You probably think async code can't have deadlocks like threaded code can. Async is still multi-threaded it's just that the threads are done in user-space and contain an implicit global lock.
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by nicoburns on Wednesday December 23, 2020 @08:07PM (#25524164)
Async is not pre-emptive though (if using a single theaded executor). And thats where most of the unintutive behaviour of threads comes from.
[ Parent | on HN ]
Re:Tokio 1.0 – async runtime for Rust by nialv7 on Thursday December 24, 2020 @11:25PM (#25534180)
Notice I didn't say async code is easier to reason about.
[ Parent | on HN ]