Hacker News Reader

Comment by samuell | Hacker News Reader

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.

View on HN

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.

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

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

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.

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.

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).

Haskell, Java

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

Java threads including Virtual Threads (JDK 21+) are preemptive.

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

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.

The original message you replied to said (mistakenly):

> adopt true goroutines

Goroutines are preemptive. The distinction between cooperative and non-cooperative concurrency is very significant - it is the difference between never having to think about the scheduler and always having to thinking about it when doing CPU intensive tasks.

Reply on news.ycombinator.com