While continuations and coroutines are often used interchangeably (continuations are usually one-shot delimited continuations), Loom's continuations are very different from Kotlin's coroutines, which are more similar to C#'s async/await (they are stackless), while the fibers built on top of Loom continuations are more like Erlang's processes or Go's goroutines.

The difference is very big from the programmer's perspective. Kotlin's coroutines are a syntactic concept; i.e. a piece of code is either a subroutine or a coroutine, and you can use one or the other in different syntactic contexts. Loom's continuations, however, are a purely dynamic construct, like a thread. You can run any piece of code inside a continuation. The implication is that no language change is required for continuations and the fibers that are based on them -- they are just a different implementation of threads -- and no API changes. In fact, even though this talk provides some background, developers don't need to learn about continuations at all to use them. All they need to know is that they can use a light-weight implementation of threads.

Any idea how these fibers compare to the ones used by D as well? I also wonder if this means Kotlin will adopt Fibers since it does build on top of JVM capabilities.

I don't know D; I also don't currently know what Kotlin's plans are.

Fair enough, I know D has fibers, but I'm not sure how different implementations are between languages in regards to fibers. As for Kotlin it was more of a personal reflection, that is fine if you don't know.

Thanks for answering though, I look forward for this. I shared it accross a number of dev communities I frequent and one joke was "java and lightweight in the same sentence" which made me chuckle since I know Fibers are amazing.

What is a language feature of Kotlin is available as a library in Clojure: https://github.com/clojure/core.async/

Almost all of Kotlin's coroutines support is also in a library. The stuff that comes from the compiler is really the smallest possible slice, required because there is syntax for it.

Interesting that, AFAIK, computer science considers continuations a more generic mechanism than coroutines. Continuations allow continuation-passing style, creating from scratch other control flow mechanisms (like return from a subroutine), exceptions and coroutines (and maybe something else which can't be reduced to items from this list, I'm not sure). Wonder if all of that can be done with coroutines?

Continuations can be reused many times. With delimited continuations you capture the continuation as a function that works basically like any other function. With unlimited continuation you capture the continuation as a weird function that never returns but can still be kept as a closure-like thing and called repeatedly. The classic use of multiple continuation calls is “logic programming” or “nondeterminism” where for example you say “let x = choose [1,2,3]” and choose then arranges to have the continuation called three times (perhaps even concurrently).

Is there some special jvm/dalvik support for it?

It's a compiler plugin that generates bytecode for you, so there's no need for support from the runtime.

There is no JVM part of Kotlin coroutines, it just uses plain JVM features as every other Java program.