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

Async-await on stable Rust

blog.rust-lang.org

Post reply on HN
Print view View original

101–110 of 392 posts

Re: Async-await on stable Rust

#101

Post by Analemma_ »

fooyc wrote: post #98

This is a big improvement, however this is still explicit/userland asynchronous programming: If anything down the callstack is synchronous, it blocks everything. This requires every components of a program, including every dependency, to be specifically designed for this kind of concurency. Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything a…

> Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything around the fact that a program uses async I/O, including things that have nothing to do with I/O, is crazy.

Microsoft kind of tried to do this with the new APIs for UWP: pretty much everything is async, the blocking versions of APIs were all eliminated, so there was no way for the async-ness to "infect" otherwise synchronous code. It was actually a pretty nice way to program; it's a shame it never took off.

Re: Async-await on stable Rust

#102

Post by steveklabnik »

MuffinFlavored wrote: post #99

For JavaScript developers expecting to jump over to Rust and be productive now that async/await is stable: I'm pretty sure the state of affairs for async programming is still a bit "different" in Rust land. Don't you need to spawn async tasks into an executor, etc.? Coming from JavaScript, the built in event-loop handles all of that. In Rust, the "event loop" so to speak is typically a third party library/package, no…

> I'm pretty sure the state of affairs for async programming is still a bit "different" in Rust land.

There are some differences, yes.

> Don't you need to spawn async tasks into an executor, etc.?

Correct, though many executors have added attributes you can tack onto main that do this for you via macro magic, so it'll feel a bit closer to JS.

Re: Async-await on stable Rust

#103

Post by pcwalton »

mamcx wrote: post #72
vanderZwan wrote: post #43

Earlier quoted context omitted.

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

The solution suggested by that article is to use M:N threading, which was tried in Rust and turned out to be slower than plain old 1:1 threading.

If you don't want to deal with async functions, then you can use threads! That's what they're there for. On Linux they're quite fast. Async is for when you need more performance than what 1:1 or M:N threading can provide.

Re: Async-await on stable Rust

#104

Post by larusso »

Dowwie wrote: post #83
Kaladin wrote: post #75

Earlier quoted context omitted.

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

https://rust-lang.github.io/async-book https://book.async.rs https://tokio.rs

Thanks for the links. But they are not clickable :)

Re: Async-await on stable Rust

#105

Post by gregwtmtno »

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…

I've dipped my toes into embedded rust from time to time. Can you give me an example or two of how you would use async/await in an embedded environment? I'm just curious about how it would work.

Re: Async-await on stable Rust

#107

Post by nicoburns »

Analemma_ wrote: post #101
fooyc wrote: post #98

This is a big improvement, however this is still explicit/userland asynchronous programming: If anything down the callstack is synchronous, it blocks everything. This requires every components of a program, including every dependency, to be specifically designed for this kind of concurency. Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything a…

> Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything around the fact that a program uses async I/O, including things that have nothing to do with I/O, is crazy. Microsoft kind of tried to do this with the new APIs for UWP: pretty much everything is async, the blocking versions of APIs were all eliminated, so there was no way for the async-nes…

The JavaScript world is pretty close to this. Not quite everything is async, but almost everything is async-first.

Re: Async-await on stable Rust

#108

Post by oconnor663 »

bullen wrote: post #86
littlestymaar wrote: post #56

Earlier quoted context omitted.

What do you mean by “on the same memory” exactly? If you want two threads running in parallel to concurrently access the same memory location you don't need synchronization if you only perform reads, and you need one if there is at least one write. Like in any other language (this comes directly from how CPU works). The good thing with Rust is that you can't shoot yourself in the foot: if you can't accidentally have…

I mean just like it reads: I want two (or more) threads to write the same memory at the same time. This is a problem Java "solved"/"worked around" with a complete memory model rewrite for the whole JDK and the concurrency package in 2004 (1.5). The solutions range from mutexes to copy-on-write and more.

My understanding is that Rust is basically equivalent to C in this regard, in terms of concurrent writes to the same memory being per se undefined behavior. I think the JVM translates concurrent memory writes into hardware-appropriate atomics, so maybe a better translation from Java to Rust would be a large `Vec` or something like that, rather than raw memory?

Re: Async-await on stable Rust

#109

Post by aashcan »

kodablah wrote: post #13

I've been working with alpha futures, tokio, hyper, etc with async/await support on rust beta (didn't use async std yet) and can attest to them working quite well. There was quite a learning curve for me to know when to use arc, mutex, different stream combinators, and understand raw polling, but after I did, writing the code became a bit easier. I suggest anyone wanting to learn to grab a tcp-level networking projec…

Could you share some resources? I'm trying to move a Hyper + Tokio-core + Futures project to the newer versions and am struggling..

Re: Async-await on stable Rust

#110

Post by adgasf »

ralusek wrote: post #65
grumpyprole wrote: post #47

Earlier quoted context omitted.

JavaScript automatically starts the tasks and this is bad design IMHO. One loses referential transparency and the ability to run the workflow with different schedulers. It looks like Rust has done a better job.

JavaScript does not automatically start the tasks. It executes the function if you...execute the function. If you just want to pass around something with deferred execution, you can just pass the function around, or wrap it in a closure.

It does automatically start the tasks. JavaScript asyncs are "hot". You can simulate "cold" asyncs using a function, as you describe, but in other languages this is how they work by default.
Post reply on HN