Hacker News Reader

Comment by bruce343434 | Hacker News Reader

What I don't understand is why these functions must be declared async at the function declaration site. Why not allow the programmer to run any expression asynchronously, which wraps the return value of the expression in a future or promise or what have you?

    let promise = async {something+someother();};
    // other computations
    let result = await promise;

You'd essentially be creating a very ergonomical shortcut to fork-join multithreading which is infinitely more powerful and expressive than whatever this "async function" stuff is.

ETA: perhaps it would be a good idea to have a thread-unsafe keyword, though I'm not sure if rust needs that since rust has a really stringent resource pointer/reference aliasing guarantee.

ETA2: I misunderstood async semantics for rust, it's not a fork/join but send/poll. In any case, I still think you should be able to declare async at the call site, not the function site. That doesn't seem to clash.

View on HN

The reason to mark a function as async (in today's Rust) is that you want to `await` something within it.

If a function does this, it must be async- there's no other way to implement it. If a function does not do this, there is no reason to make it async in the first place- it will never suspend. (Things get uglier when it may or may not need to await something, e.g. if it accepts a closure parameter. Rust doesn't really handle this today, but one approach would be to make the function polymorphic over async-ness- this is similar to but not really the same as what it sounds like you're talking about.)

Async functions are for language-level cooperative multitasking, not concurrency per se. The difference between fork/join (what you imagined async to be) and what it actually is, is more than an implementation detail- it's a semantic change to how the program behaves. If you want to make something happen in the background at the call site, there are already ways to do that, they're just not spelled "async fn."

But what's the difference between an async function returning int, and a function returning `impl Future<int>`? If there's no difference why do we need the async keyword?

Other parts of the language are conditioned on the return type. For example the ? operator only works if the return type is Option or Result. It seems like `await` could inspect the return type in the same way.

> But what's the difference between an async function returning int, and a function returning `impl Future<int>`? If there's no difference why do we need the async keyword?

No difference, but while the feature was being explored early users found it simpler if they didn't need to think about lifetimes on the returned future. Sometimes sugar is just sugar; same reason that `for` loops exist instead of just using `while`.

You can't await inside of a function returning impl Future<Int>. (You can inside an async block inside one, but there you go with language-level support again.)

You need the collaboration with the compiler to make it all work well. And that means keywords and language-level infrastructure. We tried no sugar, and it was rough: http://aturon.github.io/tech/2018/04/24/async-borrowing/

(And a proc macro didn't work out either)

The difference between `await` and `?` is that the former completely transforms the entire function body containing it, while `?` just conditionally returns from it. (There's less of a difference to the caller of the function, where both `async` and `impl Future` give you a `Future` object.)

A normal function returning `impl Future` has normal synchronous control flow, cannot ever use `await`, and then eventually returns a value whose type implements the Future trait. You can't just return an int, because ints don't implement `Future`- you have to return something that is `poll`-able.

On the other hand, an `async fn` merely looks like it has normal synchronous control flow, with some `await`s sprinkled in. But when you call it, none of that code runs- instead it immediately constructs and returns a value (of anonymous type, similar to a closure) whose type implements `Future`. The code written in the body has its control flow ripped apart at `await` points, much like a CPS transform, and it goes in the `poll` method of that value's `Future` impl.

It's technically possible that the language could have been designed the way you describe- if an `await` is present, that transformation happens, otherwise it doesn't. But because of the nature of the `await` operator, this is much messier than `?`. For example, when the transformation happens, you need to be able to return an `int`, and when it doesn't you must return an `impl Future`, unlike `?` where you always have to return a `Result` or `Option` regardless of your use of `?`. And you wouldn't be able to tell at a glance whether the function body runs immediately when it's called, or whether it waits for the Future to be `poll`ed. Plus, the language also has `async { .. }` blocks that do the same transformation in an expression context, so it's kind of nice to be consistent with that.

> You'd essentially be creating a very ergonomical shortcut to fork-join multithreading which is infinitely more powerful and expressive than whatever this "async function" stuff is.

But that would require starting other threads, which requires everything to be `Send + Sync`, has the overhead of multithreading, and can't be managed with any sort of scheduler (without platform-specific hacks). Unless you use green threads, and that's discussed in the article.

So what then is async? If there is no scheduling/preemption in executing an "async" function, it's not really "async", but rather synchronous. Is async just a new way to say "instruction reordering"? Or is async really just "*defer* until the last possible moment: await"?

edit to match yours: not sure what a "green" thread is.

In any case, if threads are not an option, an async may always be ignorable, after all, a program may not rely on the order of the execution of its threads/its preemption; that would be a race condition. Textbook definition.

As I see it, the fork/join model is very useful for "shingling" code paths that don't have to happen in sequence, but _could_ happen in parallel.

Final edit: nothing is otherwise stopping the implementer of async to add a pre-started threadpool to the runtime, with whatever configurable parameters one would want.

Post final edit: I think fork/join vs send/sync are just implementation details. But I respect Rust for going with send/sync, just that it doesn't change all that much in terms of the programming interface.

Async is running many tasks on many less threads, using polling.

See https://rust-lang.github.io/async-book/01_getting_started/02...

(but note that this doesn't mean busy-loop polling, while that will be used in "my first executor" tutorials, production executors don't call a future until it's ready to have more progress made via an event, often from an epoll/kqueue/iocp or similar mechanism.)

this sounds like a lot of overhead, though

Rather, Rust just makes this overhead explicit. Go, Node, etc do the same thing, but just hide what actually happens.

It is, relative to not doing it. But it's quite a lot less overhead than a native thread.

As opposed to what?

It's "compile this as a state machine such that when other futures are waited on internally by this function, store stack state in an anonymous struct that implements Future + Poll, and allow repumping when that Poll implemention says it's ready. This allows you to reuse the same stack when this async function is blocked"

This is possible pretty much with the syntax you wrote: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Of course you need a runtime to drive that future forward, so it's more:

    let result = runtime.block_on(future);

[edit: or if main() is async, I'm not sure if that's what you want to avoid: `let result = future.await;` https://play.rust-lang.org/?version=stable&mode=debug&editio...]

Wrapping sync in async is usually not so hard but usually an anti-pattern. In C# for example, if that synchronous work is long running, it might consume a thread in the shared thread pool and have side effects (starvation) elsewhere in the application.

I don't understand what you mean. What is to say that an async-fn is not long running? It can just as well consume a thread, right?

I may not follow you - but to expand what _(i believe)_ the GP comment said; any long running code - say a loop that spins for an hour, is bad in the async context, because that async thread is part of the runtime. Better to take those special cases and let the executor move the computation to a dedicated thread.

At my work i mix a lot of compute heavy work in an async context, and if i let this compute heavy stuff run on my async threads i'd potentially starve my runtime. Tasks wouldn't get woken up on time, etc.

right, but this isn't an argument against allowing arbitrary async expressions. I can make an async-fn that runs an infinite loop just as easy.

That's the point though - anything blocking the async thread is bad. If your loop is going to run for an hour, you'd put arbitrary yield points in it so that the executor can reliably call other tasks

Well I can only speak to C# really but...

The preferred pattern is to avoid long running tasks in the default thread pool as it's a shared resource. Long running tasks should be executed somewhere else, either some new thread pool or just a new thread or just don't use async and make it your caller's problem. The point is that you don't want to consume the limited shared resource.

In your case, what would happen? Would a new thread be created? Is it ok to use the default pool? Did the synchronous method writer even consider this? It's hard to say.

Now, does this need to be enforced by the language? No. Developers could simply append "_Async" to make it clear a method can be put on the default thread pool or not. That's still a form a coloring though. Even if you consider it a choice by the caller, it's still a color that needs to be determined and you never want to exhaust your default thread pool.

That said, there are other reasons why calling an async method should have different semantics than calling a normal sync method. Just saying that the "can use shared threads" aspect of async methods can probably live as a convention.

async things are (generally) cooperatively executed/scheduled/etc. they choose when to give up control and allow other things to run (`await x`). this is in contrast to threads / processes, which are done preemptively - the OS can say "stop doing that, do this", swap out the memory, and your thread basically can't do anything about it. (which is why there are thread priorities)

normal synchronous code never gives up control until it's done. so it'll block the cooperative/async scheduler until it finishes, whether it's maxing out the CPU or just waiting idly for a network request to respond. if there's anything else happening on that scheduler, it has to wait, which can lead to rather terrible behavior.

and last but not least: you generally cannot move async code between threads. async tends to imply you want same-thread concurrency guarantees, to avoid the cost of cross-thread mutexes and whatnot. so while you could in theory just interrupt an async scheduler and move it to a new thread, in practice that's not usually safe, so it isn't done.

you could build a system that allows jumping between threads though - that's essentially what green threaded languages do under the hood (like Go). which gives you a middle-ground of "nice thread-like semantics" but "nice async performance", but neither quite as good as a pure system in sometimes-important edge cases.

---

all that said, yes, you can just dedicate a thread to a single scheduler, run a synchronous func on it, and it has practically no additional cost over using a normal thread. but you have to choose to do that, it won't happen by default.

The answer is actually pretty dumb: functions are declared async at the declaration site because that's how C# supported legacy code.

Introducing a new keyword is a breaking change because existing code may have a variable with the same name. So `await` is a conditional keyword in C#, conditioned on whether the function is marked `async`. And other languages have since just copied that choice.

https://dotnetfiddle.net/JUE0Sy

That may have been C#'s rationale, but it wasn't Rust's rationale. Rust doesn't even strictly require the `async` keyword in a signature to define functions that work with `await`; `await` works by polling a future, and `async fn` is just sugar for defining a function that returns a future. In fact Rust does precisely what the parent suggests, and also offers `async {}` blocks as sugar for defining inline futures:

    fn bar() -> impl Future<Output = u8> {
        async {
            let x: u8 = foo().await;
            x + 5
        }
    }

Neat, I didn't know about the `async {}` feature.

I think it's obvious that Rust chose `async fn` for familiarity with other languages. As you say `async` is just sugar on the return type, so logically it should decorate that type, not the fn keyword. "async fn" is even misleading since the function itself returns synchronously (and immediately): it's the returned value where the async-ness lies.

So I think Rust's use and placement of `async` is for familiarity, which traces back to C#'s original choice. Not to say that's a bad rationale.

Admittedly I didn't follow any of the Rust async design discussions so I could be completely wrong about all of it.

> "async fn" is even misleading since the function itself returns synchronously (and immediately): it's the returned value where the async-ness lies.

You've got the causality backwards- it's the async-ness that causes it to return immediately. Async is primarily about the execution model of the entire function, and the return type is only changed in service of that model.

The course of the design discussions started without async or await, using library-based Future combinators. Async was introduced as a way to desugar control flow and move knowledge of Futures into the compiler for borrow checking reasons, not out of any intention to mimic C#.

You're quite correct, I hadn't thought of the fact that the transform and the return type were distinct. My mistake.

> I still think you should be able to declare async at the call site, not the function site

This is the big point. I'd love to see anyone put forth a concrete, valid reason why this couldn't be implemented, because as it stands, it appears that the function coloring problem is exclusively due to poor language design, rather than a technical limitation (where an example of a technical limitation would be escape analysis, which is hard).

I think the CPS attempt in Nim could do this

https://github.com/nim-works/cps

Explicit await and promise semantics are useful incase you want to, say, start multiple async calls instead of awaiting one and then the other. But ok, lets say you just want await to be implicit in some cases...

Do you actually want this? Currently, you can assume that a function will not change threads mid execution, and that that thread will also not be used to execute other things. Implicit yielding breaks that assumption. Cooperative multithreading becomes impossible because it's much hard to reason about when a method call will yield execution or not.

I wasn't proposing implicit async/await. I was proposing declaring those at the call site, instead of per function declaration.

Ironically escape analysis is the one thing Rust went above and beyond to solve in a novel way.

No, Rust did not solve escape analysis - it was designed to constrain valid programs to those for which escape analysis is trivial (as evidenced by unsafe Rust, which doesn't have those constraints, and yet has nothing else enabling escape analysis). That's like saying that "C solved type inference" - no, it just constrained you to write your types by hand, and then did some checking of them afterward.

Reply on news.ycombinator.com