Building a shared vision for Async Rust

Re:Building a shared vision for Async Rust by steveklabnik on Friday March 19, 2021 @11:29AM (#26514446)

Yes, in fact, you cannot even use async Rust without writing your own executor or bringing one in via a library. It is very, very much opt in. That was a hard constraint on the design.

However, I think what the parent is getting at is the feeling of the total package, not the technical details. If every library you want to use is async, you can't really "opt out" exactly, even if technically the feature is opt out.

[ Parent | on HN ]

Re:Building a shared vision for Async Rust by h0l0gr4ph1c on Monday March 22, 2021 @09:14AM (#26540315)

By opt in I mean I can opt in to using an executor if I want async. If I don't code still works and is might not be as performant.

Couldn't you have made another hard constraint to make async code work as normal if the programmer wanted?

[ Parent | on HN ]

Re:Building a shared vision for Async Rust by steveklabnik on Monday March 22, 2021 @09:17AM (#26540350)

An executor is required, in name or in spirit. Every async system has software that does this. Most language runtimes that do simply give you no choice in the matter.

[ Parent | on HN ]

Re:Building a shared vision for Async Rust by h0l0gr4ph1c on Tuesday March 23, 2021 @12:09AM (#26550999)

Rust is a language that does things different to other languages because it is a better way. I challenge you to do the same with Async. There is a different better way.

[ Parent | on HN ]