The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
I'm curious; using hardware threads is M logical threads preemptively scheduled on N physical cores. In what way does this not satisfy the original criteria?
They are still full OS threads: they have a full-size stack and have all the same overheads for context switching. Why would you think that a marketing term for a CPU feature is equivalent to an M:N scheduler?
A "hyperthread" can schedule work for two OS threads simultaneously on a single core. An M:N scheduler will schedule millions of green threads on as many cores/hardware threads as you give it (typically you'd give it all of them).
Yes. However the number of times I've scheduled millions of concurrent tasks is 0; hence my question about subjective experience.
I would guess that how well integrated OS threads or green threads are into a language has a much stronger impact on experience & quality.
EDIT: you're also comparing hyper threading itself to the green thread scheduler (M green threads vs 2 logical cores), that doesn't make any sense. You probably want to compare to the OS's scheduler. It will schedule those millions of threads over all the hardware concurrency available too.
SamInTheShell · · focus · HN ↗
Just from observations over the years, I don't think there's any other language quite like this, in terms of how things can end up happening in any thread.
osigurdson · · focus · HN ↗
Doesn't that describe pretty much any green thread style concurrency implementation.
dlisboa · · focus · HN ↗
Other languages and their implementations of green threads usually have cooperative scheduling or M:1 mapping
dwattttt · · focus · HN ↗
jeremyjh · · focus · HN ↗
A "hyperthread" can schedule work for two OS threads simultaneously on a single core. An M:N scheduler will schedule millions of green threads on as many cores/hardware threads as you give it (typically you'd give it all of them).
dwattttt · · focus · HN ↗
I would guess that how well integrated OS threads or green threads are into a language has a much stronger impact on experience & quality.
EDIT: you're also comparing hyper threading itself to the green thread scheduler (M green threads vs 2 logical cores), that doesn't make any sense. You probably want to compare to the OS's scheduler. It will schedule those millions of threads over all the hardware concurrency available too.