Hi all,
I wanted to ask if Fibers will be "only" the pendant to Kotlins Coroutines or Goroutines in Golang... in Java or does it add advantages?
I guess it'll just be the Java implementation, right?
All in all I think Java's future is somehow just adding features, which are already in Kotlin since some time (also with the enhanced switch-statement, more or less smart casts, adding Pattern Matching based on classes, now with the text blocks...). I'm not very enthusiastic, I have to say. I think the Java architects are only trying to catch up a bit with Kotlin, more or less.
Kind regards
Johannes
Top comments (6)
Take a look at the following article:
blog.softwaremill.com/will-project...
Basically, Kotlin coroutines are executed at compile time while Java fibers have runtime support since the JVM has fibers implemented natively. Kotlin's coroutines are finally transformed by the compiler and remain thread-blocking.
Regarding reactive solutions and issues, you can check Project Loom Team Lead comments:
infoq.com/presentations/continuati... and Tomek Nurkiewicz talk:
youtube.com/watch?v=5TJiTSWktLU
and
Fortunately they don't. Kotlin is not the best source of useful features.
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.