Live data from Hacker News

Async-await on stable Rust

blog.rust-lang.org

71–80 of 392 posts

Re: Async-await on stable Rust

#71
post #60

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…

It feels like you're complaining about things in the Rust language without taking the time to understand how the language idioms work. RTFM.

Additionally, you're making snarky comments about how you don't like how the base language doesn't handle something like JS...then reference a third party JS library. Base JS doesn't solve your 'problem' either.

To answer your question, async/await provides hooks for an executor (tokio being the most common) to run your code. You things like that in the executor.

https://docs.rs/tokio/0.2.0-alpha.6/tokio/executor/index.htm...

Re: Async-await on stable Rust

#72

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…

I also think async (the paradigm) is kind of weird in rust world. I agree with https://journal.stuffwithstuff.com/2015/02/01/what-color-is-....

Re: Async-await on stable Rust

#73

Earlier quoted context omitted.

Which executor do you use? Tokio is a bit heavy, no?

Not the parent, but I've been keeping my eye on https://github.com/Nemo157/embrio-rs

Not much doc at the github. Can you provide a quick overview?

Re: Async-await on stable Rust

#74
post #60

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…

The join macro is also implemented “in user space”.

Re: Async-await on stable Rust

#75
post #62

This is a major milestone for Rust usability and developer productivity. It was really hard to build asynchronous code until now. You had to clone objects used within futures. You had to chain asynchronous calls together. You had to bend over backwards to support conditional returns. Error messages weren't very explanatory. You had limited access to documentation and tutorials to figure everything out. It was a proce…

Is there any resources you could point to learn more about how to use this async programming with?

Re: Async-await on stable Rust

#76
post #71
post #60

Earlier quoted context omitted.

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…

It feels like you're complaining about things in the Rust language without taking the time to understand how the language idioms work. RTFM. Additionally, you're making snarky comments about how you don't like how the base language doesn't handle something like JS...then reference a third party JS library. Base JS doesn't solve your 'problem' either. To answer your question, async/await provides hooks for an executor…

I reference a third-party library to show that you have full control of this stuff in user-space. Implementing Promise.all or Promise.map in userspace is trivial.

I'm not complaining about things without taking the time to understand how the language works, I'm giving examples of things that don't seem possible based off of my understanding of how the language works...in hopes that someone will either clarify or accept that this is a shortcoming.

Re: Async-await on stable Rust

#77

Earlier quoted context omitted.

The library support's not quite there yet. But I'd bet on it being pretty good by the end of the year. A lot of popular libraries have async support on their master branches.

Agreed - just trying to temper expectations. I'd hate for new users to come in and be frustrated due to implied "completeness" of Async. While Async itself might be "complete", as a broad concept it really needs so much more to be end-user complete. Traits are a big one for me. Though, I've seen good things with the Async Trait Macro libraries. So hopefully those do good. It doesn't make this Async-Stable event any l…

It is a good idea to tempter expectations.

1) this is an MVP, some features like you mentioned are not yet implemented

2) the echosystem was preparing for this release but it will likely have a bit of churn until things settle down now that the feature is in stable

3) there was a lot of diagnostics work to make the feature minimally understandable when something is incorrect, but it will be a source of frustration because it's not as polished as other constructs that have had the benefit of several releases and us seeing how they were misused to have targeted errors. Some things are already tackled in the new beta, but I foresee a lot of work ahead of us.

Re: Async-await on stable Rust

#78

Earlier quoted context omitted.

Not the parent, but I've been keeping my eye on https://github.com/Nemo157/embrio-rs

Not much doc at the github. Can you provide a quick overview?

Not much I can say other than “an executor designed specifically for embedded.” I don’t do embedded dev myself, so it’s more of a curiosity thing for me than something that I can give you a lengthy explanation of.

Re: Async-await on stable Rust

#79
post #60

Earlier quoted context omitted.

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…

The join macro is also implemented “in user space”.

Thank you, so what is the syntax that is used in order to execute without awaiting? Do you create a thread for each?

Re: Async-await on stable Rust

#80
post #76
post #71

Earlier quoted context omitted.

It feels like you're complaining about things in the Rust language without taking the time to understand how the language idioms work. RTFM. Additionally, you're making snarky comments about how you don't like how the base language doesn't handle something like JS...then reference a third party JS library. Base JS doesn't solve your 'problem' either. To answer your question, async/await provides hooks for an executor…

I reference a third-party library to show that you have full control of this stuff in user-space. Implementing Promise.all or Promise.map in userspace is trivial. I'm not complaining about things without taking the time to understand how the language works, I'm giving examples of things that don't seem possible based off of my understanding of how the language works...in hopes that someone will either clarify or acce…

Rust and JS have very very different execution models. You can absolutely control how many futures are allowed to make progress at the same time fully in userspace. If you're joining N futures, and want to only allow M futures to make progress at a time, make an adapter that only calls the poll function of M futures at a time, until those futures call ready.

Rust gives you all the flexibility you need here. It might not be trivial yet because all the adapters might not be written yet, but that's purely a maturity problem.

The `join` macro does nothing magical. Go check out its implementation, and it will make it obvious how to implement a concurrency argument.

Post reply on HN