[throwaway17_17]

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

[kccqzy]

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.

[ktpsns]

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.