Comment by vamega | Hacker News Reader

Comment by vamega | Hacker News Reader

Parent Full thread

Certainly.

I think it starts off with your claim that Quasar is easy to integrate with existing Java libraries. I find that claim to be untrue since any library it's used with needs to be retrofitted/wrapped to make it work with Quasar. If that isn't the case I don't understand why Comstat exists.

The article makes it seem like Akka cannot be used from Kotlin. I think that's disingenuous, given that Akka has a Java API there is absolutely no reason to not be able to use it from Kotlin, or Groovy. 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.

I don't understand the part about "non-standard DSL" being used to describe the method of composing futures in Akka. Seems weird to call a DSL "non-standard". I'm also not seeing a DSL in the accompanying code.

Then there are the claims that Quasar being able to run inside a Servlet container is really a huge advantage. No explanation at all is given for that assertion. As far as I'm aware it was not a goal of the Play framework to be Servlet compatible. It's a framework that provides a HTTP server, I don't see this as fundamentally different than Node or Go which also do this. Python and Ruby need application servers like uWSGI and Unicorn, I don't see why that's a good thing but the article claims that running under a JavaEE Servlet container is a good thing as if it's an axiom.

I'm excited about continuations on the JVM. Lightweight threading is something I'd love to have. I used to work on a Actor based language that compiled to the JVM (a very object-oriented actor language). The lack of lightweight threads was a real issue for that system.

However posts come off as unreasonable because of the tone.

Disclosure - I've not worked withQuasar or Comstat just yet so I can't talk to their technical abilities.

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

Reply on news.ycombinator.com