Coroutines and fibers existed long before Kotlin did born. So, even if they will be identical in regard to features this does not mean that Java copies Kotlin.
But I don't see significant value in either of them, just a poor hack to continue using flawed "thread per task" processing model instead of reactive solution.
There is no physical possibility to simultaneously run more concurrent threads than exists logical CPU cores. Any attempt to run at once more tasks than exists cores means that there is scheduling and context switching overhead. Depending on the implementation details amount of overhead is different. For regular threads this amount is huge, it involves context switching (quite expensive operation by itself) and OS-level scheduling (with its own specifics, not necessarily optimal for particular application). For fibers/coroutines it's quite small, involves only app-level scheduling. But this overhead is still present.
Carefully written pure event driven application based on callbacks or promises has virtually near to zero such overhead. What is even better - it automatically establishes optimal order of execution of all parts of code. Any external scheduler will be worse in this regard. This is the primary reason why I see no big value in fibers/coroutines. The only reason of their existence is ability to continue writing classic synchronous code.
One curious observation: classic synchronous code is imperative and has quite a lot of issues (exceptions, error and null values handling, for example). Reasonable solution is wider use of FP code approaches. But most FP approaches are heavily based on passing functions, i.e. using kind of callback. So switching to FP code style makes use of reactive approaches quite natural.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
So what will be the difference or advantage of Fibers to Kotlins Coroutines?
Coroutines and fibers existed long before Kotlin did born. So, even if they will be identical in regard to features this does not mean that Java copies Kotlin.
But I don't see significant value in either of them, just a poor hack to continue using flawed "thread per task" processing model instead of reactive solution.
Multiple tasks can run in the same thread with Kotlin Coroutines. As long as you have true non-blocking IO you can call .await() anyway..
There is no physical possibility to simultaneously run more concurrent threads than exists logical CPU cores. Any attempt to run at once more tasks than exists cores means that there is scheduling and context switching overhead. Depending on the implementation details amount of overhead is different. For regular threads this amount is huge, it involves context switching (quite expensive operation by itself) and OS-level scheduling (with its own specifics, not necessarily optimal for particular application). For fibers/coroutines it's quite small, involves only app-level scheduling. But this overhead is still present.
Carefully written pure event driven application based on callbacks or promises has virtually near to zero such overhead. What is even better - it automatically establishes optimal order of execution of all parts of code. Any external scheduler will be worse in this regard. This is the primary reason why I see no big value in fibers/coroutines. The only reason of their existence is ability to continue writing classic synchronous code.
One curious observation: classic synchronous code is imperative and has quite a lot of issues (exceptions, error and null values handling, for example). Reasonable solution is wider use of FP code approaches. But most FP approaches are heavily based on passing functions, i.e. using kind of callback. So switching to FP code style makes use of reactive approaches quite natural.