Async-await on stable Rust • Hacker News Board

Re: Async-await on stable Rust

#231

Post by bulldoa » Thu, Nov 07, 2019, 9:39 PM UTC

cfallin wrote: post #192

bulldoa wrote: post #190

Earlier quoted context omitted.

hmm, why is that a bad thing, if your entire thread is synchronous shouldn't it technically be blocking? Or is OS thread the main thread?

The problem is that the async model is a form of cooperative multithreading, so if one computation runs for a long time without returning to the main event loop, it can increase the latency for responses to other events. E.g., if one HTTP request takes a long time to process, and many of the worker-pool OS threads are handling such a request, response time goes up for all the other requests. OS-level concurrency is p…

ah, that make sense, I think another user point out that spawning n goroutine does not actually spawn n physical threads but rather queue n task to m thread in the pool, so if we exhaust m thread, n-m task will be blocked.

Thanks for the explanation

I wonder what is the point where each trade off make sense (ie. what is consider heavy computation vs light computation, it probably is related to OS thread allocation time)

Re: Async-await on stable Rust

#232

Post by twodave » Thu, Nov 07, 2019, 9:40 PM UTC

ralusek wrote: post #30

Isn't it kind of a poor design choice that Rust will not actually begin execution of the function until `.await` is called? If I didn't want to execute the function yet, I wouldn't have invoked it. Awaiting is a completely different concept than invoking, why overload it? If you want to defer execution of a promise until you await it, you can always do that, but this paradigm forces you to do that. The problem is the…

Those don't actually execute simultaneously in Javascript, though. In Javascript, C# and I suspect Java, each usage of await generates a state machine that can _defer execution_. So while one function is blocked, another can continue to execute. The concept is the same in Rust, except in Rust a nested await does not generate a new state machine. The entire async operation just uses a single state machine.

The reason Rust does this is because its priorities are different than these other languages. Rust is built around zero-cost abstractions because it is intended to be as fast as possible while still safe. That's one of many reasons why Rust is considered a systems language and Javascript is not. They're for different things.

For more on how async in Rust works, I'd invite you to read the actual manual on the subject (linked from the announcement): https://rust-lang.github.io/async-book/06_multiple_futures/0...

Re: Async-await on stable Rust

#233

Post by jstimpfle » Thu, Nov 07, 2019, 9:40 PM UTC

weberc2 wrote: post #207

jstimpfle wrote: post #200

Earlier quoted context omitted.

What gives you doubts I'm serious?

Proposing asm and deprecated APIs, "just use a portable wrapper library" as though there are any such (good) libraries, type safety, etc.

The fact is, all "green threads" do is swapping between call stacks and call register sets. The call stack is usually just a register itself. How hard can it be to save a register and restore it later?

> as though there are any such (good) libraries

Win32 Fibers are extremely easy to use (and not deprecated). I used them once, it was a blast. I wrote a simple wrapper around them in less than 50 lines of straightforward code, exposing maybe a struct and 3-4 function calls. Never had any problems.

That makes writing your own little non-preemptive scheduler extremely easy as well. That might be as little as another 50-100 lines of code. So you get a lot of control at almost no price.

POSIX C has swapcontext() / setcontext() which must be pretty similar (although I'm not sure I've ever used it) and if I understand correctly it was only obsoleted due to a syntactical incompatibility with C99 or something like that...

The only problem here is that green threads are a little bit of an awkward computational model in many cases. But that's not a syntax problem.

Re: Async-await on stable Rust

#234

Post by jdance » Thu, Nov 07, 2019, 9:42 PM UTC

I have never used async/await and cant really understand it. Is it like coroutines in lua? It seems very similar. But I guess its not limited to one thread like lua? Whats makes it better then threaded IO? Losing the overhead of threads?

I like coroutines but thats mostly because they are not threads, they only switch execution on yield, and that makes them easy to reason about :)

Re: Async-await on stable Rust

#235

Post by pimeys » Thu, Nov 07, 2019, 9:44 PM UTC

maccam912 wrote: post #227

pimeys wrote: post #205

The same day as async/await hits stable, the next Prisma alpha is released and is the first alpha that's based on Futures and async/await. https://github.com/prisma/prisma-engine/ Been working with the ecosystem since the first version of futures some years ago, and I must say how things are right now it's definitely much much easier. There are still optimizations to be made, but IO starts to be in a good shape!

What is this? The Github repo doesn't offer a description.

Maybe the website tells more? https://www.prisma.io/

