> 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.
> 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!
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.