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