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

181–190 of 392 posts

Re: Async-await on stable Rust

#181

Post by Matthias247 »

nicoburns wrote: post #107
Analemma_ wrote: post #101

Earlier quoted context omitted.

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

The javascript world was forced into this. Since it doesn't (or at least didn't) expose threads, everything had to be non-blocking. Otherwise programs would be non-responsive all the time.

Re: Async-await on stable Rust

#182

Post by Zelizz »

phamilton wrote: post #120
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…

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.

Aren't you effectively asking the compiler to solve the halting problem?

I think the best you could do would be heuristics - having inferred or user-supplied bounds on the complexity of functions, having rough ideas on how disk or network latency will affect the performance of functions, and bubbling that information up the call tree. It wouldn't be perfect, but it could be useful.

Re: Async-await on stable Rust

#183

Post by rightbyte »

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…

Is it a single threaded state machine?

Re: Async-await on stable Rust

#185

Post by kgraves »

pixel_fcker wrote: post #168
eeZah7Ux wrote: post #143

The level of fanboyism in the comments is saddening. Many other fast and productive languages have async since a while.

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.

Re: Async-await on stable Rust

#186

Post by bulldoa »

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…

> since hot loops can block a whole OS thread

Asking as a beginner, what does the above mean?

Not sure what does hot loop means, and why does it block Os thread

Re: Async-await on stable Rust

#187

Post by staticassertion »

bulldoa wrote: post #186
littlestymaar wrote: post #127

Earlier quoted context omitted.

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

> since hot loops can block a whole OS thread Asking as a beginner, what does the above mean? Not sure what does hot loop means, and why does it block Os thread

Hot loops are often "expensive", or where your program is spending a lot of its time.

If you're doing a hot loop, which may be synchronous, you will block the event loop attached to that OS thread, because a hot loop is presumably not yielding control until it is done.

Re: Async-await on stable Rust

#188

Post by staticassertion »

Zelizz wrote: post #182
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.

Aren't you effectively asking the compiler to solve the halting problem? I think the best you could do would be heuristics - having inferred or user-supplied bounds on the complexity of functions, having rough ideas on how disk or network latency will affect the performance of functions, and bubbling that information up the call tree. It wouldn't be perfect, but it could be useful.

Compilers can "avoid" the halting problem if the underlying language is not turing complete/ can express function totality.

You can even express algorithmic complexity in a language.

But it's a bit more complex than that, really. You will have a harder time saying "this loop will block the event system for longer than I'd like".

Re: Async-await on stable Rust

#189

Post by jabl »

jsiepkes wrote: post #130
littlestymaar wrote: post #127

Earlier quoted context omitted.

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

Erlang probably comes closest?

Not an Erlang user, but my understanding is that the Erlang VM (BEAM) schedules on function calls. Which works fine for that use, since Erlang does looping with tail calls, but is not a solution for procedural languages.

Re: Async-await on stable Rust

#190

Post by bulldoa »

staticassertion wrote: post #187
bulldoa wrote: post #186

Earlier quoted context omitted.

> since hot loops can block a whole OS thread Asking as a beginner, what does the above mean? Not sure what does hot loop means, and why does it block Os thread

Hot loops are often "expensive", or where your program is spending a lot of its time. If you're doing a hot loop, which may be synchronous, you will block the event loop attached to that OS thread, because a hot loop is presumably not yielding control until it is done.

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?
Post reply on HN