Second Draft: Coroutines

[Jin]

On Friday, 24 January 2025 at 04:32:21 UTC, Mai Lapyst wrote:
> I think you have a misunderstanding (or mutliple here). Nobody 
> here want's to take away threads or fibers from the language.

This is not the first day in programming and, unfortunately, I 
know perfectly well how the Overton window works:
- No one will suffer from another feature X. Do not want to - do 
not use.
- Here you have a new API / library, but it is available only 
through X. Please rewrite part of your code through X.
- There are too many crutches for X in the code. In order to get 
rid of them, you need to rewrite your entire code on X.
- X is actively supported, while the “outdated” mode of operation 
is drowned in problems that have not been repaired for years, 
some of which appeared during the implementation of X.
- At some point, the code without X simply stops working and you 
have no choice completely left. See the example: 
https://www.npmjs.com/package/fibers

> Benchmarking is always only as good and usefull when used in 
> the right environments. I can easily create benchmarks that 
> also show how "slow" fibers are and how "fast" async is, as 
> well as otherwise.

When the smart indicates the problem, the fool looks at the 
finger.
Asynchronous function can not be inlined at the place of use and 
use a faster allocation on the stack. Benchmark only shows that 
even the coolest modern JIT compilers are not able to optimize 
them.

> Just go ahead and try re-implementing it with fibers or OS 
> Threads where every call to `fib(n)` spawns a new thread and 
> joins it. I think anyone would agree that thats just insane 
> waste of performance, which it rightfully is! Nobody in their 
> right mind would try to calculate it in parallel because its 
> still only a "simple" calculation.

You either decisively do not understand what you are talking 
about, or do intentional demagogy. Both options do not honor you. 
Where one single fiber will have a dozen fast calls and the 
optional one yield somewhere in the depths, with async functions 
you will have a dozen slow asynchronous calls, even if no 
asynchrony (for example, because caching) will not be required.

> This need only arises from poorly used global variables / 
> "impure" code, as the example you reference very good 
> demonstrates;

Any useful code is not pure. You either did not understand the 
problem that AsyncContext solves, or did not try to understand. 
Global (or rather Thread/Fiber Local) variables are used for 
special programming techniques that allow you to write a simpler, 
more reliable and effective code. I will not carry out a lecture 
on reactive programming, logging in exceptional situations and 
tracking user actions. See this series for example: 
https://dev.to/ninjin/perfect-reactive-dependency-tracking-85e
Concurrent access to variables with multi-threading has nothing 
to do with it.