3 ms·

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 g

by kccqzy 4mo 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 4mo ago
In fairness, goroutine is far catchier than >>=<%>.
throwaway17_17 4mo 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 4mo 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 4mo 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.

by kccqzy 4mo ago

Balinares 4mo ago

In fairness, goroutine is far catchier than >>=<%>.

throwaway17_17 4mo 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 4mo 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 4mo 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.