Local async executors and why they should be the default
1–10 of 327 posts
Re: Local async executors and why they should be the default
#2> Posted on June 9, 2022
Re: Local async executors and why they should be the default
#3Multithreading, why does everyone always do it wrong?
One of life's big questions.
Re: Local async executors and why they should be the default
#4> Posted on June 9, 2022
Yeah, it is old. But I only found it recently and did not see a discussion of it yet.
I found this quite interesting. I love rust, but async rust always seems almost like a different language.
Lifetimes become much more complex and much less useful, you use Box and Arc way too much. It seems like you would be better off if everything was heap allocated.
Working with local futures brings back some of the things I love about rust, but it is certainly not prominently featured in libraries like tokio and the entire async ecosystem.
Re: Local async executors and why they should be the default
#5Multithreading, why does everyone always do it wrong? One of life's big questions.
Because there are no actual good sources to implement async/multi threading programs.
Re: Local async executors and why they should be the default
#6Multithreading, why does everyone always do it wrong? One of life's big questions.
I think rust does it right in many cases. Raw rust multithreading is a pleasure to use, and some libraries like rayon are extremely unobtrusive.
That is why I am somewhat unhappy with the state of async rust. It does not yet have the quality and unobtrusiveness of sync rust libraries like rayon.
Re: Local async executors and why they should be the default
#7Multithreading, why does everyone always do it wrong? One of life's big questions.
Pray tell, what's the objective right way?
Re: Local async executors and why they should be the default
#8Re: Local async executors and why they should be the default
#9Multithreading, why does everyone always do it wrong? One of life's big questions.
I think rust does it right in many cases. Raw rust multithreading is a pleasure to use, and some libraries like rayon are extremely unobtrusive. That is why I am somewhat unhappy with the state of async rust. It does not yet have the quality and unobtrusiveness of sync rust libraries like rayon.
Yeah, I just recently picked up rust and rayon is so awesome. It is great to be able to instantly parallelize an iterator.
Re: Local async executors and why they should be the default
#10"If you write regular synchronous Rust code, unless you have a really good reason, you don't just start with a thread-pool. You write single-threaded code until you find a place where threads can help you, and then you parallelize it, [..]"
I cannot agree more with that. As someone who's done a good deal of Java in my day job, I can tell you a thing or two about spawning threads willy-nilly. At least it is easier to avoid in Rust, but I'd still prefer it the other way round: opt-in, instead of opt-out.