Basically we offer a code generator for typescript, migrations and a query engine to simplify data workflows. Go support is coming next.

Re: Async-await on stable Rust

#236

Post by kbenson » Thu, Nov 07, 2019, 9:46 PM UTC

vanderZwan wrote: post #43

ComputerGuru wrote: post #22

I’ve been playing with async await in a polar opposite vertical than its typical use case (high tps web backends) and believe this was the missing piece to further unlock great ergonomic and productivity gains for system development: embedded no_std. Async/await lets you write non-blocking, single-threaded but highly interweaved firmware/apps in allocation-free, single-threaded environments (bare-metal programming wi…

Have you ever heard of Esterel or Céu? They follow the synchronous concurrency paradigm, which apparently has specific trade-offs that give it great advantages on embedded (IIRC the memory overhead per Céu "trail" is much lower than for async threads (in the order of bytes ), fibers or whatnot, but computationally it scales worse with the nr of trails). Céu is the more recent one of the two and is a research language…

> Er... sorry, this may have been a bit of an inappropriate comment, shifting the focus away from the Rust celebration.

I think if it's interesting and spurs useful conversation, it's appropriate, tangent or not. I for one an thankful for your suggested links, they look interesting.

Re: Async-await on stable Rust

#237

Post by jeffdavis » Thu, Nov 07, 2019, 9:48 PM UTC

kgraves wrote: post #185

pixel_fcker wrote: post #168

Earlier quoted context omitted.

Or maybe there are just a lot of people who like using rust because it fits their use cases very well and are excited about the release of a big new feature that’s been in development for a long time?

>...because it fits their use cases very well and are excited about the release of a big new feature. a bit too excited. GP isn't wrong, Go pretty much has the same thing and I have never seen so much fanboyism for a single feature ever in my career. I don't get it, but that might be because I am a manager.

https://github.com/jeff-davis/postgres-extension.rs

See my example where a pure-rust postgres extension can start a background worker, listen on a port, and handle concurrent network requests, multiplexing them over a single backend calling a non-thread-safe internal postgres API.

That's possible because rust has no runtime to get in the way, it can use C structs natively and seamlessly, tokio offers the CurrentThread runtime (which doesn't spawn new threads), and a bunch of other details that need to be done right.

Try doing that in a pure-Go postgres extension.

Re: Async-await on stable Rust

#238

Post by [deleted] » Thu, Nov 07, 2019, 9:55 PM UTC

pimeys wrote: post #205

The same day as async/await hits stable, the next Prisma alpha is released and is the first alpha that's based on Futures and async/await. https://github.com/prisma/prisma-engine/ Been working with the ecosystem since the first version of futures some years ago, and I must say how things are right now it's definitely much much easier. There are still optimizations to be made, but IO starts to be in a good shape!

[deleted]

Re: Async-await on stable Rust

#239

Post by littlestymaar » Thu, Nov 07, 2019, 9:56 PM UTC

ralusek wrote: post #60

roblabla wrote: post #37

Earlier quoted context omitted.

In Rust, you can use a future adapter that does this: futures::join!(asyncTaskA(), asyncTaskB()).await See the join macro of futures[0]. The way it works is, it will create a future that, when polled, will call the underlying poll function of all three futures, saving the eventual result into a tuple. This will allow making progress on all three futures at the same time. [0] https://docs.rs/futures/0.3.0/futures/macr…

I don't like this at all. Having to rely on futures::join! means that I don't have the flexibility to control the execution of these things unless Rust adds that specific utility, right? In JS, for example, the `bluebird` library is a third party utility for managing execution of functions. You can do things like const results = await Promise.map(users, user => saveUserToDBAsync(user), { concurrency: 5}); And I pass…

In Rust, everything is in ‘user space’ since nothing is managed by the language itself, you have full control on how the Futures are executed. Even the executor (the “event loop” in js parlance) is a third party library. You can't get more control in js than what Rust gives you.

Re: Async-await on stable Rust

#240

Post by ClumsyPilot » Thu, Nov 07, 2019, 9:59 PM UTC

pimeys wrote: post #235

maccam912 wrote: post #227

Earlier quoted context omitted.

What is this? The Github repo doesn't offer a description.

Maybe the website tells more? https://www.prisma.io/ Basically we offer a code generator for typescript, migrations and a query engine to simplify data workflows. Go support is coming next.

Maybe, but you linked the repo and it don't even have link to the website, let alone a description.

Looks like a great project, best of luck.