4 ms·
I don't get it. How is this different than using standard Java ExecutorService & co features?
by peterisdirsa 3y ago
I don't get it. How is this different than using standard Java ExecutorService & co features?
- Shawnecy 3y agoI'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?
- jayd16 3y agoWell for one, virtual threads would be implicit blocking and this style is explicit.
- _ZeD_ 3y agoso kotlin functions are colored while java ones are colorless?
- tadfisher 3y agoJava 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 https://openjdk.org/jeps/462
- mst 3y agoIt 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.
- tadfisher 3y agoThe 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.
- lfmunoz4 3y agoThe 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.