10 ms·

Async Overloading

59 points by lukastyrychtr 5y ago

ioquatix 5y ago
> When designing an API in Rust which performs IO, you have to make a decision whether you want it to be synchronous, asynchronous, or both. Why must that be true? Why can't you write the interface once, and have concurrency be an implementation detail?
- vlovich123 5y ago
  Because async based APIs need to return a promise type of some kind (eg Future). You can kind of auto-generate wrapping code to convert synchronous to asynchronous (with some performance cost that may be undesirable) but you can’t generally do the reverse, unless you try to do funky things like pausing/resuming user space fibers (and then issues of lock inversions and things come into play there in a systems level language).
- monocasa 5y ago
  Because rust sync versus async colors the functions and how they're called.
- Kinrany 5y ago
  Ideally: 1. The compiler would be able to turn a subset of async code into sync code with no runtime cost 2. Awaiting would be the default, with `.await` deprecated and special syntax for getting a raw future instead That way most code would look the same regardless of being executed synchronously or asynchronously, with exceptions for evaluating multiple expressions in parallel and such. But #2 probably implies lazy evaluation semantics for all expressions!
- wahern 5y ago
  Because the design of async in Rust precludes that. Some of the details are leaky. For example, recursive functions require dynamic allocation in an async context because the async state must be statically sized. See https://rust-lang.github.io/async-book/07_workarounds/04_recursion.html https://rust-lang.github.io/async-book/07_workarounds/04_rec... There's no easy way to get around the function color problem unless you went the way Go did. But Go's choice made C ABI interoperability more complex. Rust chose simpler C ABI interop, at least for the sync case--no matter which choice you make neither approach makes async interop seamless. The fun part will be seeing how Rust integrates async and fallible allocation. Both of these issues you could see coming from 10 years away, and also see how they'd interact, but Rust devs decided to punt on some of these hard decisions early on. This sort of wheel reinvention is what you typically see in every new language, unfortunately, and you typically see them resolved in much the same way because solutions are path dependent on very early design decisions, and almost everybody makes the same early decisions. Except for Go. Go made the decisions it did because the designers had decades of language design experience, including decades of async experience under their belt. Rust designers came with a different set of experiences and goals, and this shows. (Not saying Go is better than Rust--in fact, non-fallible allocations was always a show-stopper for me in some critical niches. But Go made the most difficult decisions up front, and that included putting async first.)
  - steveklabnik 5y ago
    Rust did not punt on concurrency early on. The seventh word used in the first sentence ever describing Rust is "concurrent" http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf It even comes before "safe"! What did happen was that the ways in which concurrency was implemented changed as other design constraints on the language changed. But 1.0 wasn't released until we knew what the concurrency story for Rust would be, even if sorting out all of the details took a few years. "leaky" is in the eye of the beholder. Yes, if you think this should be abstracted, then it's a leak. But not everyone thinks that it should; many things about concurrent vs sequential are different, and Rust likes to expose certain kinds of costs and promises in the type signatures of functions. For its core audience, this is not a leak, this is giving you important information about the context the function should be used in.
    - wahern 5y ago
      > Rust did not punt on concurrency early on. Rust started with green threading/fibers then quickly rejected that approach. Then it spent years iteratively building an alternative solution, which is still underway. That's punting in my book; and it's punting for the majority of Rust aficionados who are surprised by the various twists and turns things take as the solution (as inevitable as it is) slowly materializes. By contrast, nothing of substance about Go async has ever changed, except perhaps the change in the default value of GOMAXPROCS. It was complete at conception. It wasn't a wrong decision that Rust made; it was just a choice. But 10 years out it's not entirely implausible that if Rust had stuck with fibers that it may have driven the required OS improvements (e.g. Google's User Managed Concurrency Groups (UMCG) Linux kernel patches) that would have resolved some of the issues. It's not like Rust has become ubiquitous in the embedded space either, considering that it's held back by LLVM in that regard. Something similiar happened with fallible allocations. Very early on most Rust devs declared that they believed that attempting recovery from allocation failure was folly (which in the land of GUIs from whence most of them came was the near universal opinion), and so shot down attempts to consider fallibility in the APIs.[1] Cue 10 years of slowly walking that back, with iterative (and still mostly pending) changes that were less than ideal owing to the fact that handling allocation failures is made infinitely more difficult if you don't take it into consideration at day 1. [1] And, no, it's not enough to say that Rust core is allocation agnostic, because setting aside that only a tiny minority of Rust programmers only stick to core, the decision involved setting idioms and practices surrounding panics.
- dathinab 5y ago
  It not possible with rust current abstractions you would need: - higher kind types / type constructors - some features to handle differences in the auto-traits depending on the result of the type constructor - some magic to resolves that --- - OR namespace overloading e.g. read_to_string$sync and read_to_string$async and magic to resolve that But async has A LOT of implications which change subtle things around handling it, like e.g. the handling of lifetimes/borrows, Send, Sync, etc. So this probably wouldn't be worth the complexity it introduces.
- ibraheemdev 5y ago
  Because synchronous IO functions block the current thread and return the value directly, while asynchronous function return a `Future`, which will eventually resolve to the value, and can be polled concurrently with other futures as to never block. fn sync_read() -> Vec<u8> { ... } fn async_read() -> impl Future<Output = Vec<u8>> { ... } // the second can be written more succinctly as: async fn async_read() -> Vec<u8> { ... }
wvenable 5y ago
I think you need a way to be explicit on which override you want to call. So in addition to the await and the implicit sync: do_something().await; do_something(); You also need a way to directly call the sync and async version: do_something().sync; // I really want the sync version do_something().async; // I want the Promise result
- shonenknifefan1 5y ago
  Agreed. Though, I think that in most contexts the compiler would probably be able to disambiguate which version is intended from type resolution. So maybe it would be better to be able to optionally specify whether we want the sync or async version, possibly overloading our usual polymorphic syntax, e.g. do_something().await; // Its clear that we're using the async version do_something::<sync>(); // I really want the sync version, even in async contexts
lalaithion 5y ago
I wish Rust would just make everything (that can be async) in the stdlib async, but also provide a simple primitive for "block the current thread on this async call", and guarantee that all of the stdlib functions that are async work when called with that primitive. Something like "block!(async_fn())" or "async_fn().block". Or even just allow non-async functions to .await, with the meaning of "block the world until this finishes running" What am I missing that makes this undesirable?
- ibraheemdev 5y ago
  That would mean a runtime in the standard library, which was explicitly rejected. Different runtimes have different pros and cons and different use cases, choosing one and putting it in the standard library means that all others are second class and probably not well supported. For example, some might want an io-uring based async runtime, while others want a runtime-per-core system for a web server, and another might want a simple lightweight runtime for an embedded environment. Someone else wants to use raw OS primitives without ever spawning a runtime (to use block_on and an async function that does IO, you still need a runtime running in the background). A better solution is to provide standard interfaces for runtimes and libraries to develop against, something that is being worked on.
- steveklabnik 5y ago
  There are a couple of different objections to this, though there is also a lot of support. The current state of it is "someone needs to write up an RFC." If you want the full gory details: https://github.com/rust-lang/rust/pull/65875 https://github.com/rust-lang/rust/pull/65875
  - ibraheemdev 5y ago
    Well that's just the "simple primitive for 'block the current thread on this async call'", which can, with the new `Wake` trait, be written in around 10 lines of code. The real change would be adding an actual runtime to the standard library.
    - 5y ago
dcow 5y ago
I like this proposal, a lot. I believe the prevailing languages of the next decade will solve the colored function problem not by removing colors but by integrating the concept into the syntax so as to achieve the appearance thereof. In other words: make calling either one a simple matter of context which the compiler should carry 99% of the time and the user should only worry about when there's a reason to do so (when the compiler cannot infer or the alternate context is needed explicitly). If the user wants an async runtime, so be it. If the user has no need for one, that should work too. The magic will be in making this seamless so that neither camp feels left out.
- bsder 5y ago
  At this point, I'm pretty convinced that "async" in 10 years is going to be like "object oriented" is now. A gigantic dead end that we're barrelling down for the wrong reasons--in this instance because everything web must be Javascript and work around all its warts. Every time someone talks about async, they always forget that you need an Executor, and those executors always have problems because they don't have the boundedness of Javascript. Using Javascript means your executors can only fire on a very constrained set of events that are completely prescribed. The moment you use something like Rust, that assumption is out the window and now your executor can't just do a couple of sockets and some DOM things. It has to accommodate sockets, timeouts, message queues that might wakeup by getting a message from another threads, character file descriptor devices, a terminal screen refresh, a video card vertical blanking event, etc. In short, your Executor has to accommodate an infinite variety of events when using async outside of the bounds of Javascript. Effectively everybody has to write their own personal Executor the moment they do something other than an IP socket. That's not an "improvement" in programming. That's a step backwards.
  - eloff 5y ago
    I'm not certain you're wrong, but not for those reasons. There are still threads for all the long tail of synchronous operations. It's easy enough to do from Tokio or other async frameworks. However, the go approach of making async look like sync code is certainly much easier to write and read code for. I'm skeptical that async is really superior to that.
deathanatos 5y ago
What I wish articles like this would dig into, and why I think the problem is harder than first blush, is how to deal with the actual future values themselves. The audience here seems to be Rustaceans a bit more than "all programmers"; there's a quick into to "here's how Swift does X", which is nice, but how does Swift deal with future values? That is, it isn't an error to not immediately .await an async function in Rust. It is problematic to discard the future (to never await). But the real power of futures comes from the composability: timeout(some_async_op(), 30).await? The "synchronous context" example is thus particularly confusing, IMO; a Rustacean will look at that and ask "but what makes that context synchronous?" or "how does it know that I want the synchronous version of the function when nothing in the code indicates it?" timeout(some_async_op(), 30).await? └─────────────┘ is this a synchronous context? (we don't *want* it to be.) Apparently, Swift introduces a separate keyword: async let f = { some_async_func() } But it seems like all uses of "f" must be "await f", so it doesn't seem like it's really a future. (One could not, AFAICT, write "timeout".) There are some other stuff with tasks & task groups, so perhaps with that, but that's my reading budget for Swift for now… Also, > With the overload added, we can start suggesting fixes for errors like this too 2. For example: | help: try removing `.await` from the function call | 3 | async fn f() { 4 - do_something().await; 4 + do_something(); | I think f() in this example is supposed to be non-async.
- Arnavion 5y ago
  It's mentioned in the "Overloading existing stdlib functions" section. >One issue to be aware of is that unlike Swift we cannot immediately fail if a synchronous overload is selected in an async function. Rust's async models allows for delayed `.await`ing, which means we cannot error at the call-site. Instead we'll likely need to hook into the machinery that enables `#[must_use]`; allowing us to validate whether the returned future is actually awaited — and warn if it's not. Even though this is slightly different from Swift appears to do things, it should not present an insurmountable hurdle. It's a bit confusing that it mentions selecting "a synchronous overload" but then goes on to talk about it returning a future. I assume it means selecting "(what looks like) a synchronous overload".
deleted 5y ago
[deleted]
saghm 5y ago
This obviously doesn't change anything, but shouldn't the example imports in the first code block use `std::fs`, not `std::io`? The existing function in the standard library is `stf::fs::remove_file`
leshow 5y ago
I'm not much a fan of adding all these custom keywords to function signatures. I hate to use use the m-word, but it really seems we are dancing around how to express monadic concepts in the language. I should note that I don't really want monads in Rust, I like them in Haskell but I've never felt Rust really needed full HKT & monads. It just feels wrong to me that we might add more syntax to the language & fn signature for each of these discrete concepts. So we have async, now we add the 'default' fn "color" and the "try" fn color, more colors feels like the wrong way to solve this problem to me. I don't know the answer here it's just a sense I get... anyone else? I was really taken by carl's post on async and how they discussed how .await could be removed https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/ https://carllerche.com/2021/06/17/six-ways-to-make-async-rus.... If we're concerned about having "colored" functions, maybe this is the avenue we should be exploring rather than lifting all the different colors out of the type signature and into special keywords?
- steveklabnik 5y ago
  The reason you get that sense is that we as programmers are drawn to the idea that generic solutions are the correct ones, and that special cases are bad. A HUGE part of our disciple is about creating and then welding abstractions. However, as Alan Perlis famously said, “a programming language is low level when its programs require attention to the irrelevant.“ In general, Rust’s default stance is that these details shouldn’t be abstracted away, because they actually matter. This is the fundamental tension that exists here.

59 points by lukastyrychtr 5y ago

> When designing an API in Rust which performs IO, you have to make a decision whether you want it to be synchronous, asynchronous, or both. Why must that be true? Why can't you write the interface once, and have concurrency be an implementation detail?

vlovich123 5y ago
Because async based APIs need to return a promise type of some kind (eg Future). You can kind of auto-generate wrapping code to convert synchronous to asynchronous (with some performance cost that may be undesirable) but you can’t generally do the reverse, unless you try to do funky things like pausing/resuming user space fibers (and then issues of lock inversions and things come into play there in a systems level language).
monocasa 5y ago
Because rust sync versus async colors the functions and how they're called.
Kinrany 5y ago
Ideally: 1. The compiler would be able to turn a subset of async code into sync code with no runtime cost 2. Awaiting would be the default, with `.await` deprecated and special syntax for getting a raw future instead That way most code would look the same regardless of being executed synchronously or asynchronously, with exceptions for evaluating multiple expressions in parallel and such. But #2 probably implies lazy evaluation semantics for all expressions!
wahern 5y ago
Because the design of async in Rust precludes that. Some of the details are leaky. For example, recursive functions require dynamic allocation in an async context because the async state must be statically sized. See https://rust-lang.github.io/async-book/07_workarounds/04_recursion.html https://rust-lang.github.io/async-book/07_workarounds/04_rec... There's no easy way to get around the function color problem unless you went the way Go did. But Go's choice made C ABI interoperability more complex. Rust chose simpler C ABI interop, at least for the sync case--no matter which choice you make neither approach makes async interop seamless. The fun part will be seeing how Rust integrates async and fallible allocation. Both of these issues you could see coming from 10 years away, and also see how they'd interact, but Rust devs decided to punt on some of these hard decisions early on. This sort of wheel reinvention is what you typically see in every new language, unfortunately, and you typically see them resolved in much the same way because solutions are path dependent on very early design decisions, and almost everybody makes the same early decisions. Except for Go. Go made the decisions it did because the designers had decades of language design experience, including decades of async experience under their belt. Rust designers came with a different set of experiences and goals, and this shows. (Not saying Go is better than Rust--in fact, non-fallible allocations was always a show-stopper for me in some critical niches. But Go made the most difficult decisions up front, and that included putting async first.)
- steveklabnik 5y ago
  Rust did not punt on concurrency early on. The seventh word used in the first sentence ever describing Rust is "concurrent" http://venge.net/graydon/talks/intro-talk-2.pdf http://venge.net/graydon/talks/intro-talk-2.pdf It even comes before "safe"! What did happen was that the ways in which concurrency was implemented changed as other design constraints on the language changed. But 1.0 wasn't released until we knew what the concurrency story for Rust would be, even if sorting out all of the details took a few years. "leaky" is in the eye of the beholder. Yes, if you think this should be abstracted, then it's a leak. But not everyone thinks that it should; many things about concurrent vs sequential are different, and Rust likes to expose certain kinds of costs and promises in the type signatures of functions. For its core audience, this is not a leak, this is giving you important information about the context the function should be used in.
  - wahern 5y ago
    > Rust did not punt on concurrency early on. Rust started with green threading/fibers then quickly rejected that approach. Then it spent years iteratively building an alternative solution, which is still underway. That's punting in my book; and it's punting for the majority of Rust aficionados who are surprised by the various twists and turns things take as the solution (as inevitable as it is) slowly materializes. By contrast, nothing of substance about Go async has ever changed, except perhaps the change in the default value of GOMAXPROCS. It was complete at conception. It wasn't a wrong decision that Rust made; it was just a choice. But 10 years out it's not entirely implausible that if Rust had stuck with fibers that it may have driven the required OS improvements (e.g. Google's User Managed Concurrency Groups (UMCG) Linux kernel patches) that would have resolved some of the issues. It's not like Rust has become ubiquitous in the embedded space either, considering that it's held back by LLVM in that regard. Something similiar happened with fallible allocations. Very early on most Rust devs declared that they believed that attempting recovery from allocation failure was folly (which in the land of GUIs from whence most of them came was the near universal opinion), and so shot down attempts to consider fallibility in the APIs.[1] Cue 10 years of slowly walking that back, with iterative (and still mostly pending) changes that were less than ideal owing to the fact that handling allocation failures is made infinitely more difficult if you don't take it into consideration at day 1. [1] And, no, it's not enough to say that Rust core is allocation agnostic, because setting aside that only a tiny minority of Rust programmers only stick to core, the decision involved setting idioms and practices surrounding panics.
dathinab 5y ago
It not possible with rust current abstractions you would need: - higher kind types / type constructors - some features to handle differences in the auto-traits depending on the result of the type constructor - some magic to resolves that --- - OR namespace overloading e.g. read_to_string$sync and read_to_string$async and magic to resolve that But async has A LOT of implications which change subtle things around handling it, like e.g. the handling of lifetimes/borrows, Send, Sync, etc. So this probably wouldn't be worth the complexity it introduces.
ibraheemdev 5y ago
Because synchronous IO functions block the current thread and return the value directly, while asynchronous function return a `Future`, which will eventually resolve to the value, and can be polled concurrently with other futures as to never block. fn sync_read() -> Vec<u8> { ... } fn async_read() -> impl Future<Output = Vec<u8>> { ... } // the second can be written more succinctly as: async fn async_read() -> Vec<u8> { ... }

wvenable 5y ago

I think you need a way to be explicit on which override you want to call. So in addition to the await and the implicit sync: do_something().await; do_something(); You also need a way to directly call the sync and async version: do_something().sync; // I really want the sync version do_something().async; // I want the Promise result

shonenknifefan1 5y ago
Agreed. Though, I think that in most contexts the compiler would probably be able to disambiguate which version is intended from type resolution. So maybe it would be better to be able to optionally specify whether we want the sync or async version, possibly overloading our usual polymorphic syntax, e.g. do_something().await; // Its clear that we're using the async version do_something::<sync>(); // I really want the sync version, even in async contexts

lalaithion 5y ago

I wish Rust would just make everything (that can be async) in the stdlib async, but also provide a simple primitive for "block the current thread on this async call", and guarantee that all of the stdlib functions that are async work when called with that primitive. Something like "block!(async_fn())" or "async_fn().block". Or even just allow non-async functions to .await, with the meaning of "block the world until this finishes running" What am I missing that makes this undesirable?

ibraheemdev 5y ago
That would mean a runtime in the standard library, which was explicitly rejected. Different runtimes have different pros and cons and different use cases, choosing one and putting it in the standard library means that all others are second class and probably not well supported. For example, some might want an io-uring based async runtime, while others want a runtime-per-core system for a web server, and another might want a simple lightweight runtime for an embedded environment. Someone else wants to use raw OS primitives without ever spawning a runtime (to use block_on and an async function that does IO, you still need a runtime running in the background). A better solution is to provide standard interfaces for runtimes and libraries to develop against, something that is being worked on.
steveklabnik 5y ago
There are a couple of different objections to this, though there is also a lot of support. The current state of it is "someone needs to write up an RFC." If you want the full gory details: https://github.com/rust-lang/rust/pull/65875 https://github.com/rust-lang/rust/pull/65875
- ibraheemdev 5y ago
  Well that's just the "simple primitive for 'block the current thread on this async call'", which can, with the new `Wake` trait, be written in around 10 lines of code. The real change would be adding an actual runtime to the standard library.
  - 5y ago

dcow 5y ago

I like this proposal, a lot. I believe the prevailing languages of the next decade will solve the colored function problem not by removing colors but by integrating the concept into the syntax so as to achieve the appearance thereof. In other words: make calling either one a simple matter of context which the compiler should carry 99% of the time and the user should only worry about when there's a reason to do so (when the compiler cannot infer or the alternate context is needed explicitly). If the user wants an async runtime, so be it. If the user has no need for one, that should work too. The magic will be in making this seamless so that neither camp feels left out.

bsder 5y ago
At this point, I'm pretty convinced that "async" in 10 years is going to be like "object oriented" is now. A gigantic dead end that we're barrelling down for the wrong reasons--in this instance because everything web must be Javascript and work around all its warts. Every time someone talks about async, they always forget that you need an Executor, and those executors always have problems because they don't have the boundedness of Javascript. Using Javascript means your executors can only fire on a very constrained set of events that are completely prescribed. The moment you use something like Rust, that assumption is out the window and now your executor can't just do a couple of sockets and some DOM things. It has to accommodate sockets, timeouts, message queues that might wakeup by getting a message from another threads, character file descriptor devices, a terminal screen refresh, a video card vertical blanking event, etc. In short, your Executor has to accommodate an infinite variety of events when using async outside of the bounds of Javascript. Effectively everybody has to write their own personal Executor the moment they do something other than an IP socket. That's not an "improvement" in programming. That's a step backwards.
- eloff 5y ago
  I'm not certain you're wrong, but not for those reasons. There are still threads for all the long tail of synchronous operations. It's easy enough to do from Tokio or other async frameworks. However, the go approach of making async look like sync code is certainly much easier to write and read code for. I'm skeptical that async is really superior to that.

deathanatos 5y ago

What I wish articles like this would dig into, and why I think the problem is harder than first blush, is how to deal with the actual future values themselves. The audience here seems to be Rustaceans a bit more than "all programmers"; there's a quick into to "here's how Swift does X", which is nice, but how does Swift deal with future values? That is, it isn't an error to not immediately .await an async function in Rust. It is problematic to discard the future (to never await). But the real power of futures comes from the composability: timeout(some_async_op(), 30).await? The "synchronous context" example is thus particularly confusing, IMO; a Rustacean will look at that and ask "but what makes that context synchronous?" or "how does it know that I want the synchronous version of the function when nothing in the code indicates it?" timeout(some_async_op(), 30).await? └─────────────┘ is this a synchronous context? (we don't *want* it to be.) Apparently, Swift introduces a separate keyword: async let f = { some_async_func() } But it seems like all uses of "f" must be "await f", so it doesn't seem like it's really a future. (One could not, AFAICT, write "timeout".) There are some other stuff with tasks & task groups, so perhaps with that, but that's my reading budget for Swift for now… Also, > With the overload added, we can start suggesting fixes for errors like this too 2. For example: | help: try removing `.await` from the function call | 3 | async fn f() { 4 - do_something().await; 4 + do_something(); | I think f() in this example is supposed to be non-async.

Arnavion 5y ago
It's mentioned in the "Overloading existing stdlib functions" section. >One issue to be aware of is that unlike Swift we cannot immediately fail if a synchronous overload is selected in an async function. Rust's async models allows for delayed `.await`ing, which means we cannot error at the call-site. Instead we'll likely need to hook into the machinery that enables `#[must_use]`; allowing us to validate whether the returned future is actually awaited — and warn if it's not. Even though this is slightly different from Swift appears to do things, it should not present an insurmountable hurdle. It's a bit confusing that it mentions selecting "a synchronous overload" but then goes on to talk about it returning a future. I assume it means selecting "(what looks like) a synchronous overload".

deleted 5y ago

[deleted]

saghm 5y ago

This obviously doesn't change anything, but shouldn't the example imports in the first code block use `std::fs`, not `std::io`? The existing function in the standard library is `stf::fs::remove_file`

leshow 5y ago

I'm not much a fan of adding all these custom keywords to function signatures. I hate to use use the m-word, but it really seems we are dancing around how to express monadic concepts in the language. I should note that I don't really want monads in Rust, I like them in Haskell but I've never felt Rust really needed full HKT & monads. It just feels wrong to me that we might add more syntax to the language & fn signature for each of these discrete concepts. So we have async, now we add the 'default' fn "color" and the "try" fn color, more colors feels like the wrong way to solve this problem to me. I don't know the answer here it's just a sense I get... anyone else? I was really taken by carl's post on async and how they discussed how .await could be removed https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/ https://carllerche.com/2021/06/17/six-ways-to-make-async-rus.... If we're concerned about having "colored" functions, maybe this is the avenue we should be exploring rather than lifting all the different colors out of the type signature and into special keywords?

steveklabnik 5y ago
The reason you get that sense is that we as programmers are drawn to the idea that generic solutions are the correct ones, and that special cases are bad. A HUGE part of our disciple is about creating and then welding abstractions. However, as Alan Perlis famously said, “a programming language is low level when its programs require attention to the irrelevant.“ In general, Rust’s default stance is that these details shouldn’t be abstracted away, because they actually matter. This is the fundamental tension that exists here.