Hacker News Reader

Comment by peterisdirsa | Hacker News Reader

I don't get it. How is this different than using standard Java ExecutorService & co features?

I'm curious as well. Once you can use an ExecutorService with virtual threads, the gap seems a bit thin.

The best I can tell is that coroutines are a bit lighter weight (in terms of what state is managed) and have a bit simpler usage out-of-the-box.

But I've not used them myself so maybe I'm not seeing how big of advantage those are or perhaps there's more to it than that?

Well for one, virtual threads would be implicit blocking and this style is explicit.

so kotlin functions are colored while java ones are colorless?

Java doesn't have an equivalent to Kotlin's 'suspend fun'. The CoroutineScope abstraction ('launch', 'join', 'await', etc) is also absent, at least until Structured Concurrency gets released [1] and Java gains StructuredTaskScope.

1: https://openjdk.org/jeps/462

It explicitly says it's not for actual use.

The point (I think) was as an exercise to demonstrate it was possible to implement in 'userland' and how they did so.

The runtime uses ExecutorService and friends to run coroutines, which are bits of CPS-transformed Kotlin code that are generated when you compile a 'suspend fun' declaration.

The way the code looks is completely different and significantly cleaner and faster to write in Kotlin. Actual performance and final functionality is likely to be same.

Reply on news.ycombinator.com