> any library it's used with needs to be retrofitted/wrapped to make it work with Quasar.
True, but 1/ to see how easy it can be to integrate a pre-existing library with Quasar, just have a look at the OkHttp integration in Comsat's master and at this post http://blog.paralleluniverse.co/2014/08/12/noasync/ and 2/ the integrations provide an API identical to the original ones, not new ones, which makes the transition (and the opt-out) easy. Further so considering that fibers have API and usage practically identical to regular threads. So there's no API proliferation when integrating Quasar and the integration implementation itself can amount to just few lines of code.
> The article makes it seem like Akka cannot be used from Kotlin
Akka can surely be used from Kotlin (or even Clojure probably, for that matter), yet it lacks an idiomatic wrapper for it, which Quasar is starting to provide (and has offered for quite some time now for Clojure). Both Kotlin and Clojure are good at using existing Java APIs conveniently but, especially in Clojure's case perhaps, I think the lack of an idiomatic wrapper would be felt as an important minus, especially considering how concise and lean Clojure idiomatic APIs usually are.
> I'm unsure if Quasar can't be used from Scala because of the Bytecode manipulation that you're doing being incompatible with the Bytecode that the Scala compiler is putting out.
Quasar's bytecode manipulation amounts to user stack management in order to schedule continuation tasks and generally plays well with other instrumentation agents. Language integration could be very easy (f.e. Kotlin) or less easy (f.e. Scala) depending on the language implementation but I think it is entirely possible to build an integration module for Scala, only it seems to require some effort and so far there have been other priorities on our side.
> I don't understand the part about "non-standard DSL" being used to describe the method of composing futures in Akka. I'm also not seeing a DSL in the accompanying code.
The Future API itself and composition operators (e.g. "Future.sequence(futureSentiments)") are a new async/monadic concurrency DSL meant to work around Java threads being heavyweights. But why adopting a different API and programming model when the pre-existing thread abstraction can simply be made more efficient? I think API proliferation and expansion in general is not a good thing, and more so if it's only meant to work around implementation problems.
> Then there are the claims that Quasar being able to run inside a Servlet container is really a huge advantage.
I'm not advocating for Servlet containers, on the opposite I personally think standalone app deployments are better. But there are a lot of companies with substantial Servlet infrastructure out there and accompanying IT/DevOps processes and skills that can't always afford (or not quickly) a shift to other deployment practices (and I have direct experience about that). So, in the spirit of playing nicely with what is already there, which is also based on standards (even if not always most enjoyable ones), I think it is definitely an advantage to offer such an option.
I'll only add that Quasar offers several types of "send" and "receive" operations: blocking indefintely, with timeout and even "try" variants that will not block at all, as well as several mailbox types, so the developer can regulate queues, responsivity (and backpressure) as desired.
If you want regular code and not async, then yes, it matters: if you have a lot of OS thread-based actors performing blocking network "send"s as part of their regular control flow, each of them blocks an OS thread and you'll run out of resources soon. If those actors are backed by lightweight threads instead, which are very frugal, basically you are only limited by the network stack.
> I've been using Akka in combination with Scala's Futures, with Java 8's CompletableFutures, with Rx Observables, with in-house asynchronous queues and I can't see how Akka doesn't play nice.
Quasar doesn't introduce an async programming framework to work around threads inefficiencies, it simply gives you more efficient threads.
> You can do that [write REST endpoint] with Akka as well, I've done that, I don't see the problem there.
Without Quasar, for your services you can either use normal JAX-RS, which is based on Java's heavyweight threads, or Play (or Spray) which is non-standard and async.
With Quasar instead you can use standard JAX-RS with regular blocking code, but running on lightweight threads.
> the bit about "synchronous" and "blocking" code being easier (while cheating by patching connections) is bullshit [...] People should write asynchronous code throughout the entire call-stack [...]
Probably I don't understand because I don't know much about Gevent and Eventlet but for info about Quasar I/O pls. refer to my other comment: https://news.ycombinator.com/item?id=9585737.
As for async being the way to go, I don't agree and the many discussions about async code problems tell me I'm not alone in that.
In Akka an actor is basically a message handler; I personally think that being able to use regular control flow constructs is an easier way to model state machines than swapping around message handlers.
scala-async looks more like core.async's go to me, i.e. it macro-transforms blocks of code that include special constructs into some continuation-passing style. Quasar implements lightweight threads on the JVM (via bytecode instrumentation, which is a language-independent mechanism), and this is a different thing: no special constructs are needed, you just write regular blocking code (only in lightweight threads, that have basically the same interface and usage as regular Java threads) using normal method calls and control flow constructs. Quasar will take care of blocking/resuming/scheduling efficiently.
As for I/O, Quasar integrations allow lots of fibers to make blocking calls _without_ as many OS threads blocking. The underlying implementation mechanism is often to tap into an async API, suspending fibers when an async call is started and installing an handler that will resume them when the async call completes. Quasar includes such an integration with Java NIO for files and sockets and more are available in Comsat (e.g. with servlet async, async HTTP clients etc.).
I agree about typed actors not being too helpful in dynamic, complex and highly concurrent environments, but in some situations (e.g. transient one-receive actors) they can help keeping communication in check more statically. Of course one can just avoid using types if not needed and Quasar behavioural actors are actually untyped.
Actually the statement about logging is a bit different and says that Akka offers an additional logging API, which is correct I believe, and I think this is unnecessary since a pre-existing one could be used.
As for clustering it's probably just an error in the table, thanks for pointing it out, I'll fix it.
As for JMX, I didn't find info about non-cluster metrics, although there seem to be some 3rd-party projects to get more, but maybe I missed something. Do you have pointers?
Actually bytecode manipulation doesn't make JVM alternative languages impossible, on the opposite Quasar allows them to be easily integrated and investigation/work is ongoing to avoid even having to do that. Plus, depending on the language implementation, in some cases integration is just not needed.
Of course you can use Akka with Kotlin (and Clojure, although not sure how convenient that would be) but there's no idiomatic API (yet?), while Quasar offers them.