One of the major issues that Kotlin faces is that it’s hard for them to change the VM to provide a feature they want while Java and the OpenJDK developers have the freedom to either change the VM or the language to provide something.
I don't think it's too burdensome, because they can emulate features until the JVM gets support. I can think of several:
- Data classes can become JVM records with the @JvmRecord annotation and some additional type constraints.
- Inline classes will certainly become Valhalla value types (hence the required @JvmInline annotation).
- Nullable types are supported with compile-time checks and additional runtime checks inserted by the compiler at time-of-use, and if Valhalla adds a nullability marker to the bytecode, Kotlin can support it.
- Coroutines/structured-concurrency already uses Executors under the hood, so it's likely that we'll have Loom thread support without any changes to the coroutines APIs (though the standard dispatchers will need to use virtual threads themselves). Coroutines themselves are CPS-transforms of ordinary code and don't need VM support.
- Tail-call elimination is supported by transforming to trampolines, something which the JVM will probably never support until Java needs it.
Right but, in my opinion, those all come with ergonomic issues from not being able to change the VM. In general the quality of the feature provided by Java will be better because of their ability to mold the VM to the language.
For example syntactic cooperative coroutines vs preemptive coroutines provided by the VM. Kotlin is now stuck with the colored function problem and has the stack trace issues that the Java team is able to avoid by not only being able to change the language.
That being said, I think they're both fine languages with different goals.
I'm not convinced colored functions are a problem, personally. You either color an async function with a Continuation argument and place yields, or you can mark it as a CPS function with a keyword, so it's not like coloring goes away by omitting the keyword. And making async pre-emptive introduces a different kind of complexity that can be just as hard, if not harder, to reason about for anything more complex than "park this thread for IO".
