Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • cynical
    replied
    Originally posted by DoMiNeLa10 View Post
    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.
    Async/await is just sugar over promises to make them look synchronous, and promises are monads.

    Originally posted by kpedersen View Post

    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.
    This is clueless, the web is a completely different environment with different needs. Your biggest problem as a web developer is blocking I/O, so how does multithreading solve that? Are you going to make a new thread for every request? There is a reason Node is high performance despite being single-threaded. Btw, nested callbacks are not a thing in JS anymore.

    Leave a comment:


  • Khrundel
    replied
    Originally posted by kpedersen View Post
    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.

    Leave a comment:


  • mmstick
    replied
    Originally posted by DoMiNeLa10 View Post
    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:

    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.

    Code:
    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.
    Last edited by mmstick; 09 November 2019, 12:23 AM.

    Leave a comment:


  • oleid
    replied
    Originally posted by Ilphrin View Post
    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.
    Last edited by oleid; 08 November 2019, 03:48 PM.

    Leave a comment:


  • tajjada
    replied
    Originally posted by kpedersen View Post
    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).

    Leave a comment:


  • Guest
    Guest replied
    Originally posted by kpedersen View Post

    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.

    Leave a comment:


  • fuzz
    replied
    Originally posted by M@yeulC View Post

    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.


    https://homepages.inf.ed.ac.uk/wadle...s-sessions.pdf
    Last edited by fuzz; 08 November 2019, 02:26 PM.

    Leave a comment:


  • M@yeulC
    replied
    Originally posted by kpedersen View Post

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

    Leave a comment:


  • kpedersen
    replied
    Originally posted by Khrundel View Post
    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by DoMiNeLa10 View Post
    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.

    A pragmatic new design for high-level abstractions Monads (and, more generally, constructs known as “higher kinded types”) are a tool for high-level abstraction in programming languages1. Historically, there has been a lot of debate inside (and outside) the Rust community about whether monads would be a useful abstraction to have in the language. I’m not concerned with that here. You see, there’s a problem with talking about whether monads would be useful or not, and it’s this: there are a large number of design challenges to overcome to have any hope of implementing them at all — to the best of my knowledge, there currently exists no realistic (that is, practical) design for monads in Rust. In fact, there are so many obstacles that some people express doubt that it’s even possible. Strictly speaking, they’re a lot more than that, but we’re only interested in the programming angle here. ↩


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

    Leave a comment:

Working...
X