News for hackers. Stuff that matters.
Re:Async Rust Is A Bad Language by harpiaharpyja on Friday September 08, 2023 @01:36PM (#37436748)
I remember picking up this sort of advice from a professor way back in college. It's a godsend. Structure the problem as data flowing between tasks and connect them up with queues, avoid sharing state. It's just a better way to deal with multithreading no matter what language you use.
Re:Async Rust Is A Bad Language by bluGill on Friday September 08, 2023 @01:52PM (#37436966)
There is a time any place for sharing state and data. However it is extremely complex to make that work, and so if at all possible don't. In general the only time I can't use queues is when I'm writing the queue implementation (I've done this several times - turns out there are a number of different special cases in my embedded system where it was worth it to avoid some obscure downside to the queues I already had).

When you need the absolute best performance sharing state is sometimes better - but you need a deep understanding of how your CPUs share state. A mutex or atomic write operation is almost always needed (the exceptions are really weird), and those will kill performance so you better spend a lot of time minimizing where you have them.

Re:Async Rust Is A Bad Language by samsquire on Friday September 08, 2023 @02:38PM (#37437592)
I like this too.

I would also suggest looking into ringbuffers and LMAX Disruptor pattern.

There is also Red Planet Lab's Rama, which takes the data flow idea and uses it to scale.

Re:Async Rust Is A Bad Language by brigadier132 on Friday September 08, 2023 @05:56PM (#37439878)
Async is not a solution for data parallelism.