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.
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.
On GitHub, Akka has 14659 commits, 82 branches, 150 releases, and 188 contributors. Quasar has 1753 commits, 14 branches, 9 releases, and 7 contributors.
All other statistics are also massively in favor of Akka (just look at the numbers for this past week, or the number of contributors that are really active in both projects).
Akka is serious business software, that companies can safely rely on, without gambling their money. It is easy to use, performant, low risk, and has an incredible team of very capable developers who have been perfecting it for years. And "serious and safe" does not at all mean static: they constantly keep pushing the state of the art (I didn't see anything in the article about Akka Streams, Spark, the upcoming typed actors, any emphasis on the usefulness of message persistence, ...).
If you want to challenge the market leader, you will need more than biased reviews: you will need more people working on it, more activity, and real-life success stories.
I'm not affiliated with either horse in this race, but it would be good for you to explain exactly what about those repo statistics favors Akka. Seems like the numbers are larger, of course, but I'm aware of no relationship between any of those numbers and project quality. Or anything else, for that matter.
When you choose the backbone of your architecture, there are other things to consider, in addition to technical aspects. The numbers I mentioned give an indication of some of those aspects.
If I look at Quasar in GitHub, it seems to have only two developers who are really active: the same two people who are writing on this thread. Let’s say I adopt Quasar and base my architecture on it. What happens when these guys land a big project paying big money with a big client? Will they have time to fix issues? Will they have time to develop new features? Will the big client dictate the direction of new developments?
Look at Akka on the other side. They have people like Jonas Bonér, Viktor Klang, Roland Kuhn, Mathias Doenitz, etc. People who are not only amazing developers, but who are also thought leaders. These guys publish books on the subject, speak at conferences, conduct massive online training, and have industry recognition. And they are just the tip of the iceberg. They have a team of less-famous but equally amazing rock star delelopers working with them. Akka gets more solid as time progresses, not only technically but also in terms of market perception.
On which of the two horses would you place your bet?
Quasar may have its technical merits, but unless it comes up with a really compelling feature that gives it a sustainable advantage against Akka, it has no chance of winning.
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.
* 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.
> 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.
> [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 ;-)
> You can do that with Akka as well, I've done that, I don't see the problem there.
The problem is that your (JAX-RS) endpoint will then not scale as much as your business logic.
> People should write asynchronous code throughout the entire call-stack
Ah, but why? Forget for a second about Quasar and its current implementation. Why on god's green earth should people ever consider writing asynchronous code? Correct me if I'm wrong, but the only answer to that is "to avoid blocking threads, which is expensive". If you had a way to make blocking threads inexpensive and therefore not have to write asynchronous code, wouldn't that be better (even if you think async code is not hard)?
> 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.
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?
