6 ms·
My first thought was "why don't they use Akka"? > Akka has no true lightweight threads (the actors are actually callbacks) Would you care to elaborate? I'm no
by CookWithMe 13y ago
My first thought was "why don't they use Akka"?
> Akka has no true lightweight threads (the actors are actually callbacks)
Would you care to elaborate? I'm not too familiar with the internals of Akka, but they definitely don't use "heavyweight" threads (which I assume are threads that are 1:1 mapped to OS threads).
Also, I didn't get "the actors are actually callbacks". Yes, there may be callbacks involved internally (why not?), but there is a big difference whether I am sending a message to an actor (which may be processed at any time) vs. calling a callback (which is immediately executed on the very same thread that I'm running on).
Sorry if this sounds dismissive, but I'd really like to learn why you choose to implement your own solution, because you've obviously put some time into evaluating what is out there.
- pron 13y agoSee my reply to jaimefjorge
- hp 13y agohttps://github.com/scala/async https://github.com/scala/async is the syntactic sugar to write sequential nonblocking code in Scala (no callbacks). Though functional-style code works well also if you know it.
- pron 13y ago[cloned comment] Essentially, Quasar provides async and await for all JVM languages. async is called `Fiber.start()`, and await is called `Fiber.park`. Other than working for all JVM languages, Quasar fibers are more general in that they can spawn many functions (they have a stack), while async is limited to a single expression block. Because of this, we can hide the "await" deep inside the JDBC call stack. Under the hood, they are similar: both instrument your code. Only async does this at the language level (it's a Scala macro), while fibers do it at the bytecode level.