10 ms·

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not l

by bjoli 3mo ago

It seems like we forgot about lightweight fibers for about 30 years and then collectively rediscovered it in about 2010. sure, Java did green threads, but not like m:n stuff. I sometimes wonder where we would be now if people would have gone "Wow, mr Reppy! concurrentML is so cool!" in 1993. instead we got pthreads and collective amnesia and later we got go's girly times and channels which are only half way there.

kllrnohj 3mo ago
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 3mo ago
  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 3mo ago
  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 3mo ago
    > 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 3mo ago
      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.
smallstepforman 3mo ago
Yet the average software engineer hasn’t heard or Carl Hewitt, Joe Armstrong, has never programmed in an Actor Programming model, and dont even know what it is.
BobbyJo 3mo ago
Back then you could spend 6 months making something twice as fast, or wait six months for computers to become twice as fast. People obviously did the latter. It also became a cycle: People write single threaded code -> CPUs/OSs optimize performance/ergonomics for single threaded programs -> People write single threaded code ->... It wasn't until scaling slowed down that interest/investment in concurrency/parallelism took off.
badc0ffee 3mo ago
"girly times" = goroutines?
- bjoli 3mo ago
  yep. writing on my phone. notoriously bad at proof reading.

by bjoli 3mo ago

kllrnohj 3mo ago

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 3mo ago
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 3mo ago
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 3mo ago
  > 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 3mo ago
    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.

smallstepforman 3mo ago

Yet the average software engineer hasn’t heard or Carl Hewitt, Joe Armstrong, has never programmed in an Actor Programming model, and dont even know what it is.

BobbyJo 3mo ago

Back then you could spend 6 months making something twice as fast, or wait six months for computers to become twice as fast. People obviously did the latter. It also became a cycle: People write single threaded code -> CPUs/OSs optimize performance/ergonomics for single threaded programs -> People write single threaded code ->... It wasn't until scaling slowed down that interest/investment in concurrency/parallelism took off.

badc0ffee 3mo ago

"girly times" = goroutines?

bjoli 3mo ago
yep. writing on my phone. notoriously bad at proof reading.