4 ms·

> In general, it can. Yes, it's called threads. > You can look at Erlang, Haskell, and Go as things that just handles the matter internally, between the comp

> In general, it can. Yes, it's called threads. > You can look at Erlang, Haskell, and Go as things that just handles the matter internally, between the compiler and the runtime, and erases the color distinction. Erlang, Haskell, and Go use threads, just a particularly idiosyncratic M:N userspace implementation. There's no conceptual difference between what those three languages do and pthreads. Note that all three implementations are stackful (in Haskell's case, morally so rather than technically so). > I would certainly encourage any modern language designer starting from scratch to think long and hard before simply blindly porting async/await into their language. Look around at what else has been done first. I consider it an awfully klunky answer. Async/await allows you to have stackless coroutines, because of the explicit nature. This is a significant benefit, and dismissing it as "klunky" is a misunderstanding. > I haven't looked into it personally but I hear Zig has an interesting answer. Zig uses async/await with a global per-program switch that allows the whole program to be switched into blocking mode.

jerf 5y ago
"Async/await allows you to have stackless coroutines, because of the explicit nature. This is a significant benefit, and dismissing it as "klunky" is a misunderstanding." No, I understand it perfectly. It is a disagreement about the relative cost/benefits of making the programmer do it vs. letting the runtime do it, even if it costs a bit. I'd lay money 90%+ of the people doing async/await, either because they are stuck in a language in which it is the only choice (Javascript being the biggest entrant here since in its space there is no alternative), or because they thought they needed it, do not benefit from the additional 5-ish percent of performance gain, because programmers have been assuming they need the biggest, baddest toolset to write their code that handles a 50us request every few seconds since programming began. Instead they ought to be using a system that is far easier for the programmer and letting the runtime and compiler do the work. It is good, even very good, that Rust provides the option to remove even those last few percent of overhead. It is not good that so many people who have problems that are orders of magnitude away from needing that level of performance choose something that requires more of the programmer instead of more of the compiler/runtime. That Rust community has decided this is almost the only way of doing concurrency (even if the Rust language itself technically is not requiring that) is one of the major things keeping me away from it. I don't want to do that work unless I'm tight up against my CPU budget, and in a world of 64 core servers and when I'm not doing any hard realtime networking like routing, none of my tasks are even close to requiring that. (Not that I use those 64 core servers, I'm just saying they're there before I need to go crazy to get the last few percent. I'm usually more in the position of explaining to my coworkers that the system they seem to think needs a 16core machine with oodles of RAM runs rather comfortably on the second smallest instance there is and is still mostly twiddling its thumbs.) I don't care about that last little bit of performance in my personal need space, and even the vast majority of Rust users shouldn't either. Again, that it's available for the ones who legitimately do is very good. But it's a klunky, ugly default to go slightly faster, or to enable the average programmer to fit in to 1% of the available RAM for their task instead of 1.4%, to have to add a color to all your functions and tell the compiler over and over again "Here's where you split my function to do some IO here... and I do some here... and I do some here... and I do some here... and I do some here..." unto literally thousands of times for even medium sized programs. It's good that it exists. It's a bad default.

jerf 5y ago

"Async/await allows you to have stackless coroutines, because of the explicit nature. This is a significant benefit, and dismissing it as "klunky" is a misunderstanding." No, I understand it perfectly. It is a disagreement about the relative cost/benefits of making the programmer do it vs. letting the runtime do it, even if it costs a bit. I'd lay money 90%+ of the people doing async/await, either because they are stuck in a language in which it is the only choice (Javascript being the biggest entrant here since in its space there is no alternative), or because they thought they needed it, do not benefit from the additional 5-ish percent of performance gain, because programmers have been assuming they need the biggest, baddest toolset to write their code that handles a 50us request every few seconds since programming began. Instead they ought to be using a system that is far easier for the programmer and letting the runtime and compiler do the work. It is good, even very good, that Rust provides the option to remove even those last few percent of overhead. It is not good that so many people who have problems that are orders of magnitude away from needing that level of performance choose something that requires more of the programmer instead of more of the compiler/runtime. That Rust community has decided this is almost the only way of doing concurrency (even if the Rust language itself technically is not requiring that) is one of the major things keeping me away from it. I don't want to do that work unless I'm tight up against my CPU budget, and in a world of 64 core servers and when I'm not doing any hard realtime networking like routing, none of my tasks are even close to requiring that. (Not that I use those 64 core servers, I'm just saying they're there before I need to go crazy to get the last few percent. I'm usually more in the position of explaining to my coworkers that the system they seem to think needs a 16core machine with oodles of RAM runs rather comfortably on the second smallest instance there is and is still mostly twiddling its thumbs.) I don't care about that last little bit of performance in my personal need space, and even the vast majority of Rust users shouldn't either. Again, that it's available for the ones who legitimately do is very good. But it's a klunky, ugly default to go slightly faster, or to enable the average programmer to fit in to 1% of the available RAM for their task instead of 1.4%, to have to add a color to all your functions and tell the compiler over and over again "Here's where you split my function to do some IO here... and I do some here... and I do some here... and I do some here... and I do some here..." unto literally thousands of times for even medium sized programs. It's good that it exists. It's a bad default.