Comment by dcow | Hacker News Reader

Comment by dcow | Hacker News Reader

Parent Full thread

I think you misunderstand my point slightly. Here’s the difference: in JS everything that needs to be async is actually marked async. So when you use a browser api or library function you know for certain. I agree I like that and want it for Rust. In Rust the standard lib is not async aware so it cant be used safely from async code, period. And tons of Rust code uses the stdlib and it’s not super practical to just not use it so you’re stuck asking whether something is safe to call from async code or not with zero help from the compiler. So we agree not having the compiler do this sucks.

(What I meant by partially skirting the colored function issue is that you don't have to call await on the result of a function if you dint want to. So you can call a blue function from a red function just fine and do stuff with the result. You just can’t await it. This adds back lots of flexibility that some async impls in other languages don’t allow for.)

> you can call a blue function from a red function just fine and do stuff with the result. You just can’t await it

By this do you mean you can choose between waiting for a value in a way that halts the entire rest of the runtime while it resolves and one that will attempt to perform other tasks while waiting for the resolution?

Essentially yes.

Any time you call an async function you get a Future. The future does not resolve until you await it. So you can call an async function from a non-async function normally and do things with the future. You just cant call future.await to yeild until the result is is ready unless you’re in an async context. You can ask the runtime to resolve the future if you want, but that’s a blocking call so it’s up to you to make sure it’s safe to block.

Oh, well that's exactly the same as JS. You can await it to get a value but you don't have to, you could instead fire-and-forget, batch it up over time and await them all later, or attach a function to run with the resolved value whenever it resolves while letting the current execution move along unhampered. If you don't want to `await` it, your function stays "red" or whatever.

The main difference between rust futures and JS promises is that rust futures don't get scheduled if you don't poll them (we high await does under the hood). Promises otoh get to run immediately and can run to completion even if you never touch the promise ever againt

You get the same with e.g. tokio::spawn, which runs the future concurrently and returns something that you can await and get the future's output. Or you can forget that something and the future will still run to completion.

Directly awaiting a future gives you more control, in a sense, as you can defer things until they're actually needed.

Reply on news.ycombinator.com