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

131–140 of 392 posts

Re: Async-await on stable Rust

#131

Post by nemothekid »

mamcx wrote: post #112
pcwalton wrote: post #103

Earlier quoted context omitted.

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.

> If you don't want to deal with async functions, then you can use threads! Truly? If some very popular lib become async (like actix, request, that I use), I can TRULY ignore it and not split my world in async/sync?

Both actix and reqwest are already async, the fact that you haven't noticed yet just shows that you are already ignoring it.

Re: Async-await on stable Rust

#132

Post by weberc2 »

jayd16 wrote: post #116
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…

Isn't this the most convenient setup though? I'm most familiar with async/await in UI programming and you most often have a main thread for synchronization. You want to assume that most of your main thread work is synchronous and non-yielding until you explicitly yield. Seems like it would be a lot harder to use main thread synchronization in the style your suggesting. Maybe I just can't imagine it. Whats a good lang…

Not the OP, but Go doesn't have this problem because all I/O is async under the hood, but it exposes a sync interface. This means the entire Go ecosystem is bought into a single concurrency model and runtime, which some find irksome, but it works pretty well most of the time. Of course, Go also lacks Rust's static safety features, but I think that's orthogonal to its concurrency approach.

Re: Async-await on stable Rust

#133

Post by naasking »

vanderZwan wrote: post #114
Rusky wrote: post #100

Earlier quoted context omitted.

It's not the same, but Rust async/await tasks are also in the order of bytes, and you can get similar "structured concurrency"-like control flow with things like `futures::join!` or `futures::select!`. Ceu looks very neat, I suspect (having not read much about it yet) that async codebases could take a lot of inspiration from it already.

> you can get similar "structured concurrency"-like control flow with things like `futures::join!` or `futures::select!`. That sounds very promising, I should give it a closer look (I don't program in Rust myself so I only read blogs out of intellectual curiosity)

Or you can use something like protothreads or async.h [1] if you're stuck with C/C++ and need something lightweight.

[1] https://news.ycombinator.com/item?id=21033496

Re: Async-await on stable Rust

#134

Post by weberc2 »

jstimpfle wrote: post #117
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 believe will make rust pretty much the easiest low-level platform to develop for. This stuff is easily available for C. It's just a function call instead of syntactic sugar. On Windows, use Fibers. On Linux, there is a (deprecated) API as well (forget the name). Or use a portable wrapper library. Or just write a little assembly. Can't be hard.

Can't tell if you're trolling or not.

Re: Async-await on stable Rust

#135

Post by phamilton »

bluejekyll wrote: post #129
phamilton wrote: post #120

Earlier quoted context omitted.

I am waiting for a language to solve this with the type system and compiler. Give me the ability to mark a thread as async only and a clean (async) interface to communicate with a sync thread. If my async code tries to do anything sync, don't let it compile.

Sorry, how is Rust not that language? You can use single threaded executors that only require Send and not Sync on data being executed on.

Does the compiler prevent me from calling a library that calls a library that performs a sync action?

Re: Async-await on stable Rust

#136

Post by stbuehler »

epage wrote: post #15
takeda wrote: post #7

Earlier quoted context omitted.

Why would it be different for async code than sync code? The goal of Rust's checker is to track lifetime of an object so for example it knows that at the end of a function the object should be freed. Async shouldn't matter here.

The challenge with async code is that the state across yield points is put into a struct and if a reference to a stack variable is used across yield points, then that struct is self-referential which Rust can't reason about (yet?). I honestly do not know who much can be recreated with `unsafe` and `Pin` vs how much is built-in. I'd love for Rust to eventually get a Move trait (something like C=+ move constructors) to…

That is exactly what `async` blocks are about: they do support self-referential structs, and `Pin` is what allows us to use those in a safe way, as `Pin`ned data can't be moved again (unless the data is `Unpin`, which self-referential structs are not), so the self-references are safe.

Re: Async-await on stable Rust

#137

Post by pgt »

littlestymaar wrote: post #127
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…

> Programming languages have the power to implement concurrency patterns that offer the same kind of performances, without the hassle. Can you give one that reaches this goal? Go is often cited on that regard but it doesn't really fit your description since it trades performance for convinience (interactions with native libraries are really slow because of that) and still doesn't solve all problems since hot loops ca…

Clojure's pmap function (parallel map) is pretty cool: http://clojure.github.io/clojure/clojure.core-api.html#cloju...

Re: Async-await on stable Rust

#138

Post by bluejekyll »

phamilton wrote: post #135
bluejekyll wrote: post #129

Earlier quoted context omitted.

Sorry, how is Rust not that language? You can use single threaded executors that only require Send and not Sync on data being executed on.

Does the compiler prevent me from calling a library that calls a library that performs a sync action?

No, but if that library claims to be an async library, wouldn't that be a bug in the library?

Edit: I'm interpreting your use of sync here as "blocking" and not as Sync in Rust, meaning safe to share across threads. To be clear in my initial response I was talking about shared memory across threads, and may have misunderstood your original statement.

Re: Async-await on stable Rust

#140

Post by eximius »

phamilton wrote: post #135
bluejekyll wrote: post #129

Earlier quoted context omitted.

Sorry, how is Rust not that language? You can use single threaded executors that only require Send and not Sync on data being executed on.

Does the compiler prevent me from calling a library that calls a library that performs a sync action?

What is a 'sync action'?

Async is fundamentally cooperative multitasking. There is no real difference between the 'blocking'-ness of iterating over a large for-loop and doing a blocking I/O action - the rest of your async tasks are blocked either way while another task is doing something.

Post reply on HN