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?
That's why higher level languages are in an advantage. E.g. in java - outside of FFI - syscalls are basically "only within" standard library functions. So it was possible to make them virtual thread aware, e.g. park a virt thread, use something like io uring for the actual IO call on the JVM level and resume it when it returns, doing work on another virt thread in the meanwhile.
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 ↗
dlisboa · · focus · HN ↗
dwattttt · · focus · HN ↗
falserum · · focus · HN ↗
LtWorf · · focus · HN ↗
gf000 · · focus · HN ↗