Tsoding - How Not to Market Your Language Features

[Derek Fawcus]

On Friday, 28 March 2025 at 14:15:01 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 29/03/2025 12:41 AM, Dukc wrote:
>>     Also many approaches are expecting async/await behavior
>> 
>> Is this a problem for D? Doesn't Vibe.D, or even just Phobos, 
>> handle this just fine?
>
> No.
>
> D's Fiber's cannot move between threads safely, and there is a 
> limit on the number you can have at the kernel level due to the 
> usage of pages.
>
> We cannot recommend a solution to drive modern event loops 
> (circa late 90's), due to safety concerns and these 
> limitations. Note the word recommend, it is important here!
>
> Hence why we need stackless coroutines to fill in that gap ;)

Actually, one could have light weight stackful coroutines within 
the system, and user space switching.  Have a look at what Alef 
had - the predecessor to Limbo and Go.

It had 'procs' and 'tasks'.  The former being implemented simply 
as kernel level threads, hence preemptively scheduled by the 
kernel, the latter as user level coroutines within such a thread. 
  The same scheme ended up as libthread for C on plan9.

One should be able to create a libthread like facility for D, and 
given the GC it should be almost as usable as the CSP scheme in 
Go.  The difference being the lack of preemption between 'tasks', 
vs the preemption which happens with goroutines.

As to stackless coroutines, I personally find the too much 
hassle, hiding some (but not all) of the detials and complexities 
of their underlying state-machine implementation.

About the only thing I'd say they have going for them is they 
sort of are flavour of the month, and C++ has sort of done the 
same thing.  But then I'm biased, I prefer the CSP / Actor 
approach.