3 ms·

How did Java (as opposed to JVM) try to properly engineer solution to the problem coroutines were created to solve?

jsiepkes 6y ago
Project Loom: https://openjdk.java.net/projects/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-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).
- balfirevic 6y ago
  "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.
  - vips7L 6y ago
    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.
    - jsiepkes 6y ago
      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.
chrisseaton 6y ago
> How did Java (as opposed to JVM) Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
- balfirevic 6y ago
  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.
  - chrisseaton 6y ago
    Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.
  - jdmichal 6y ago
    Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.

Project Loom: https://openjdk.java.net/projects/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-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).

balfirevic 6y ago
"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.
- vips7L 6y ago
  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.
  - jsiepkes 6y ago
    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.

chrisseaton 6y ago

> How did Java (as opposed to JVM) Well that’s the point - they solved it in the JVM not as a kludge of bytecode.

balfirevic 6y ago
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.
- chrisseaton 6y ago
  Anyone can propose changes to the JVM. The Java people did. The Kotlin people didn't. And the Kotlin approach generates bad (irreducible) bytecode.
- jdmichal 6y ago
  Yet the JVM had `invokedynamic` before it had any use in Java, specifically to support more dynamic languages.