4 ms·

Glad to see more languages adopt true goroutines [edit: lightweight threads or fibers] with M:N scheduling. Surprised more haven't. Among compiled language I'm

by samuell 3mo ago

Glad to see more languages adopt true goroutines [edit: lightweight threads or fibers] with M:N scheduling. Surprised more haven't. Among compiled language I'm only aware of Go and Crystal off the top of my mind.

kccqzy 3mo ago
Haskell does too. And it predates Go by a large margin, such that calling it goroutine is weird. And within Google, the C++ implementation fiber also predated goroutines. It really shows that this is more of a library feature rather than a language feature.
- Balinares 3mo ago
  In fairness, goroutine is far catchier than >>=<%>.
- throwaway17_17 3mo ago
  I agree with your objection to treating goroutines as the baseline implementation of fibers. However, I would disagree with categorizing the feature as a library feature vs a language level feature. In “low-level” languages (C, Rust, Zig, C++, etc) the ability and option exists for having ‘green threads’ with most of their commonly assumed characteristics be library based constructs (although see [1] for why that’s not true for threads in general ). However, almost all managed/runtime-required/scripting/“high level” languages lack the facilities to implement almost any realistic types of fibers and any FFI based implementations are going to suffer severe syntax integration issues (I am assuming somewhat on this point). TL;DR Green threads are on a library feature for low level languages. 1 - Threads Cannot Be Implemented as Libraries (Boehm 2005), https://dl.acm.org/doi/10.1145/1064978.1065042 https://dl.acm.org/doi/10.1145/1064978.1065042
  - ktpsns 3mo ago
    Another thing is the stdlib integration of goroutines. We see this in Python where various generations of paradigms kind-of coexist. Golang built their goroutines into the heart of the stdlib which puts it IMHO in a special position.
  - kccqzy 3mo ago
    We are not disagreeing here. Your citation is actually not relevant: Boehm is arguing that you cannot implement threads as libraries in a language without threading. But all modern languages actually have OS native threads; the addition of green threads to this environment does not require any further changes to the compiler in addition to what has been changed to support OS threads. If anything, green threads are even easier to support than real OS threads depending on the preemption design.
gf000 3mo ago
Haskell, Java
- jeremyjh 3mo ago
  Java and Crystal are not equivalent - neither have preemptible threads. Lots of other languages have co-routines or other cooperative systems - async/await are really just variants of that. I didn't check if Gossamer is actually preemptible. I believe the short list of production languages with preemptible M:N schedulers are limited to: Erlang/Elixir Haskell Go
  - msgilligan 3mo ago
    Java threads including Virtual Threads (JDK 21+) are preemptive.
    - jeremyjh 3mo ago
      They are not - and do not claim to be preemptive. They claim they are "not cooperative", but even that doesn't mean what anyone else thinks it means. This paragraph is the only one containing the word "preempt" in JEP 444: "The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads." https://openjdk.org/jeps/444 https://openjdk.org/jeps/444
      - gf000 3mo ago
        How did we get to that? We were talking about n:m threading, especially with threads being blocking IO-aware, being able to automagically turning such a call to non-blocking. Java more than fits that description.
        3mo ago
Twey 3mo ago
Green threads predate modern async/await by quite a long way. Since async/await was developed, recent languages tend to prefer the ‘principle of least surprise’ by making the yield points explicit, since they interact in important ways with the code around them, with the notable exception of Go (which is very weird considering how explicit they decided to make their error handling).

by samuell 3mo ago

kccqzy 3mo ago

Haskell does too. And it predates Go by a large margin, such that calling it goroutine is weird. And within Google, the C++ implementation fiber also predated goroutines. It really shows that this is more of a library feature rather than a language feature.

Balinares 3mo ago
In fairness, goroutine is far catchier than >>=<%>.
throwaway17_17 3mo ago
I agree with your objection to treating goroutines as the baseline implementation of fibers. However, I would disagree with categorizing the feature as a library feature vs a language level feature. In “low-level” languages (C, Rust, Zig, C++, etc) the ability and option exists for having ‘green threads’ with most of their commonly assumed characteristics be library based constructs (although see [1] for why that’s not true for threads in general ). However, almost all managed/runtime-required/scripting/“high level” languages lack the facilities to implement almost any realistic types of fibers and any FFI based implementations are going to suffer severe syntax integration issues (I am assuming somewhat on this point). TL;DR Green threads are on a library feature for low level languages. 1 - Threads Cannot Be Implemented as Libraries (Boehm 2005), https://dl.acm.org/doi/10.1145/1064978.1065042 https://dl.acm.org/doi/10.1145/1064978.1065042
- ktpsns 3mo ago
  Another thing is the stdlib integration of goroutines. We see this in Python where various generations of paradigms kind-of coexist. Golang built their goroutines into the heart of the stdlib which puts it IMHO in a special position.
- kccqzy 3mo ago
  We are not disagreeing here. Your citation is actually not relevant: Boehm is arguing that you cannot implement threads as libraries in a language without threading. But all modern languages actually have OS native threads; the addition of green threads to this environment does not require any further changes to the compiler in addition to what has been changed to support OS threads. If anything, green threads are even easier to support than real OS threads depending on the preemption design.

gf000 3mo ago

Haskell, Java

jeremyjh 3mo ago
Java and Crystal are not equivalent - neither have preemptible threads. Lots of other languages have co-routines or other cooperative systems - async/await are really just variants of that. I didn't check if Gossamer is actually preemptible. I believe the short list of production languages with preemptible M:N schedulers are limited to: Erlang/Elixir Haskell Go
- msgilligan 3mo ago
  Java threads including Virtual Threads (JDK 21+) are preemptive.
  - jeremyjh 3mo ago
    They are not - and do not claim to be preemptive. They claim they are "not cooperative", but even that doesn't mean what anyone else thinks it means. This paragraph is the only one containing the word "preempt" in JEP 444: "The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads." https://openjdk.org/jeps/444 https://openjdk.org/jeps/444
    - gf000 3mo ago
      How did we get to that? We were talking about n:m threading, especially with threads being blocking IO-aware, being able to automagically turning such a call to non-blocking. Java more than fits that description.
      - 3mo ago

Twey 3mo ago

Green threads predate modern async/await by quite a long way. Since async/await was developed, recent languages tend to prefer the ‘principle of least surprise’ by making the yield points explicit, since they interact in important ways with the code around them, with the notable exception of Go (which is very weird considering how explicit they decided to make their error handling).