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.