I think it's down to them noticing that nothing is waiting for the result of the task and handling it differently?

C: if nothing is waiting for it, don't run it at all.

ABC: if nothing is waiting for it, wait for it when it's run.

But print is a side effect? Why would that be optimised away?

It's not that it's optimized away, it's that the authors have done a bad job translating their pseudo code into Rust etc.

In Rust, if you do not `await` a future, it does not run - so in their example where only C is printed, they must have translated this into some Rust code that does not await the call to print AB.

This is simply not something you would ever do in real life, and in fact the Rust compiler emits a warning if you create a future but do not await it.

A more "correct" approach would be to call `tokio::spawn` with the future to print AB. This would result in AB always being printed, usually in the order ACB, but with no hard guarantees on that order because of the semantics of the `sleep` call. (specifically, it will wait at least the amount of time specified, but possibly more)

nothing is optimized away, it's just not executed - e.g. the program including semantics of the language is just designed such that it is not executed.

e.g. for Rust/tokio printing B is skipped, because the process exits and cancels the future before the task can print B

That's what I thought. But then what is the point when no other async function is executed while the caller sleeps for 1 second (presumably, or is it ms?)?

how would one be executed when the function is explicitly waiting?

also it's an example to demonstrate the differences of async implementations of languages, not a excerpt of a production code base