If best things were winning we would all be using Mercurial and JS would be long dead. Popularity and endorsment decide.
Quasar and Akka – a Comparison
31–40 of 49 posts
Re: Quasar and Akka – a Comparison
#32If best things were winning we would all be using Mercurial and JS would be long dead. Popularity and endorsment decide.
Re: Quasar and Akka – a Comparison
#33Earlier quoted context omitted.
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 thei…
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.
I am also not affiliated with either.
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.
Re: Quasar and Akka – a Comparison
#34Seems like a very one sided comparison. Most other posts from paralleluniverse have also come off this way.
They have conveniently omitted the fact of existence of Akka.NET which gives C#, F#, .NET support. This is not a minor feature. http://getakka.net
True, although it's a community project and not part of the main Akka project AFAIK. Worth mentioning though, thanks for pointing out.
Re: Quasar and Akka – a Comparison
#35Earlier quoted context omitted.
> 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…
> [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 cod…
> 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.
Re: Quasar and Akka – a Comparison
#36How much does the fact you have non blocking green threads matters when you have a cluster of 100 machines? Yes, internally in each machine there are less kernel threads and less overhead, but If an actor on one machine sends a message to an actor in another, does it matter if it's a jvm thread or a fiber?
Re: Quasar and Akka – a Comparison
#37Seems like a very one sided comparison. Most other posts from paralleluniverse have also come off this way.
Anytime I see "Not needed" instead of "No" in a feature comparison chart, I am inclined to just stop reading.
Here are two examples of this in action: http://imgur.com/a/YaQyn#1
Re: Quasar and Akka – a Comparison
#38Quasar is going the right direction - writing synchronous code is better - the code is simpler and cleaner. There is no inherent performance penalty in synchronous approach, it's just the runtime systems of many popular languages make it so - statically allocated stack, and some penalty of context switch via system call. In addition to the languages mentioned in the article (Go, Clojure core.async, Erlang), Gambit Sc…
I feel like Actor is a quantum leap ahead of all the previous and current paradigms, like Promise and Future and Async. What do you think makes it clumsy and why do you think we have something better in store?
Re: Quasar and Akka – a Comparison
#39How much does the fact you have non blocking green threads matters when you have a cluster of 100 machines? Yes, internally in each machine there are less kernel threads and less overhead, but If an actor on one machine sends a message to an actor in another, does it matter if it's a jvm thread or a fiber?
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.
Re: Quasar and Akka – a Comparison
#40The article is full of incorrect statements and biased opinions, I stopped reading at some point, because even though I think Quasar is really interesting, this article has been a turn off. Some things that bothered me ... Akka follows the Erlang actor model pretty faithfully and what you do in the actor model is that you model state machines . In Scala you can also work with scala-async [1], which is basically what…
> This is because it's not the asynchronicity that bites you
But it's certainly what makes your code much harder to read and write (certainly when not using Scala), and it is exactly what colors your code in red and blue.
> This really means that your pieces of I/O logic are still separated into blocking and non-blocking (red versus blue)
But they're not. You can use the same wrapped JDBC data source, or the same lock in your threads and your fibers. There is no more "non-blocking", so it really does uncolor your code -- all code can run in a fiber or a thread. You can take the very same code and run it in a thread -- in which case a kernel thread will be blocked -- or a fiber -- in which case the fiber will be blocked -- and the only difference will be how many of those threads/fibers (Quasar calls them both "strands") you can have, which is exactly a heavyweight/lightweight choice.