5 ms·

One of the unsung heroes of go is how goroutines sit on top of channels + select. Blocking and waiting on one queue is easy, blocking and waiting on a set of qu

One of the unsung heroes of go is how goroutines sit on top of channels + select. Blocking and waiting on one queue is easy, blocking and waiting on a set of queues waiting for any to get an element is a good deal trickier. Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. You can kinda do this with futures but I suspect it'll be wildly inefficient. I really hope Java get's something to fill this niche. We already have a menagerie of Queue, BlockingQueue, and TransferQueue implementations. What's a few more?

ackfoobar 4y ago
> Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. Kotlin coroutines have the bare minimum in the language, and implement the rest (e.g. channel, select, `go`/`launch`) in libraries. Could you explain what the dividends for Go are?
MrBuddyCasino 4y ago
Channels on the JVM would be sweet. You can do the same with Futures, and its probably not even slower, but it is a lot more clunky. I suspect its never gonna happen, too big a change. Maybe Kotlin will do it.
- native_samples 4y ago
  Kotlin already does it: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.selects/select.html https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutin...
  - MrBuddyCasino 4y ago
    Interesting. Not quite as clean as if it was a built-in keyword, but close enough. Seems this is still experimental and not available per default.
sudarshnachakra 4y ago
I guess the Structured Concurrency JEP below addresses the problems you'll get to solve. It'll enable things like AND / OR combinations of virtual threads which IMHO looks like a better way to solve this rather than having a special syntax for select. https://openjdk.java.net/jeps/8277129 https://openjdk.java.net/jeps/8277129 But frankly I'm afraid of how these changes affect garbage collection since more and more vthread stacks are going to be in the heap (I hope they are contemplating some form of deterministic stack destruction along with the above JEP).

ackfoobar 4y ago

> Having that baked into the language and the default channel data-structures really does pay dividends over a library in a case like this. Kotlin coroutines have the bare minimum in the language, and implement the rest (e.g. channel, select, `go`/`launch`) in libraries. Could you explain what the dividends for Go are?

MrBuddyCasino 4y ago

Channels on the JVM would be sweet. You can do the same with Futures, and its probably not even slower, but it is a lot more clunky. I suspect its never gonna happen, too big a change. Maybe Kotlin will do it.

native_samples 4y ago
Kotlin already does it: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.selects/select.html https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutin...
- MrBuddyCasino 4y ago
  Interesting. Not quite as clean as if it was a built-in keyword, but close enough. Seems this is still experimental and not available per default.

sudarshnachakra 4y ago

I guess the Structured Concurrency JEP below addresses the problems you'll get to solve. It'll enable things like AND / OR combinations of virtual threads which IMHO looks like a better way to solve this rather than having a special syntax for select. https://openjdk.java.net/jeps/8277129 https://openjdk.java.net/jeps/8277129 But frankly I'm afraid of how these changes affect garbage collection since more and more vthread stacks are going to be in the heap (I hope they are contemplating some form of deterministic stack destruction along with the above JEP).