> 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.