More powerful. Java threads are objects with a standard API for managing them, and you can do things like await concurrent work without rolling your own command protocol using channel pairs and hoping some goroutine out there might still be answering. A JMX client can even show them in a GUI.

This makes the same concept radically cheaper by not involving the kernel, which is great because Java hasn't had green threads for a long time, and doing everything async in small worker pools worked but has admittedly been pretty painful.

That’s the idea, just like coroutines in Kotlin.

Coroutines in Kotlin are only a compiler trick, and are stackless. Go and Java's are stackful, reifed: small stack chunks are moved in and out of the heap to the carrier stack.

This means you get an actual meaningful stacktrace when debugging, and not something stemming from a mysterious event-loop thread.

In Java you could save your coroutine state to disk, and wake it up later in theory.

----

EDIT: This being said, I'm 99% sure Kotlin is going to pass Loom's goodness onto their developers when it's available, probably reusing the existing coroutine API.

Kotlin is placing themselves into a corner by trying to go everywhere and married Android.

So for every JVM/Java feature post Java 6 that gets introduced, they will have the dilemma of how to integrate them into a way that keeps language semantics across compilation targets, having multiple solutions to the same problem (Kotlin's one and what each platform later introduced), or just expose them via KMM and leave the #ifdef burden to the community.

That is why platform languages always carry the trophy, even if they are the turtle most of the time.

Well, so far that hasn't been an issue. Kotlin is a pragmatic language. The differences that currently exist can be addressed just with an annotation here or there. Also, Kotlin's features are designed whilst paying careful attention to what the Java guys are doing. Look at how records have played out. You can use JVM records from Kotlin transparently, you can create them by just adding an annotation (not that there's much point in doing so, as records are mostly a labour saving device that Kotlin already had).

Value types are perhaps a better example. Kotlin has them already with nearly identical semantics to Valhalla, but without the ability for them to have more than one field due to the need for erasure. Once Valhalla arrives, Kotlin can simply remove that restriction when targeting the JVM, perhaps add another annotation or compiler flag to say "make this a real Java value type". No language changes needed beyond that.

Kotlin is semantically so close to Java already that they aren't really growing apart, they're growing together. It works well enough to justify its usage, for me.

JVM history is full of pragmatic guest languages.

Yes, and it's richer for it. Java is definitely not the last word in language design!

Indeed, it just has the same role on the JVM as C on UNIX, JS on the browser,....

Just like those, it will slowly adopt whatever is more appealing from the guests and then carry on its merry way, while the other slowly lose their relevance while newcomers try yet again to challenge the place of the host language on the platform.

It sure is a dilemma. Java is catching up. When (if) Java introduces null-safety, Kotlin will loose much of its lustre, at least to me.

Virtual threads are superior to coroutines, which are still a pain in the ass in Kotlin, cause issues with mocking and you can't even evaluate them in the repl.

Kotlin's null safety is only a selling point when one uses 100% libraries written in Kotlin.

PMD, SonarQube and nullable annotations have long sorted that problem in our Java projects.

> PMD, SonarQube and nullable annotations

Not a fan of any of those tools, tbh. Still better than nothing I suppose, but I'd rather use Kotlin in the meantime.

They're talking about it and waiting to see if `?` pays off in C# and Kotlin before moving on it.

From C# point of view, I have hardly seen anyone use it outside conference talks about new C# features.

Right now there are 20 years of having null as default and turning it on just generates endless warnings.

So it is left for complete new projects where almost no third party libraries are being used, which right now is very little.

I also hope that C# 10 doesn't get !! for checked parameters, but it might already be too late.

Interesting, got any links?

I do not, but as always this is the Java way. Being the last mover is how Java moves forward with features. They let other languages experiment first so they don't have to support a bad feature for eternity because of Java's backwards compatibility promises.