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

[phoronix]

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

Rust 1.39 is out today as the latest stable update for this popular programming language...

http://www.phoronix.com/scan.php?pag...-1.39-Released

[bug77]

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

[DoMiNeLa10]

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.

[kpedersen]

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.

[Chewi]

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.

[bug77]

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

[Veto]

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

[jacob]

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.

[Khrundel]

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.

[Ilphrin]

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