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

  • Guest
    Guest replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • Ilphrin
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • jacob
    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.
    Rust can't support real monads because it doesn't have HKTs to begin with. It is possible to kinda sorta recreate them using traits and associated types but that's far more cumbersome than async/await.

    Leave a comment:


  • Veto
    replied
    Originally posted by DoMiNeLa10 View Post
    Async await is pure cancer no matter the language.
    Well, asynchronous code, multitasking and low latency event handling is a tough problem no matter the language. Async/await is a solution that attempts to uphold an appearance of synchronous code while acting (somewhat) asynchronously, which probably makes a lot of sense for most people brought up on the algorithmic Turing model.

    Personally, I am a big fan of an explicit actor/state/event model - but that can be cumbersome to implement in most languages. I should probably seriously learn Erlang one day

    Leave a comment:


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

    Leave a comment:


  • Chewi
    replied
    Having easily implemented a new feature for hyper 0.13 with async-await being available and then struggling for a couple of days to backport it to 0.12 without async-await, I very much welcome this.

    Leave a comment:


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

    Leave a comment:


  • Guest
    Guest replied
    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.

    Leave a comment:


  • bug77
    replied
    This is absolutely awesome. Probably the most awaited (pun intended) feature in years.

    Leave a comment:

Working...
X