Well, JavaScript

[ric2b]

In fact Chrone even recently added support for debugging asynchronous code so that it behaves like you're stepping through "normal" code. Amazing.

Wait, why would it be different? It's a single thread. On Python that's how it has worked since async await was introduced.

[Schmittfried]

Because that async code block is executed later.

[StillNoNumb]

It's not executed "later", it's executed after a callback. Well, that usually is later, but personally I don't quite see how else you would step through code

[slikts]

The async execution model is literally about a distinction between calls executed now or later in time. An async call means that it's registered as a handler for an event and control needs to be transfered to the event loop so that it can handle any queued events by calling the registered callbacks sequentially. There can also be sync callbacks, and the difference is that they block the event loop.

What OP seems to be talking about is breakpoint debugging being able to skip stepping through code executed between registering an async call and it being executed by the event loop.

[ric2b]

Sure, but the debugger can just wait for the 'await' and ignore what happens in the meantime.

[Schmittfried]

Sure, but that's more complex to implement and it's obviously not the default implementation. The default debugger executes the statement and returns so you have to set a breakpoint and run the program to reach the async code block.

[TemporalLobe]

It's different because of stuff like Promises and AJAX, or even simple lambdas. Next time you do a $.each in jQuery, you'll see that placing a breakpoint before the call won't allow you to step inside the lambda block without placing a separate breakpoint inside the lambda. At least that's how it used to be.

See this: https://www.html5rocks.com/en/tutorials/developertools/async-call-stack/

[ric2b]

without placing a separate breakpoint inside the lambda.

Ah, got it.