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

171–180 of 238 posts

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

#171

Post by jensneuse »

zamadatix wrote: post #72
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…

A good example is say you want to handle 100k TCP sessions concurrently. You probably don't want to launch 100k threads considering the overhead in doing so and constantly switching between them. You also don't want to do things synchronously as you'll constantly be waiting on pauses instead of doing work on the 100k sessions. So you launch 100k instances of it as an async function and they all stay in a single threa…

Does this mean that rust async is using poll/epoll/kqueue under the hood?

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

#172

Post by justicezyx »

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…

User space threads and corouting is pretty much the right abstraction for application code.

Async can be useful when more control over the details of execution is needed.

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

#173

Post by Argorak »

MaxBarraclough wrote: post #132
Argorak wrote: post #108

Earlier quoted context omitted.

> It's best to treat 'await' as syntactic sugar, and to dig in to the underlying concepts. Slight word of warning: `async/await` is more than just sugar in Rust, it also enables borrowing over awaits, which was previously not possible.

Interesting, thanks.

Nerding a bit more, it was a bit late yesterday: this is why the Future takes this weird type called a `Pin`, which is a guarantee that the value does not move in memory while the Future is polled. This is also one of the reasons the feature took so long, Rust previously only had ways to detect potential moves in memory, but could not disallow them.

https://doc.rust-lang.org/std/future/trait.Future.html#requi...

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

#174

Post by Argorak »

jeremyjh wrote: post #119
Argorak wrote: post #113

Earlier quoted context omitted.

Any code in Rust is free to bind to FFI and sockets can be gained through `libc`.

I didn't literally mean "How is that possible?" I meant: is that a real thing? Is there a database binding out on crates.io that uses no_std ?

Yes. E.g. some databases highly recommend using their C library, as they don't consider their protocol specified.

That gap might close, but it will stay with us for years.

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

#175

Post by otabdeveloper2 »

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

> I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead.

'async' exists because Python has that GIL bullshit and so Python programmers had to invent that fifth wheel of 'async programming'.

Programmers in other languages then got jealous because they, too, wanted a complex, unnecessary framework that pollutes the whole runtime and serves to differentiate regular programmers from 'rockstar' programmers.

And so async got fashionable and barely-literate coders now think async is magic performance dust that will automatically make your program run 1000% faster.

TL;DR - it's just fashion, give it five years and we'll be reading posts about how async sucks and that it's stupid legacy tech invented by bonehead dinosaurs.

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

#176

Post by steveklabnik »

jensneuse wrote: post #171
zamadatix wrote: post #72

Earlier quoted context omitted.

A good example is say you want to handle 100k TCP sessions concurrently. You probably don't want to launch 100k threads considering the overhead in doing so and constantly switching between them. You also don't want to do things synchronously as you'll constantly be waiting on pauses instead of doing work on the 100k sessions. So you launch 100k instances of it as an async function and they all stay in a single threa…

Does this mean that rust async is using poll/epoll/kqueue under the hood?

Strictly speaking, it's not tied to any particular method. It depends on your executor. That said, the most popular executor does use epoll/kqueue/iocp. (tokio)

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

#177

Post by spullara »

nine_k wrote: post #164
spullara wrote: post #22

Earlier quoted context omitted.

N threads, with N readers waiting for a message that will only come if the N+1 reader (still in the queue) gets a message first.

But sure one must use an output queue, not synchronously wait for the consumer to consume a result?

The N + 1 readers are all reading different sockets, blocked.

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

#178

Post by Argorak »

bpye wrote: post #154
davidhyde wrote: post #4

Great library, well done. In case anyone was wondering this is not a [no_std] crate even though it can be used as a replacement for std library calls. I guess it (obviously) can't be since it interfaces with the operating system so much.

I really wish we could work out a better way to make no_std easier. I know why io::Error requires std for example, but it makes things difficult. It would be nice if you could provide your own sys crate so you could even use some of std on an embedded device. If you had say an RTC you could make time related calls work, maybe you'd wire networking to smoltcp etc. Currently you could do that - maybe - but you'd have t…

The stdlib is already just a facade. There's plans to make that more explicit, maybe opening up the way to things like that.

But that plan is severely understaffed, we go so much else to do.

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

#179

Post by [deleted] »

Argorak wrote: post #38
vbezhenar wrote: post #27

Earlier quoted context omitted.

> It's trivial to turn async into sync in Rust. You can use ".poll", "executor::block_on", et cetera. Is it 0-cost abstraction? I mean, is `sync_read` will compile to the same code like `async_read.poll`? Because turning sync into async is kind of trivial as well: just spawn new thread for that sync block.

0-cost abstraction was summarised by Stroustrup as: > What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better. In that mind-set, it is completely okay that `sync_read` and `async_read.await` can totally compile to something different, as they abstract different things. Boats has some more thoughts on this here: https://boats.gitlab.io/blog/post/zero-cost-abstractions/

[deleted]

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

#180

Post by je42 »

pcwalton wrote: post #128
nullwasamistake wrote: post #102

Earlier quoted context omitted.

Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency. Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,0…

25,000 threads are perfectly fine on Linux.

it is the memory associated with a posix thread that becomes the limit.
Post reply on HN