Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to think about async/await in Rust

cliffle.com

Post reply on HN
Print view View original

261–268 of 268 posts

Re: How to think about async/await in Rust

#261

Post by starcraft2wol »

jayd16 wrote: post #220
starcraft2wol wrote: post #173

Earlier quoted context omitted.

> in GUI programming where you simply can't have blocking code a lot of the time, This can be transparently solved by the GUI library. The main thread does a loop and polls events from a queue. Those events are generated by a gui on another thread. It can be designed so gui itself can be manipulated on the mainpulated on the main thread, and the event handling and rendering is double buffered, or synchronized for you…

What GUI system are you referring to? As far as I know, pretty much all major UI frameworks use a single thread, or at best a gui thread and a render thread.

I believe SDL works how I described. But yes, I was trying to describe a gui/render thread split.

Re: How to think about async/await in Rust

#262

Post by jayd16 »

starcraft2wol wrote: post #261
jayd16 wrote: post #220

Earlier quoted context omitted.

What GUI system are you referring to? As far as I know, pretty much all major UI frameworks use a single thread, or at best a gui thread and a render thread.

I believe SDL works how I described. But yes, I was trying to describe a gui/render thread split.

Pulling out the render thread just helps offloads the GPU calls, no? The GUI thread still has the usual single thread concurrency issues most programmers deal with.

Re: How to think about async/await in Rust

#263

Post by usrbinbash »

phicoh wrote: post #29
usrbinbash wrote: post #2

Not specific to rust, but I think asynchronous programming in general is a hype. It didn't start because it is so awesome, it started because JS can't do parallel any other way. That's the long and short of it. People wanted to use JS in the backend for some reason. The backend requires concurrency. JS cannot do concurrency. Enter the event loop. Then enter some syntactic sugar for the event loop. And since JS is pop…

In C, I have written and worked on a lot of code that is event-based. Async is a natural extension to that. So, no it is not a hype. These types of techniques have been used for a very long time.

Allow me to clarify:

Event Loops are an old technique and not a hype. I am aware of that. One of my earliest C experiments as a kid was writing a snake-implementation for the terminal. I still have that code, and it uses an event loop to process the input.

The hype I am talking about, is an assertion currently "en vogue", that asynchronous should be the default method of doing concurrency.

This hype, imho, started with the ubiquitous use of JS as a backend implementation language. JS couldn't work another way, so this is what all these JS programmers used, and JS is super popular. So, it must be cool and great. And that's how a workaround for a language limitation became a popular paradigm.

Re: How to think about async/await in Rust

#264

Post by usrbinbash »

littlestymaar wrote: post #127
usrbinbash wrote: post #2

Not specific to rust, but I think asynchronous programming in general is a hype. It didn't start because it is so awesome, it started because JS can't do parallel any other way. That's the long and short of it. People wanted to use JS in the backend for some reason. The backend requires concurrency. JS cannot do concurrency. Enter the event loop. Then enter some syntactic sugar for the event loop. And since JS is pop…

> Code written using threads is, at least to me, much more readable and easier to reason about. It's “easier” because it lies to you and makes you assume that everything is sequential, but it's not, and sometime that “everything is sequential” abstraction is leaky, and you can't really see what's going on without diving to the bottom of every functions. I've been accustomed so much to the transparency of async/await,…

> It's “easier” because it lies to you

No, it really doesn't. If I make the wrong assumption that "everything is sequential", then it's not the paradigm lying to me.

Pretty much the first thing I learned about threads: I have to assume that my code can, and will, be interrupted at arbitrary points.

As long as I keep that in mind, there is very little that can surprise me. Because the other side of that coin reads: "Unless it branches into more threads of execution, each block itself will run sequentially, no matter what", which makes it very easy to reason about each block.

The rest is a matter of synchronizing these interruptions to a useful outcome, which, as stated elsewhere, CSP and modern languages integrating the primitives for that natively, make really easy.

Re: How to think about async/await in Rust

#265

Post by atombender »

munificent wrote: post #259
atombender wrote: post #257

Earlier quoted context omitted.

Nobody was doing async JS before Node, which came long after async I/O was an established paradigm.

XMLHttpRequest shipped in 1999. AJAX was coined in 2005. The "A" in "AJAX" is for "asynchronous".

XMLHttpRequest may be async, but it's not an asynchronous programming model.

Re: How to think about async/await in Rust

#266

Post by mpweiher »

pavlov wrote: post #226
mpweiher wrote: post #219

Earlier quoted context omitted.

Use one or more service threads to do most work off the UI thread.

Yes, sure. Operating systems nowadays provide useful thread pool runtimes for this purpose, like Apple’s GCD. In no way does it mean that you don’t need an event loop because threads exist, as was the contention here.

1. You don't need either thread pools or GCD for this. GCD generally makes things worse.

2. It absolutely does mean you don't need the main thread event loop for non UI-events.

Re: How to think about async/await in Rust

#267

Post by usrbinbash »

mschuetz wrote: post #228
usrbinbash wrote: post #2

Not specific to rust, but I think asynchronous programming in general is a hype. It didn't start because it is so awesome, it started because JS can't do parallel any other way. That's the long and short of it. People wanted to use JS in the backend for some reason. The backend requires concurrency. JS cannot do concurrency. Enter the event loop. Then enter some syntactic sugar for the event loop. And since JS is pop…

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 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

#268

Post by mschuetz »

usrbinbash wrote: post #267
mschuetz wrote: post #228

Earlier quoted context omitted.

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 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.

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.
Post reply on HN