2 ms·

Isn't point (5) kind of moot with virtual threads? I think golang shows that a synchronous, imperative paradigm wins the masses. I'm not too brushed up with K

Isn't point (5) kind of moot with virtual threads? I think golang shows that a synchronous, imperative paradigm wins the masses. I'm not too brushed up with Kotlin suspend, but does it suffer from the classic "function coloring" problem that plagues other solutions? I've dabbled in functional effect systems in Scala, for example. I really enjoy them, but my coworkers sure don't when they realize that to perform some IO in a new place they will have to update a huge stack of type signatures to be wrapped in an IO monad. Async/await in javascript has the same issue, though the syntax is a bit friendlier. My great hope for virtual threads in Java is that we can bring great IO performance and scalability, on par with golang, without retraining devs.

gavinray 3y ago
Yeah, Kotlin does have the colored-function problem, in the same way that Node/JS has. Loom and Virtual Threads are one area I'm not as familiar with. What I do know is that you can configure virtual threads as the coroutine dispatcher for Kotlin coroutines, and in a recent video Roman Elizarov talked about how the default "Dispatchers.IO" could theoretically leverage VT's in some future JDK. https://youtu.be/zluKcazgkV4?t=2518 https://youtu.be/zluKcazgkV4?t=2518
soulbadguy 3y ago
> I think golang shows that a synchronous, imperative paradigm wins the masses. I am not sure go shows that... Attributed the "poplarity"of go solely to its async model is kind of a leap. > I'm not too brushed up with Kotlin suspend, but does it suffer from the classic "function coloring" problem I never quite understand why function coloring is referred to as a problem. Including the async/non-async nature of a function in its signature is as natural as using any other monadic types as a return, such as Optional for example. > My great hope for virtual threads in Java is that we can bring great IO performance and scalability, on par with golang, without retraining devs. I think that's sometime a conflation that happens : virtual thread usually ease scalability at the the cost of performance.
- hamandcheese 3y ago
  > I never quite understand why function coloring is referred to as a problem. For exactly the reason I said: colored functions are poison. Changing one type is easy. Changing a whole stack of types is tedious. And that's before you realize you tests have stopped compiling as well!
  - ohgodplsno 3y ago
    Colored functions are a warning.
xmcqdpt2 3y ago
> Isn't point (5) kind of moot with virtual threads? It might be but we don't know yet. I have yet to see a large scale application written with virtual threads (for the good reason that it is barely out of development!) I'm reserving judgement until I see virtual threads in use outside of toy examples.

gavinray 3y ago

Yeah, Kotlin does have the colored-function problem, in the same way that Node/JS has. Loom and Virtual Threads are one area I'm not as familiar with. What I do know is that you can configure virtual threads as the coroutine dispatcher for Kotlin coroutines, and in a recent video Roman Elizarov talked about how the default "Dispatchers.IO" could theoretically leverage VT's in some future JDK. https://youtu.be/zluKcazgkV4?t=2518 https://youtu.be/zluKcazgkV4?t=2518

soulbadguy 3y ago

> I think golang shows that a synchronous, imperative paradigm wins the masses. I am not sure go shows that... Attributed the "poplarity"of go solely to its async model is kind of a leap. > I'm not too brushed up with Kotlin suspend, but does it suffer from the classic "function coloring" problem I never quite understand why function coloring is referred to as a problem. Including the async/non-async nature of a function in its signature is as natural as using any other monadic types as a return, such as Optional for example. > My great hope for virtual threads in Java is that we can bring great IO performance and scalability, on par with golang, without retraining devs. I think that's sometime a conflation that happens : virtual thread usually ease scalability at the the cost of performance.

hamandcheese 3y ago
> I never quite understand why function coloring is referred to as a problem. For exactly the reason I said: colored functions are poison. Changing one type is easy. Changing a whole stack of types is tedious. And that's before you realize you tests have stopped compiling as well!
- ohgodplsno 3y ago
  Colored functions are a warning.

xmcqdpt2 3y ago

> Isn't point (5) kind of moot with virtual threads? It might be but we don't know yet. I have yet to see a large scale application written with virtual threads (for the good reason that it is barely out of development!) I'm reserving judgement until I see virtual threads in use outside of toy examples.