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

Async-std: an async port of the Rust standard library

async.rs

Post reply on HN
Print view View original

51–60 of 238 posts

Re: Async-std: an async port of the Rust standard library

#51

Post by jeremyjh »

bryanlarsen wrote: post #11
Un1corn wrote: post #5

This remind me of the blog post "What Color is Your Function?"[0], they had to create a different library that is the same as the standard library but with async functions. I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead. [0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

None of the 5 points in that article about callbacks in 2015 node.js apply to async in Rust. The Rust people spent years agonizing over their version of async and applied a lot of lessons learned from implementations in other languages. https://news.ycombinator.com/item?id=20676641 It's trivial to turn async into sync in Rust. You can use ".poll", "executor::block_on", et cetera. Turning sync into async is harder in…

> that would have been hard to do 5 years ago.

Five years ago Rust still had green threads. Literally every standard library I/O function was async, and the awaits were always written for you with no effort.

Its literally taken five years to get back to an alpha thats not as good, and we'll still have to wait for a new ecosystem to built on top of it. I know not everyone writes socket servers and so forcing the old model on everyone probably doesn't make sense long-term, but I still have to shake my head at comments like this.

https://github.com/rust-lang/rfcs/pull/230

Re: Async-std: an async port of the Rust standard library

#52

Post by Argorak »

2bitencryption wrote: post #46

I must be dumb, because every time I dive into async/await, I feel like I reach an epiphany about how it works, and how to use it. Then a week later I read about it again and totally lost all understanding. What do I gain if I have code like this [0], which has a bunch of `.await?` in sequence? I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are…

In small examples like this, you don't gain anything. For the sake of the example, we just run one task. But you _could_ run 100 with them. And at each of those `awaits`, they could schedule differently.

For a more complex networked application, we have the tutorial here: https://github.com/async-rs/a-chat

Re: Async-std: an async port of the Rust standard library

#53

Post by aphexairlines »

Argorak wrote: post #44
pohl wrote: post #8

Earlier quoted context omitted.

The caller of the function knows nothing about what happens within the body of the function. (Is it just doing computation, or is it doing I/O?). The async keyword is how the author of the function makes it explicit that caller should choose when to await the result. Isn't the alternative WCiYF is proposing to allow the caller to treat any function asynchronously, while having no way to discern whether doing so might…

Rust async functions are also different here. They don't run the code, they create a Future structure in it's initial state. Contrary to e.g. JavaScript, it doesn't start to run until you end up putting it on an executor. So the actual function call does something very different from what happens in other languages. It's sometimes called "cold futures".

Sounds similar to what the Scala ecosystem calls Tasks.

https://monix.io/docs/3x/eval/task.html#introduction

https://github.com/traneio/arrows#using-task

Re: Async-std: an async port of the Rust standard library

#54

Post by weavie »

2bitencryption wrote: post #46

I must be dumb, because every time I dive into async/await, I feel like I reach an epiphany about how it works, and how to use it. Then a week later I read about it again and totally lost all understanding. What do I gain if I have code like this [0], which has a bunch of `.await?` in sequence? I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are…

Yeah if there are no other futures spawned, then the await is going to cause the app to just sit there until the future completes. It's got nothing better to do.

If there was another future spawned then the await would cause the runtime to sit there until either of the futures completed. The code would attend to the first future that completes intil that hits an await.

Re: Async-std: an async port of the Rust standard library

#55

Post by hathawsh »

DecoPerson wrote: post #24
otabdeveloper2 wrote: post #19

Earlier quoted context omitted.

Cooperative multitasking, like it's 1995 again? No thanks.

Would you mind elaborating on your opinion here? As far as I understand, cooperative is far more efficient than preemptive, but unsuitable for poorly written or untrusted code. I wish to learn and would really appreciate your assistance if you are willing to help.

The key difference is cooperative multitasking lets the program yield the thread anywhere, not just to the event loop like async programming. Arbitrary yielding was a feature that programmers widely abused in the early Windows days. The user would start something in an app that takes some time to complete; the app would freeze for a while, but all other apps remained usable. It was obvious that the programmers, rather than solving the real problem, had sprinkled some yield instructions throughout the program, which allowed the computer to keep working even though the app was unresponsive. It's a good thing that async programming frameworks don't usually allow yielding from arbitrary places.

Re: Async-std: an async port of the Rust standard library

#56

Post by guntars »

wahern wrote: post #35
bryanlarsen wrote: post #11

Earlier quoted context omitted.

None of the 5 points in that article about callbacks in 2015 node.js apply to async in Rust. The Rust people spent years agonizing over their version of async and applied a lot of lessons learned from implementations in other languages. https://news.ycombinator.com/item?id=20676641 It's trivial to turn async into sync in Rust. You can use ".poll", "executor::block_on", et cetera. Turning sync into async is harder in…

Literally none of your rebuttals actual rebut the claims. The very fact that async-std exists is absolute proof that the issue remains--if there wasn't a "color" problem there wouldn't be any need for a "port" of the standard library. Rust had legitimate reasons for taking the approach that they did. One can agree that they made the correct decision without excusing and obscuring the consequential costs.

The async-std is taking the “always red” approach that the article mentions and that wasn’t possible until now due to async being hot of the presses. The rest of the arguments in the article are based on the point that “red functions are more clumsy to call” which doesn’t hold for Rust, but holds for JavaScript.

Re: Async-std: an async port of the Rust standard library

#60

Post by wahern »

slovenlyrobot wrote: post #13
dmytroi wrote: post #12

Earlier quoted context omitted.

Except that io_uring is threads running in kernel. There is no true async I/O on most (if not all) current platforms - it's all threads, either in user space or in kernel space. Sometimes even deliberately, for example polling disk will give better latency compared to waiting for IRQ.

AFAIK Windows handles truly asynchronous buffered IO in some circumstances, but I feel once you're past the point of managing the abstraction or caring about its internal details, it doesn't really matter if there is a tiny chunk of dedicated stack in the kernel, that's a problem for the OS

IOCP uses a pool of quasi-kernel threads (i.e. schedulable entity with a contiguous stack for storing state) with polling, very much like how io_uring and other incarnations of AIO in the Linux kernel work; and for that matter it's not unlike how purely user space AIO implementations work. The benefit of IOCP and io_uring is there's one less buffer copying operation. The biggest benefit of IOCP, really, is that it's a blackbox that you can depend on, and one that everybody is expected to depend upon. So it can be whatever you want it to be ;)
Post reply on HN