Async-std: an async port of the Rust standard library • Hacker News Board

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

#201

Post by zzzcpan » Sat, Aug 17, 2019, 11:54 AM UTC

MrBuddyCasino wrote: post #200

noncoml wrote: post #193

Earlier quoted context omitted.

Nobody is denying that async code is faster. But it’s not as dramatic as presented in the grand parent post. And IMHO the added code complexity is not worth the trouble.

> And IMHO the added code complexity is not worth the trouble. The thing is, this is just that - your opinion, generalized as The Truth. But engineering is about making the right trade-offs. Often threading will be fine, you'll win simplicity, and all is good. But sometimes you really need the performance, or your field is crowded and its a competitive advantage. Think large-scale infrastructure at AWS, central load-…

It goes deeper than that. There is plenty of research showing that shared memory multithreading is not even a viable concurrency model. The premise that threads are fine and simple is just false.

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

#202

Post by zzzcpan » Sat, Aug 17, 2019, 11:57 AM UTC

badamp wrote: post #123

zzzcpan wrote: post #39

Earlier quoted context omitted.

Even conceptually the models are very different, in one control is just given up and regained unpredictably, while in the other one it is programmed, hence asynchronous programming, not multitasking.

> in one control is just given up and regained unpredictably Which one? It’s “cooperative” ie not unpredictable. The points where one can block are predictable and documented explicitly, otherwise how would the programmer know they won’t block forever. The same should hopefully be the case for async/awaitable apis. In fact where async/await will actually give up control are harder to tease out. The differences are re…

In cooperative multitasking you can program when to give up control, not when it is regained. The regaining part is unpredictable. Which introduces a lot of non-determinism to deal with and overhead.

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

#203

Post by ShinTakuya » Sat, Aug 17, 2019, 12:25 PM UTC

limsup wrote: post #170

It looks great. But it's odd that they do not cite Tokio. I know this isn't an academic paper, but come on have some professional curtesy and discuss the contributions made in prior art.

Apologies if I'm misunderstanding things here, I'm just now getting back into Rust after a couple of years of not using it. Did Tokio really inspire this library that much?

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

#204

Post by fluffything » Sat, Aug 17, 2019, 1:50 PM UTC

atombender wrote: post #195

steveklabnik wrote: post #176

Earlier quoted context omitted.

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)

Doesn't the executor need to be aware of all the different mechanisms that can be used to poll, and so there's an implicit coupling between the async function implementation and the executor? For example, socket.read() might return a future that represents a read on a file descriptor. I don't know the internals of Rust's async support at all, but presumably the future is queued up and exposes some kind of trait that…

The TL;DR: is that, while the `std::future::Future` trait is generic, the actual type that implements this trait is often tied to a particular executor.

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

#205

Post by fluffything » Sat, Aug 17, 2019, 1:51 PM UTC

steveklabnik wrote: post #199

atombender wrote: post #195

Earlier quoted context omitted.

Doesn't the executor need to be aware of all the different mechanisms that can be used to poll, and so there's an implicit coupling between the async function implementation and the executor? For example, socket.read() might return a future that represents a read on a file descriptor. I don't know the internals of Rust's async support at all, but presumably the future is queued up and exposes some kind of trait that…

I slightly mis-spoke in a sense, yeah. This stuff has changed a bunch over the last few years :) So, futures have basically two bits of their API: the first is that they're inert until the poll is called. The second is that they need to register a "waker" with the executor before they return pending. So it's not so much that the executor needs to know details about how to do the polling; but the person implementing s…

> And executors don't need to know these details, they just need to call poll at the right time, and in accordance with their wakers.

Is this true? Essentially this is claiming that an executor does not need to use mio (epoll/kqueue/...) to be able to execute futures that do async network i/o.

So who uses mio? Would each type implementing the Future trait use mio internally as a private detail? That is, using two such future types, would they maintain multiple independent kqueues and the executor isn't able to put them both in one?

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

#206

Post by steveklabnik » Sat, Aug 17, 2019, 2:20 PM UTC

fluffything wrote: post #205

steveklabnik wrote: post #199

Earlier quoted context omitted.

