News for hackers. Stuff that matters.
Re:How to think about `async`/`await` in Rust by mschuetz on Wednesday July 05, 2023 @03:41PM (#36605997)
I strongly disagree. Async/Await is one of the nicest, cleanest ways to deal with asynchronous tasks, and asynchronous tasks are everywhere. Loading data from disk without blocking and doing something once this is done -> async. Memcpying data from CPU to GPU without blocking -> async. Memcpying data from GPU back to CPU without blocking -> async.

Sure, there are other ways to handle these things like polling state, but async makes it trivial and readable.

But this mostly applies to JS which has a kickass implementation of async/await. Whatever C++ tried to do, it's an awful mess so there I still use threads with busy loops, polling, etc., whatever makes sense for the task at hand.

Re:How to think about `async`/`await` in Rust by usrbinbash on Friday July 07, 2023 @03:15PM (#36636940)
> But this mostly applies to JS which has a kickass implementation of async/await.

The fact that JS simply has no other options for doing anything concurrently, might have something to do with that.

Re:How to think about `async`/`await` in Rust by mschuetz on Saturday July 08, 2023 @04:39AM (#36642554)
Huh? It had other options longer than it had async/await. Async/await is a fairly recent addition. E.g. before fetch with async/await, there was XmlHTTPRequest with callbacks. It also had Web Workers as a means for parallel&concurrent processing for way longer than it had async/await.