On Sat, Mar 8, 2025, at 14:38, Daniil Gentili wrote:
>
> > The async block as I'm picturing it has nothing to do with function colouring,
> > it's about the outermost function in an async stack being able to say "make sure the
> > scheduler is started" and "block here until all child fibers are either concluded,
> > detached, or cancelled".
>
> There's no need for such a construct, as the awaitAll function does precisely what you
> describe, without the need to introduce the concept of a child fiber and the excessive limitation of
> an async block that severely limits concurrency.
>
> There is absolutely nothing wrong with the concept of a fiber without a parent, or a fiber that
> throws an exception (or a cancellation exception) out of the event loop.
>
> A panic in a golang fiber surfaces out of the event loop (unless it is catched with a recover),
> just like an uncatched exception in a fiber surfaces out of the event loop: it makes no sense to
> severely limit concurrency with an async block just to handle the edge case of an uncaught exception
> (which can be handled anyway with an event loop exception handler).
>
> In general, I really don't like the concept of an async block the way it is presented
> here, because it implies that concurrency is something bad that must be limited and controlled, or
> else bad stuff will happen, when in reality, a fiber throwing an exception (without anyone
> await()ing on the fiber handle, thus throwing out of the event loop) is not the end of the world,
> and can be handled by other means, without limiting concurrency.
>
> Regards,
> Daniil Gentili.
As far as I can tell, the entire reason we are talking about this is because adding the event loop
changes the behavior of existing code. So we cannot "just turn it on".
I haven't seen an explanation of why this is the case, but that's how we got to this
point. We need some way to "opt in" to turning on the event loop.
— Rob