Rust 1.39 Released With Async-Await Support, Attributes On Function Parameters

[Guest]

It's all about implementing the same concept really and in my experience the solution that requires fewer lines of code usually wins. Even more so when the abstraction behind it is zero cost
I'll also take async/await over callback style any day

I see callbacks as a way to make scoping behave much more nicely, and have the possibility of reducing the stack size in the middle of an async operation.

[ssokolow]

Async await is pure cancer no matter the language. It makes code convoluting, error handling becomes flimsy and cumbersome. Implementing a proper monadic interface is the way to go.

Here's an in-depth exploration of the challenges involved in implementing monads for Rust, plus a potential avenue for achieving it. Enjoy.

https://varkor.github.io/blog/2019/03/28/idiomatic-monads-in-rust.html

I also recommend reading the Twitter thread it links to when it says "In fact, there are so many obstacles that some people express doubt that it’s even possible."

[kpedersen]

You must be kidding. Js have got async/await only recently. Async/await was invented because synchronous IO has disastrous performance. Node.js were outperforming Asp.net and MS had to do something, that is why they've invented sugar to hide callback chain behind pseudosynchronous code.

I more meant an asynchronous architecture in general. Those keywords are basically just syntactic sugar anyway.

For example, before async / await existed, Javascript in a web browser environment couldn't do synchronous IO. The only exception was a synchronous ajax request which most browsers didn't allow anyway and it has been deprecated.

Synchronous IO is still the *only* way that io can be performed underneath if you do not have proper multithreading (i.e JS web browsers). You just read in small chunks and poll. It only has disastrous performance if the developer doesn't quite have enough experience.

[[email protected]]

Agreed, it doesn't work well in game loops or other real-time systems.

It was only invented and became popular because of the limitations of web browser environments. If Javascript interpreters were correctly multithreaded from the start and didn't freeze the browser on a tightloop, callbacks calling callbacks calling callbacks would remain a niche clusterfsck left entirely to amateurs.

I have never used async/await, doing mostly system/embedded programming in C. There, you can have an event loop, and handle asynchronous computing trough a few synchronization primitives. But from what I've seen with rust, it's basically syntaxic sugar, and I am not sure there is a reason why the way it was implemented in rust would be incompatible with game loops and other real-time systems.

The way I got it, by way of a C analogy, would be with each "async" variable being a structure with a function pointer, as well as that function's parameters (not sure if any global scope is preserved as well), to be called at a later point. That, without the runtime overhead of such a structure. But I could be wrong, and I would actually like a primer for that feature written in those terms, if anyone has a few pointers?
Yeah, I should really take time to learn Rust properly one of these days...

[fuzz]

I have never used async/await, doing mostly system/embedded programming in C. There, you can have an event loop, and handle asynchronous computing trough a few synchronization primitives. But from what I've seen with rust, it's basically syntaxic sugar, and I am not sure there is a reason why the way it was implemented in rust would be incompatible with game loops and other real-time systems.

The way I got it, by way of a C analogy, would be with each "async" variable being a structure with a function pointer, as well as that function's parameters (not sure if any global scope is preserved as well), to be called at a later point. That, without the runtime overhead of such a structure. But I could be wrong, and I would actually like a primer for that feature written in those terms, if anyone has a few pointers?
Yeah, I should really take time to learn Rust properly one of these days...

It all comes down to type theory, even if we don't think about it that way in languages like C. Philip Wadler has a good talk (Propositions as Types) about the history of the written expression of logic and its correlation with programming languages. Much of it has been created by logicians and again separately by engineers. I think he refers to the field as informatics.

He is currently working on something called "Session Types"; a way of logically representing types in concurrent systems, if you will.

http://groups.inf.ed.ac.uk/abcd/

https://homepages.inf.ed.ac.uk/wadle...s-sessions.pdf

[Guest]

I more meant an asynchronous architecture in general. Those keywords are basically just syntactic sugar anyway.

For example, before async / await existed, Javascript in a web browser environment couldn't do synchronous IO. The only exception was a synchronous ajax request which most browsers didn't allow anyway and it has been deprecated.

Synchronous IO is still the *only* way that io can be performed underneath if you do not have proper multithreading (i.e JS web browsers). You just read in small chunks and poll. It only has disastrous performance if the developer doesn't quite have enough experience.

You could fake async stuff by splitting work up to smaller chunks and using something like timeouts to run these slices without completely locking up the event loop.

These days, multithreaded js in a browser is a thing with web workers. Applications like Google Maps are multithreaded, and you can just go there to check it yourself with dev tools in your browser.

[tajjada]

callbacks calling callbacks calling callbacks would remain a niche clusterfsck left entirely to amateurs.

async/await and futures in rust work differently from javascript and most other languages. Rust uses a poll-based rather than a callback-based model. You should read up on it. It is really cool and allows the compiler to optimize the whole thing down to a straightforward state machine (zero cost).

[oleid]

That's a lot of good news! I tried Rust when in was in beta, and that was painful but cool (I feel weird to say that), should give Rust another try now. Just need a project excuse to code in Rust

One needs to mention, that despite basic async/await stuff is now stable, edges are still rough. For once, error messages can be quite strange. That will surely improve given some time. Then, the ecosystem still has to catch up. Many crates are not updated to the new futures (from std, which async fn generates). I guess that will, however, improve till the end of the year. Once Tokio 0.2 is released, things will be more pleasant. Async-std (basically a direct port of the std library to async fn) is quite usable, however, it can still be a little bare.

[mmstick]

Async await is pure cancer no matter the language. It makes code convoluting, error handling becomes flimsy and cumbersome. Implementing a proper monadic interface is the way to go.

The way it's been implemented in Rust is virtually no different from writing traditional synchronous functions. Error handling is no different than before. The only difference between async and non-async code is the use of the `.await` postfix to begin execution of a future. Unless you start joining futures and spawning tasks, it will execute no differently than traditional synchronous code.

The below async code:

let mut buf = String::new();
File::open(path)
    .await
    .context("failed to open file")?
    .read_to_string(&mut buf)
    .await
    .context("failed to read file");

Is the same as the identical sync code, minus not being given a choice on how to await a result.

let mut buf = String::new();
File::open(path)
    .context("failed to open file")?
    .read_to_string(&mut buf)
    .context("failed to read file");

At least with async, you can poll many tasks simultaneously, instead of waiting for one task to complete before beginning the next.

[Khrundel]

Synchronous IO is still the *only* way that io can be performed underneath if you do not have proper multithreading (i.e JS web browsers). You just read in small chunks and poll. It only has disastrous performance if the developer doesn't quite have enough experience.

Synchronous code will always have a huge impact on performance. Even in theory, every thread which sleeps waiting some IO operation to finish is holding some amount of stack memory. Couple of thousand of such threads will waste gigabytes. In a real world thread switching isn't cheap, so there will be CPU time impact too. So, to achieve adequate performance, it has to be some explicit many request per one thread (from request's perspective it will be same asynchronous processing) or some nice abstraction such as futures and/or async/await.