Repository navigation
Async IO #1081
Description
Rust currently only includes synchronous IO in the standard library. Should we also have async IO as well, or leave that to an external crate? What would the design look like?
Moved from rust-lang/rust#6842
Related: #388
Activity
Valloric commentedon Apr 21, 2015
I don't see why this couldn't just remain in third-party external crates.
steveklabnik commentedon Apr 21, 2015
It can. Hence the 'community library' and 'libs' tags both.
Anachron commentedon Apr 22, 2015
Depends on who is actually maintaining the crate.
In my opinion it should be at least some from the core members as once async and sync are not on the same page anymore, it can lead to confusion of even worse, broken projects.
What I mean is this:
Once the community wrote async versions of the std, the community will make decisions on itself, whether something should be one or another way.
It will be hard to keep up-to-date and collaborateurs may not have digged into the core of Rust, though it will either go into a different direction or need someone to sync it with the syncronous version of the core.
josephglanville commentedon May 7, 2015
The problem with "leaving it up to third party crates" is not having a blessed implementation that all libraries can interoperate with.
This problem has already happened a few times now, namely Ruby and Python both have many competing and incompatible asynchronous IO libraries (gevent/twisted, celluloid/eventmachine).
In and of itself that doesn't sound so bad until you realise the huge amount of stuff that gets built on top of said libraries. When you aren't then able to use powerful libraries with each other because they belong to different "async" camps then things get sad pretty quickly.
Contrast this to C#, a language with built in async primitives, it also ships most of the higher level async integrated code (HTTP client etc). There is a single blessed solution and every library builds on top of it, they all interoperate and everyone is happy.
I think it's super important to have async IO in core or blessed in some way to avoid fragmentation.
m13253 commentedon May 9, 2015
But I think there should be language-level support for some key features that are important to async programming. That includes:
yieldstatement (though it originally makes an iterator, in async programming it is used to save current execution point and get back later)async/awaitstatement insteadYes we can already build a Node.JS-styled callback based async library -- that makes no sense. We need language-level support to build a modern one.
flaub commentedon May 14, 2015
I think it's important to distinguish between traditional async I/O from use cases requiring the standard C
select()API. I think that the existing synchronous I/O API is incomplete without the ability to cancel blocking calls. This doesn't seem to be robustly implementable without usingselect().I'd like to see the current synchronous I/O API extended to support cancellation without necessarily exposing the underlying
select. The goal here is not to provide a highly scalable or particularly efficient way of scheduling I/O requests, but merely a way to cancel blocking calls.gotgenes commentedon May 18, 2015
A minor correction to the "Python-styled" comment: it's technically
yield from– syntax introduced in Python 3.3. (But yes, it is still based on generators).Regarding
async/await, it's worth noting that this syntax was proposed for Python 3, and has been provisionally accepted for Python 3.5. PEP 492 lists a fair number of languages that have adopted or have proposed the async/await keywords. PEP 492 also does a fair job of describing the weaknesses of theyield fromapproach, as well as the advantages ofasync/await.Not that bandwagons are always the best reason to choose a direction, but
async/awaitwill become a very widespread idiom, and supporting it in Rust would provide great accessibility to those of us coming from other languages.Hear, hear!
ryanhiebert commentedon May 18, 2015
Being somebody familiar with Python and its async story, but not as familiar with compiled static languages, it would be helpful to me (and perhaps others) if somebody could comment on something that I'm familiar with from Python.
In Python 3.5,
asyncandawaitwill be based onyieldandyield fromcoroutines based on generators under the hood. This seems like a pretty elegant design to me, but I'd love to hear if there are any problems with that kind of approach.gotgenes commentedon May 18, 2015
From @nathanaeljones's comment on rust-lang/rust#6842:
Now, what is "expensive"? I'm not sure. (I'm in the same boat as @ryanhiebert. I program mostly in Python. I was made aware of Rust by @mitsuhiko's blog posts.)
lilith commentedon May 18, 2015
@gotgenes The expense depends on how much thread-local storage you're using. I know that it's low enough now that new APIs are async-only. This really depends on the language runtime (and the operating system); I don't think much can be learned about the performance implications by looking at other languages.
phaux commentedon Jun 30, 2015
Would be cool to have something like GJ in the core.
160 remaining items
chpio commentedon Oct 8, 2017
Yeap, Tokio is also just using futures. futures is the library at the heart of all async operations in rust.
https://github.com/alexcrichton/futures-await/blob/master/examples/echo.rs
Ixrec commentedon Oct 8, 2017
@c0b https://internals.rust-lang.org/t/help-test-async-await-generators-coroutines/5835 might be the best place to start if you're trying to use the async/await experiment currently on nightly.
leonerd commentedon Jan 19, 2018
If it's of any interest, I've been busy implementing this idea in Perl, and observing that Python, C#, JavaScript and Dart all also do basically the same thing.
Perl: https://metacpan.org/pod/Future::AsyncAwait
Python: https://docs.python.org/3/library/asyncio-task.html
C#: https://docs.microsoft.com/en-us/dotnet/csharp/async
JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
Dart: https://www.dartlang.org/articles/language/await-async
If you have something of an "official language overview" page similar to those above, I'd like to add it to my collection.
Centril commentedon Feb 24, 2018
Since discussion has moved on from here to tokio.rs, futures-rs, and other RFCs, I'll go ahead and close this issue.
janhohenheim commentedon Feb 26, 2018
@Centril I think it would be useful to link those issues for readers stumbling across this one. Do you happen to have them at hand?
Centril commentedon Feb 26, 2018
Not so much about directly adding async IO directly to the standard library but rather enabling as crates:
m13253 commentedon Feb 26, 2018
In reply to @Centril ,
This is what I (as well as some of us) are preventing from happening for years.
Some of us are actually preventing this move to third-party crates.
Lack of language-level async IO would cause incompatibility among third-party crates, as I have already stated before. Additionally, since Rust offers FFI, lack of language-level async IO would cause problems for C code to utilize concurrent programming.
In fact, nearly all languages have async IO. But only those who provide language-level concurrency (e.g. Go, Python 3, C#, etc.) may have more or less chance to win the "language for the cloud" battle. We all agree that Rust is a powerful language far more than the need to build a browser engine. But we don't want to see Rust losing the cloud battlefield, do we?
Really sorry if my language is offensive to you. But I disagree with your opinion that "we are relying on third-party crates". True concurrency requires implementations on compiler level that third-party crates cannot offer.
Update: Thank you for your response below. ❤️
Centril commentedon Feb 26, 2018
@m13253
note: I'm only describing things as they are, not as they ought to be. =) Anyone is free to file full RFC proposals for libstd / language level async IO and we will judge those on their merits.
Ixrec commentedon Feb 26, 2018
Note that "other RFCs" includes https://github.com/rust-lang/rfcs/blob/master/text/2033-experimental-coroutines.md, which basically is async/await syntax (albeit slightly less pretty since it's done with procedural macros for now). That seems like "language-level async IO" to me, even if it's not-so-secretly sugar over the futures library.
leonerd commentedon Feb 26, 2018
That's OK. It's surface syntax sugar over futures in Perl as well. :) Probably true of many languages
BatmanAoD commentedon Apr 25, 2018
@m13253 In case you hadn't heard, here are more up-to-date proposals: