44 ms·
> 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?
by songqin 6y ago
> 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?
- steveklabnik 6y agoYes, 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.
- h0l0gr4ph1c 6y agoBy 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?
- steveklabnik 6y agoAn 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.
- h0l0gr4ph1c 6y agoRust 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.
- h0l0gr4ph1c 6y agoI 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.