3 ms·

> Async I/O gives awesome performance No, it doesn't really. 'Async' is a strictly Python problem, due to the insanity of the GIL. Predictably, the Python solu

> Async I/O gives awesome performance No, it doesn't really. 'Async' is a strictly Python problem, due to the insanity of the GIL. Predictably, the Python solution to it is also insane. Why you have to turn a sane language like Rust into an insane one by cargo-culting a solution to a non-problem is a mystery to me. Oh well, good thing at least C++ hasn't dropped the ball.

dthul 7y ago
You are mixing up a lot of stuff here. - Asynchronous programming is completely orthogonal to Python - If you don't need it, don't use it. Rust without asynchronous functions still looks and works like before - By the way: welcome to C++20's coroutines
- otabdeveloper4 7y ago
  > - Asynchronous programming is completely orthogonal to Python Theoretically, yes. In practice, people are just copying Python mistakes word-for-word, in an attempt to score the "coolness" factor that async garnered in the Python community. (Never mind that the "coolness" came from solving a problem that doesn't even exist in other languages...) If you want to see what asynchronous programming would look like if it weren't copied from Python, look at the recent C++ proposal. > - If you don't need it, don't use it. Rust without asynchronous functions still looks and works like before The problem is that every Python library now comes in two versions, regular and 'async'. Even if you don't need or care about anything 'async'. I guess splintering your code base into two incompatible flavors is just the pythonic way of doing things? Now that the 2 vs 3 insanity is finally dying down, they needed to start a fresh one? Why is Rust trying hard to repeat these mistakes? > - By the way: welcome to C++20's coroutines That I already answered above.
iknowstuff 7y ago
It’s important to distinguish 3 categories of coroutine implementations: stackful, stackless-on-heap, stackless-as-struct. C++ is stackless-on-heap. Stackless-as-struct is essentially creating an anonymous type (ala lambda), used to save the data across suspension points. This is the approach taken by Rust for its async/await implementation. I believe there were declaration/definition and ABI concerns about this approach for C++: > "While it is theoretically not an insurmountable challenge , it might be a major re-engineering effort to the front-end structure and experts on two compiler front ends (Clang, EDG) have indicated that this is not a practical approach." So the short answer seems to be that due to technical debt on the part of existing C++ compilers and their "straight" pipeline, the front-end cannot anticipate the size necessary for some book-keeping information traditionally handled by the code-generator. I'll take Richard Smith's word on Clang.

dthul 7y ago

You are mixing up a lot of stuff here. - Asynchronous programming is completely orthogonal to Python - If you don't need it, don't use it. Rust without asynchronous functions still looks and works like before - By the way: welcome to C++20's coroutines

otabdeveloper4 7y ago
> - Asynchronous programming is completely orthogonal to Python Theoretically, yes. In practice, people are just copying Python mistakes word-for-word, in an attempt to score the "coolness" factor that async garnered in the Python community. (Never mind that the "coolness" came from solving a problem that doesn't even exist in other languages...) If you want to see what asynchronous programming would look like if it weren't copied from Python, look at the recent C++ proposal. > - If you don't need it, don't use it. Rust without asynchronous functions still looks and works like before The problem is that every Python library now comes in two versions, regular and 'async'. Even if you don't need or care about anything 'async'. I guess splintering your code base into two incompatible flavors is just the pythonic way of doing things? Now that the 2 vs 3 insanity is finally dying down, they needed to start a fresh one? Why is Rust trying hard to repeat these mistakes? > - By the way: welcome to C++20's coroutines That I already answered above.

iknowstuff 7y ago

It’s important to distinguish 3 categories of coroutine implementations: stackful, stackless-on-heap, stackless-as-struct. C++ is stackless-on-heap. Stackless-as-struct is essentially creating an anonymous type (ala lambda), used to save the data across suspension points. This is the approach taken by Rust for its async/await implementation. I believe there were declaration/definition and ABI concerns about this approach for C++: > "While it is theoretically not an insurmountable challenge , it might be a major re-engineering effort to the front-end structure and experts on two compiler front ends (Clang, EDG) have indicated that this is not a practical approach." So the short answer seems to be that due to technical debt on the part of existing C++ compilers and their "straight" pipeline, the front-end cannot anticipate the size necessary for some book-keeping information traditionally handled by the code-generator. I'll take Richard Smith's word on Clang.