[kllrnohj]

That's because they are very rarely useful. This was true then and it's still true now. There's just not many workloads where it makes sense to need to rapidly launch a thread that doesn't need to do much of anything but does need to exist for a while before terminating.

What is useful is the state machine aspects of things like coroutines or async/await, but those aren't quite fibers and very much aren't M:N threading. A major use of them is in UI where they have strict thread requirements even.

[freedomben]

Exactly. When I started getting into go 15 years ago, and 10 years ago or so into elixir, I loved the easy concurrency and tried to use it to the maximum possible. What I discovered is that they're just aren't that many things that you can do concurrently. Reading many different files or servicing many different network sockets being the exception, but realistically that isn't done very often relative to single threaded stuff.

State machine/management is really what is most useful

[bjoli]

you can implent something like futures on top of cml and use it as async. then you get async for stuff where async is useful and a proper way to write parallel programs for when async would lead to all the bad stuff async leads to.

i rarely write gui stuff and I find async is rarely what I need. in f# I at least have the option to use hopac.

[kllrnohj]

> and a proper way to write parallel programs for when async would lead to all the bad stuff async leads to.

you need real threads for parallelism though? And real threads scale just fine such that m:n threading isn't typically needed.

[bjoli]

that is one of the reasons async is everywhere. proper threads are not enough. 2 threads are great at doing 2 things at once, but unless you have the hardware 1000 threads scale very badly at doing 1000 dings at once.

with CAS, making a multicore cml is not too hard.