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
Comments
Can someone explain what happens in Rust and Python? I don't see how C / ABC can happen (or what's even the point of async when that's the result).
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