Project Loom: https://openjdk.java.net/projects/loom/

The view being that async-await leads to a "What color is your function" problem ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).

"As opposed to JVM"

You don't have to convince me that green threads are far superior to async-await - I already believe that.

But that's not something Kotlin (nor Java, on the language level) could have solved.

You're correct but you're forgetting that the jvm IS java. When it isn't trivial to solve at the language level they have the power to change the runtime.

And on top of that Kotlin is now basically stuck with async-await forever. Removing async-await from the language and designing a more superior model the JVM now allows for with Loom is probably not going to happen. Adding a new model based on the new possibilities Loom provides will probably cause too much fragmentation (unless they come up with some really clever interop) so thats also unlikely.

Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.

> How did Java (as opposed to JVM)

Well that’s the point - they solved it in the JVM not as a kludge of bytecode.

Well, once that happened Kotlin also gets the solution.

It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.

Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.

Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.