The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in.
That sums this discussion up nicely.
> The problem I see is the current async story is opt-out.
Surely this is only the case if you have picked asynchronous libraries to use?
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.
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?
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.
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.
Re:Building a shared vision for Async Rust
by h0l0gr4ph1c on Monday March 22, 2021 @07:58AM
(#26539598)
I actively choose libraries that are non-async. I don't want to use the programming model.
If aysnc could work like regular blocking code , if we want, and async code when you want, I think rust would be in a better place.
Just because you can do something doesn't mean you should.
The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in. As in, the code works regardless of an async runtime, async is added magic if you want it, but it will run like normal single threaded code if not.