I think the article is... not being completely honest. To my simple mind, spawning a task but not awaiting it is undefined behavior. So, no wonder it does dif

I think the article is... not being completely honest. To my simple mind, spawning a task but not awaiting it is undefined behavior. So, no wonder it does different things in different languages / libraries. What creates the implementation difference is the side effect. Some runtimes may, legitimately, conclude that since the task hasn't been awaited, then it shouldn't run at all, and no side effects should happen. Other runtimes either lack this kind of sophistication, or believe that the side effect is the goal of spawning the task, and so they proceed to run it anyways. Other discrepancies between runtimes are explained by the non-deterministic nature of concurrency... They happen to be more predictable in a very simple program that happens to terminate before the unawaited task has a chance to complete, which is what creates such diverse answers. I imagine that if the program waited longer, then we'd see most if not all implementations print all of the A, B, and C, where C can be first, second or third, but B must follow A. Which is what you'd expect, if you are familiar with any async framework.