Async Overloading

[deathanatos]

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]

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".

[dcow]

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]

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.

[jayd16]

A major consumer of async needs those seams. You often need the coloring because in many situations you want explicit control of what will yield execution. You might want to hold on to a UI thread or a specific OS thread for interop. A choice of all sync or all async is not good enough either.

There might be some better syntax with scopes but Kotlin hasn't been able to do away with the off the UI thread problem.

I won't say we'll never solve it but I don't think the solution is here yet.

[wvenable]

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]

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]

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?

[Matthias247]

First and foremost that Rust is a systems programming language that shouldn't have any kind of implicit runtime.

If you run any implicit eventloop, that property would no longer be given.

Next, it wouldn't even be desirable for lots of applications. Async IO and functions are not necessarily be faster than synchronous operations - it might as well the opposite if you don't have a lot of concurrency. E.g. if you read from one blocking socket, you do a single `read()` syscall. Add async IO, and you need an additional `select/epoll_wait` call.

Then there is an actual cost for composing Futures which are large values on the stack, sometimes having to box them (since otherwise recursion won't work and dynamic dispatch will neither, etc). The latter might certainly be avoidable with a different kind of "async design" than what Rust currently has, but there will always be some tradeoffs.

[ibraheemdev]

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.

[dcow]

Because then you mess up all the other async tasks that would be spawned by the callee and possibly deadlock your program (without an async runtime in the stdlib).

If you're using `async_std`, right now you simply, explicitly, introduce the runtime:

    let fut = async_fn();
    let res = async_std::task::block_on(fut)?;

(pulling out the Future into fut is just illustrative, it can of course be a single line) instead of:

    let res = async_fn().await?;

So it's already pretty darn easy to do what you want.

Also, here's an easy way to make it feel like a keyword:

    use std::result::Result;
    use std::error::Error;

    use async_std::task::block_on as block;

    fn main() -> Result<(), Box<dyn Error>> {
        let fut = async_std::fs::read_to_string("./Cargo.toml");
        let file = block(fut)?;
        println!("{}", file);
        Ok(())
    }
    
    ---
    
    [package]
    name = "async-sandbox"
    version = "0.1.0"
    edition = "2018"

    [dependencies]
    async-std = "1.10"

One final thing to point out here is that, unlike some other languages, in Rust you can call any async function just like any normal function. The only thing that requires a runtime is resolving the returned future. So it's not so much that functions are colored but that resolving futures needs a runtime and there is none in the current standard lib.

[steveklabnik]

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

[pjmlp]

This is the approach Microsoft took with WinRT, and Google with Android, to force devs to go fully async.

It did not work that well, as not everyone is confortable in an async only world.

[vp8989]

Wouldn't you be using 2 threads for at least some of the duration of every instance of that? Seems like it would scale very poorly.

[leshow]

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-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]

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.

[saghm]

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`

[ioquatix]

> 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?

[wahern]

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_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.)

[Kinrany]

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!

[ibraheemdev]

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> { ... }

[dathinab]

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.

[vlovich123]

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]

Because rust sync versus async colors the functions and how they're called.