Hello Bilge! > Is it really necessary to have all these `Async\launchScheduler();` calls? Why can't the scheduler always be running, the same as it is in JavaScript or any other async language? Even (userland) Revolt does not require the event loop to be manually started.
*Short answer:* This implementation is simpler — not so much in terms of code size but in terms of reducing сonfusion. And we achieve a consistent state when asynchronous code runs within a Fiber, rather than having a situation where we are in a Fiber here but not there. For example, consider how the Fiber switching mechanism works in PHP. If FiberB is launched from FiberA, FiberB can only return to FiberA. Consequently, if the Scheduler component is placed inside a Fiber, the code must track the "direction" of switching. Running the Scheduler in the "zero" Fiber results in the simplest possible switching logic. It also defines a clear point where exceptions can be thrown. One might argue that no other language does it this way. But then, no other language has Fiber as a low-level tool (except C). From this perspective, explicit activation of the Scheduler aligns with Fiber as a low-level construct. Can this be avoided? Yes, but such alternative approaches often rely on *implicit behavior*. And implicit behavior tends to break things. Of course, we could start the code inside a Fiber to initialize the Scheduler and hide the implementation, but again, that's not always necessary or useful for everyone. Ed.
