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

151–160 of 268 posts

Re: How to think about async/await in Rust

#151

Post by dboreham »

3np wrote: post #3
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…

Your comment seems to be conflating concurrency with parallelism. JS doesn't have any language-level abstractions for parallelism (async or not) but you do have Web Workers[0] and process forking (depending on runtime) to get actual parallel programming. JS async deals with concurrency, not parallelism. Threads are the opposite: They are interfaces for parallel programming and their use is orthogonal to how your appl…

> process forking (depending on runtime) to get actual parallel programming

If you get into a time machine back to the 1980s, then yes.

Re: How to think about async/await in Rust

#152

Post by nocontextpls »

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…

[dead]

Re: How to think about async/await in Rust

#153

Post by cmrdporcupine »

pkolaczk wrote: post #16
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…

async/await allows to do concurrency without the need for explicit synchronization to shared data structures. E.g. I can do: loop { select! { _ = src_channel.readable() => src_channel.read(&mut buffer), _ = dst_channel.writable() => dst_channel.write(&mut buffer), } } without any mutex guarding the buffer, even though the reads and writes happen concurrently and share the same mutable buffer. This is possible because…

This is great until someone calls you through with a multi-threaded task runner and you've just gone and added consistency and race conditions to your code.

Re: How to think about async/await in Rust

#154

Post by orangepurple »

3np wrote: post #3
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…

Your comment seems to be conflating concurrency with parallelism. JS doesn't have any language-level abstractions for parallelism (async or not) but you do have Web Workers[0] and process forking (depending on runtime) to get actual parallel programming. JS async deals with concurrency, not parallelism. Threads are the opposite: They are interfaces for parallel programming and their use is orthogonal to how your appl…

Web Workers are not parallel - they are only concurrent to the main context: think OS threads. Async JS is akin to using very lightweight simulated threads.

You will not necessarily utilize more CPU cores by spawning additional Web Workers because they are not inherenent parallel. The actual performance of Web Workers depend on how your browser and OS schedules threads.

They are OS threads despite the mountain of misinformation on the Internet about them implying that they are truly parallel. They are not.

Re: How to think about async/await in Rust

#155

Post by nvy »

3np wrote: post #124
usrbinbash wrote: post #97

Earlier quoted context omitted.

> Your comment seems to be conflating concurrency with parallelism. No, it really doesn't. I mention both concurrency and parallelism, and their main difference. > Threads are the opposite: They are interfaces for parallel programming No, they are not. Threads can do both. When waiting for an i/o bound operation, a thread can simply sleep. Added bonus: A thread basd implementation supports io bound concurrency and cp…

> 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 If the comment is not conflating concurrency and parallelism as you say, mind expanding on this part?

But concurrency is just "single core parallelism" anyways, so this isn't really germane to the discussion.

JS has neither.

Re: How to think about async/await in Rust

#156

Post by cmrdporcupine »

Hiding an asynchronous, co-routine, style program flow behind a syntax which looks like a sequential program flow is IMHO a design mistake I wish Rust had not made.

It's partially hiding what's under the surface.It makes programs harder to reason about. And, worst, it "infects" whole programs pushing async further and further up the call-chain, as the "sync to async" boundary is not a good story in Rust.

Finally the fact that async in Rust is effectively "tokio", it means this framework also gets all over the place, leading to dependency bloat and framework-itis. It potentially makes things that could be simple and re-usable components much more complicated and coupled to tokio than they could be.

I would have rather seen the language provide a nice way of doing continuation passing and an explicit coroutine construct.

That's my hot take. Personally I try to avoid async and stick with explicit concurrency & communicating by channels, until I am in a situation where I'm provably blocked primarily on I/O in a way that it would make sense to reach for it.

But I'm also not writing web services.

Re: How to think about async/await in Rust

#157

Post by hot_gril »

gavinhoward wrote: post #143

I'm a strong believer in structured concurrency over async. That said, I do not know if there would be an easier way to implement the state machine in the article using structured concurrency over async. Maybe that is actually one place where async would be better. I need to look into that. However, for those in the comments arguing that async is better for I/O-bound stuff, I heavily disagree. I implemented a multipl…

In the broad use case where you have an IO-bound server, how is this solution better than async? It sounds like your non-async solution was to reimplement async, which shows the value of the feature.

Re: How to think about async/await in Rust

#158

Post by ghosty141 »

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…

The biggest benefit of async/await is imo. in GUI programming where you simply can't have blocking code a lot of the time, and moving everything between the GUI thread and the backend thread can be rather costly and annoying as well as buggy if people are not 100% aware which thread accesses what.

I find it rather odd that you say "easier to reason about.". I find it much harder to keep a mental model in my head which thread currently does what compared to async/await code which you can write like synchronous code. You generally don't have to be that hyper-aware.

Re: How to think about async/await in Rust

#159

Post by zetaposter »

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…

async/await is about superimposing useful CPU computations with slow I/O operations.

For example, you would read data fragment D0 from a network socket, and right before doing any work on it, you ask the OS to fetch data fragment D1, etc. This would is faster than reading and working in distinct time intervals. And despite whatever you seem to believe, it would also be faster than reading and working using thread parallelism. Because even if you eliminate the synchronization overhead or you devise a good lock-free algorithm, thread context switches still have a massive overhead, not to mention issues related to memory bandwidth and cache coherence.

Still, how does one gather the nerve to call a feature present in most modern languages, from C# to Zig, a hype?

Re: How to think about async/await in Rust

#160

Post by bluepod4 »

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…

Maybe I’m wrong but the “asynchronous programming started with JavaScript” take doesn’t seem factual.
Post reply on HN