[kodablah]

Saying Quasar supports Kotlin/Clojure as though Akka does not (considering both languages interop with Java) is unfair. There is a difference between bytecode manipulation making alternative JVM languages impossible vs just not having a language-idiomatic wrapper.

There a few other parts I take slight umbrage with (e.g. pretending Akka is heavyweight, has deployment rules, incomplete integration information, etc) but overall a nice informative comparison if a tad biased feeling.

[saryant]

Some of it is definitely misleading. Saying that Akka forces you into a logging library when it can be used with log4j, logback, provides a bridge with slf4j, etc, is just being uncharitable. As is claiming that "commercial tools" are needed for monitoring when JMX can be used just as with Quasar. Same with labeling Akka's clustering support as "experimental". Akka dropped that status from the clustering module a while ago (I had it in production for over a year).

I get that it's marketing material so it's going to be biased but I can't help but feel that one too many liberties were taken in making Quasar look good.

[kodablah]

This is most evident in the conclusion: "Akka [...] is a totalizing choice", "blocking is free", "Akka [...] the way to go if [...] you have embraced Scala", "Akka [...] betting on a framework and sticking with it [...] high rewrite price", on and on. In retrospect I would remove "a tad" from the last sentence of my original post.

[circlespainter]

Can you expand on why you think these statements are not correct? I think they are thoroughly explained in the post.

[kodablah]

* Akka is not a totalizing choice, it's just a concurrency mechanism. Many people to not bury logic in there but in traits or other places handling normal futures. That's like saying if you use threads, it's a totalizing choice regardless of where the majority of your code resides.

* "blocking is free" is contradicted right up earlier in the post with "highlights the additional cost of the real lightweight threads in Quasar"

* I will admit, between these two choices, you must choose Akka if you embrace Scala. But the inverse is not true.

* I don't believe it's a high rewrite price any more than any other library is. Do I pay a high rewrite price for using any other abstraction? I mean I just have functions that return futures, but because I composed them with Akka I can't rewrite it?

In general I think it's unfair to make assumptions or opinions here. To compare objectively is one thing, but to say something is a choice one way, requires you code one way, etc is invalid.

[pron]

> Akka is not a totalizing choice, it's just a concurrency mechanism.

... that doesn't play nice with any other Java (or Clojure) concurrency mechanism.

> "blocking is free" is contradicted right up earlier in the post with "highlights the additional cost of the real lightweight threads in Quasar"

Well, very nearly free, and the cost will drop further.

> I mean I just have functions that return futures, but because I composed them with Akka I can't rewrite it?

Pretty much. Java code doesn't work that way, and certainly doesn't integrate with Scala futures. Also, you commit to using non-standard APIs in much of your application. With Quasar you'll likely write the REST endpoint in standard JAX-RS, and run it on top of Tomcat or Jetty or JBoss. So Akka is a library that 1/ encompasses many facets of your application, 2/ uses non-standard APIs everywhere and 3/ uses non-idomatic APIs that are very hard to compose with other Java libraries.

> to say something is a choice one way, requires you code one way, etc is invalid.

Akka does require you to write asynchronous code throughout the entire call-stack.

[bad_user]

> [Akka] doesn't play nice with any other Java (or Clojure) concurrency mechanism

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. With the introduction of the reactive streams protocol, piping streams of events between multiple libraries becomes really easy as well.

> Java code doesn't work that way, and certainly doesn't integrate with Scala futures.

Akka exposes a Future interface for Java, however I don't see the problem with working with Java's CompletableFuture or whatever is in Guava. I've done that, it's quite OK. Also, along with Scala 2.12 (now in milestone), Futures from Scala will be usable straight from Java 8.

> With Quasar you'll likely write the REST endpoint in standard JAX-RS, and run it on top of Tomcat or Jetty or JBoss.

You can do that with Akka as well, I've done that, I don't see the problem there.

> Akka does require you to write asynchronous code throughout the entire call-stack.

I've worked on an RTB system processing over 30000 transactions per second, I'm working now on a system processing real-time events coming from industrial machines. I've been using Akka where it makes sense and while I only played with Quasar, I do have a lot of experience with Gevent and Eventlet in Python and the bit about "synchronous" and "blocking" code being easier (while cheating by patching connections) is bullshit, for one because sometimes it doesn't work creating more problems than it solves and because it doesn't simplify anything of importance. People should write asynchronous code throughout the entire call-stack, it's doable and fun with the right tools ;-)

I expanded a little for the why in another comment: https://news.ycombinator.com/item?id=9585424

[circlespainter]

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?

[circlespainter]

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.

[Blackthorn]

I'm really looking forward to when suspendable annotations are no longer needed, so there isn't any special work that needs to be done to support (for example) Scala.

[pron]

We're working on it, but it might require Java 9.