Goroutines use thread-per-core but run stackful fibers on top of that. (A similar model is sometimes known as "Virtual Processors" or "Light-weight processes".) This is unlike the use of stackless async-await in other languages. This peculiar use of fibers in Go is also what gets in the way of conventional C FFI and leads to quirks like cgo.

Excellently described.

I'd love to see a resource that highlights these all on a table across programming languages as well as the associated strengths and weaknesses of such threading & concurrency models.

Perhaps a ByteByteGo graphic, if you will.

In the future, I think thats what I'll say. Thanks.

I usually just say that Go implements "userspace threading", since that's really what it is. Some early, pre-pthreads, implementations of Linux threads worked the same way as Go does and they usually called such implementations "M:N", to indicate M userspace threads mapped onto N kernel threads, so "M:N" is a good descriptor too.

but that's not really accurate. It uses system threads. Userspace threading doesn't make a transition to kernel (IIUC).

Go doesn't need to transition to the kernel to switch threads, does it? It just saves and loads the register state in userland.

IIUC it can, sometimes, avoid a kernel transition when it knows it can schedule the recipient of a message, but I believe that golang creates a threadpool for running goroutines on platforms that use thread primitives.

From https://github.com/golang/go/blob/c7d6c6000a84b61ac8bb2e38e8... I believe "worker threads" are OS threads.

The Go runtime can create more that one thread per core, especially when there is some blocking syscall.

Back when Java had green threads (the late 1990s), there was no such thing as "multi-core machines". Some top-of-the-line servers had SMP (i.e. two or more physical processors running together on the same bus and sharing the same memory), but very few programs were built to take advantage that option yet.

So Java's green threads was not a stop-gap for the 90s machine which only had one core. That's preposterous. Does Go need to disable its goroutines to support the Raspberry Pi Zero that has only one core? Obviously not! The reason Java didn't support multi-core scheduling is that multi-core processors still weren't a thing, and SMP was too high-end for them to bother (and by the time they did start caring about high-end systems, they've already moved to kernel threads).

Nothing prevents green threads from supporting multi-core (Java 21's Virtual Threads obviously do that, but Erlang's processes also had SMP support well before Go).

I think the terms "green threads" or "user-space threads" are really not that confusing. Definitely not confusing enough to warrant inventing a new term like "goroutines". THAT is confusing. I'm happy the Project Loom team resisted the urge to give the Virtual Threads a fun name like "Jorutines".

sun, where java was written, was shipping smp computers with 64 processors in 01997, two years after they first released java https://en.wikipedia.org/wiki/Sun_Enterprise

they bought that off cray, but in 01995 a few months after they released java, they (a different division) released the dual-processor ultra 2 https://en.wikipedia.org/wiki/Sun_Ultra_series

but that wasn't sun's first smp machine; the sparcserver 630mp, among others, supported four cpus in 01991 https://en.wikipedia.org/wiki/SPARCstation#Server_systems

i had a dual-processor smp pentium pro under my desk by 01998, running windows nt 4.0 and occasionally java

really tho the bigger issue with java performance was that there was no supported native-code compiler until hotspot; though gcj was available, sun didn't support it, and i don't recall its performance as being that great. so by writing your code in java you were usually wasting 95% of your cpu on the bytecode interpreter, like python today. it wasn't something you'd do for things that required a lot of cpu