Async Overloading

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

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.

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.

  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

If you want the full gory details: https://github.com/rust-lang/rust/pull/65875

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

    let res = async_fn().await?;

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"

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.

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

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.

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!

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

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

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