I slightly mis-spoke in a sense, yeah. This stuff has changed a bunch over the last few years :) So, futures have basically two bits of their API: the first is that they're inert until the poll is called. The second is that they need to register a "waker" with the executor before they return pending. So it's not so much that the executor needs to know details about how to do the polling; but the person implementing s…

> And executors don't need to know these details, they just need to call poll at the right time, and in accordance with their wakers. Is this true? Essentially this is claiming that an executor does not need to use mio (epoll/kqueue/...) to be able to execute futures that do async network i/o. So who uses mio? Would each type implementing the Future trait use mio internally as a private detail? That is, using two suc…

mio is useful when you’re writing an application that runs on windows/Linux/Mac. But you can use futures on any platform, including embedded ones. Those would be coded against whatever API the system offers. There’s an embedded executor, for example.

Tokio uses mio to implement its futures that do async IO, so if you use Tokio, you use mio. You don’t have to use Tokio, though it is the most popular and most battle tested.

Many futures don’t do IO directly; for example, all of the combinator futures. Libraries can be written to be agnostic to the underlying IO, only using the AsyncRead/AsyncWrite traits, for example.

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

#207

Post by andrewflnr » Sat, Aug 17, 2019, 2:22 PM UTC

steveklabnik wrote: post #148

andrewflnr wrote: post #145

Earlier quoted context omitted.

Same here. Rust code tends to be dense. It has its moments, but I wouldn't compare it to a scripting language.

I'm sitting in a Rust talk at a conference right now, and the speaker has slides comparing the syntax to Ruby/TypeScript/Python. "You already basically know Rust" A lot of the fancier stuff is very different, but there's fairly close parallels to most of the basic syntax.

Basically everything Algol-descended has close parallels in the syntax. That falls apart as soon as you hit a turbofish. I'm not saying the language or even the syntax is bad, but I think it does earn its reputation for being a little hard to read.

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

#208

Post by bsaul » Sat, Aug 17, 2019, 2:57 PM UTC

littlestymaar wrote: post #198

lenkite wrote: post #169

Earlier quoted context omitted.

Yes, the idea is that the thread that is executing this piece of code can "steal" other work when it is awaiting on either of those methods. Frankly, in the case of sequential flow like the above, I would rather write result = server.getStuff() second = server.getMoreStuff(result+1) print(result) and have the runtime automatically perform work-stealing for me. No need for awaits. They just litter the code. This is wh…

In Go you need to manually tell the runtime to spawn a goroutine with the `go` keyword, which also «litter» the code…

Except in practice, go keyword is used much more coarsly and sparingly because you can group all the block of function calls under one big go call. With async, every single function has to be flagged as beeing asynchronous and be called differently ( although maybe some modern languages have a way to group all the await calls ?)

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

#209

Post by rough-sea » Sat, Aug 17, 2019, 3:07 PM UTC

ShinTakuya wrote: post #203

limsup wrote: post #170

It looks great. But it's odd that they do not cite Tokio. I know this isn't an academic paper, but come on have some professional curtesy and discuss the contributions made in prior art.

Apologies if I'm misunderstanding things here, I'm just now getting back into Rust after a couple of years of not using it. Did Tokio really inspire this library that much?

Absolutely. The whole std::future interface has been borne out of years of careful attempts to actually make these abstractions work in real life. async-std didn’t come from a vacuum. It’s a incremental improvement on tokio that benefits from being able to greenfield on top of the newly changed and standardized future trait.

Carl Lerche and the rest of the Tokio contributors deserve a citation.

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

#210

Post by enlyth » Sat, Aug 17, 2019, 3:27 PM UTC

hathawsh wrote: post #81

rammy1234 wrote: post #58

Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?

Rust is very ambitious and unusually successful at reaching its ambitions. It's efficient like C/C++, but safer. It's modern like Go, but more expressive and open to metaprogramming. It's often as readable as a scripting language, but doesn't depend on garbage collection. It's a young rising star originating from a great company.

> often as readable as a scripting language

Rust code is littered with things like |_|, (|&(&x, _), &mut, &'a and Result>.

It's anything but easily readable.