2 ms·

The interesting aspect is not "running Kotlin coroutines on Loom", but eliminating the need for source-level coroutine keywords and solving the problem of funct

• jillesvangurp 5y ago
  Sorry, but that's not what Loom is about at all. It's mostly about the jvm internals; that's the main chunk of work. The API level stuff is just designed to be consistent with the existing Thread API, with all it's technical debt, flaws, boiler plate, etc. that has inspired alternative frameworks and approaches to be written. It's consistent with that is the best you can say about it. To me it looks like it's a nod to other frameworks to make it as easy as possible for those to integrate this stuff. Good approach, very valid. It's not designed to be more usable / less boiler plate heavy. That's what other frameworks are for. Loom is not a replacement for these frameworks but something that is designed to seamlessly be integrated by them. There's only 1 co-routine related keyword in Kotlin: 'suspend'. The rest of co-routines ships in the form of a normal kotlin multiplatform library that you just add to your project. Java has several keywords that you don't need in Kotlin (e.g. synchronized, volatile). You can mark things as synchronized with a simple kotlin function. And likewise there's a Volatile annotation. Mostly that's just useful for kotlin code that needs to be used from Java. The function coloring bit seems to obsess a lot of people. I just don't see the issue with it. For me the boiler plate that Java makes you use instead is a much bigger issue.