Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Quasar and Akka – a Comparison

blog.paralleluniverse.co

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Quasar and Akka – a Comparison

#41

Post by pron »

bad_user wrote: post #25
pron wrote: post #21

Earlier 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…

> 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)?

Re: Quasar and Akka – a Comparison

#42

Post by Matthias247 »

Just wanted to comment on the "Blocking vs. Non-Blocking" nature of the different actor implementions. The article here says

A reason for choosing the asynchronous, callback-based approach has been that blocking plain OS threads entails significant overhead (as does the mere existence of many threads), which can be avoided with a non-blocking API. However, because Quasar – just like Erlang and Go – has true lightweight threads, blocking carries virtually no overhead

In my opinion the difference is much then whether an OS thread is blocked or not. Being able to make synchronous-looking (but not-thread-blocking) calls inside Actors still will block the Actor for other incoming messages for that amount of time. So you have states were the Actor is unresponsive - and with the right amount of dependencies between Actors you can deadlock.

A Actor which doesn't use any blocking calls internally will be more responsive and less prone to deadlock. But of course - you have to model more states explicetly. E.g. if I have an Actor routine that's like

  while true {
    var msg = await mailbox.Get();
    if (msg is XYZ) {
      var result = await doSthAsync()
      updateState(result)
    }
  }
and would like to transform that into a completly nonblocking implementation then I would need to model an extra state and probably handle messages differently in the timeframe between doSthAsync() was sent and the result is received.

This can be a good thing (you can be more responsive and all states are explicit) and also a bad thing (more verbose code).

Important is also that with the blocked Actor one get some kind of backpressure strategy for free. Whereas with the nonblocked Actor one has to handle that also explicitly.

I tried both concepts in my recent work, the blocked actor mainly with F#'s mailbox processor and the nonblocked with my own implementation and personally favor the second version now. I find it quite useful to think about and model Actors as state machines and beeing able to handle all kinds of state transitions explicitly. It also made deadlock prevention easier.

Nevertheless I'm seriously impressed about the capabilities of Quasar and Pulsar.

Re: Quasar and Akka – a Comparison

#43

Post by circlespainter »

Matthias247 wrote: post #42

Just wanted to comment on the "Blocking vs. Non-Blocking" nature of the different actor implementions. The article here says A reason for choosing the asynchronous, callback-based approach has been that blocking plain OS threads entails significant overhead (as does the mere existence of many threads), which can be avoided with a non-blocking API. However, because Quasar – just like Erlang and Go – has true lightweig…

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.

Re: Quasar and Akka – a Comparison

#44

Post by eranation »

circlespainter wrote: post #39
eranation wrote: post #36

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

My thought is that always the network is the bigger bottleneck. But I guess it depends on the data / OS etc.

Re: Quasar and Akka – a Comparison

#45

Post by vamega »

circlespainter wrote: post #12
vamega wrote: post #5

Seems like a very one sided comparison. Most other posts from paralleluniverse have also come off this way.

I don't agree but can you expand? Which parts are one-sided in your opinion and which other posts?

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.

Re: Quasar and Akka – a Comparison

#46

Post by Jweb_Guru »

felixgallo wrote: post #38
avodonosov wrote: post #17

Quasar 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?

The problem, I suspect, is that there isn't really one formal "actor" model that everyone agrees on. People have used it to describe formal models like CSP and linear logic, practical systems like the Erlang VM and Go's green threading implementation, and capability-based systems like the (provably secure) SEL4; these are not the same thing. And, not to pick on you specifically, this is exacerbated by confusingly referring to "promises, futures, and async" as "paradigms." Promises and futures are for the most part identical, and I don't see how you can meaningfully call them "paradigms"--they're just APIs. "Async" (async what?) is maybe abstract enough that I'd be willing to call it a "paradigm," but I don't see how actors don't also fall into that category.

Re: Quasar and Akka – a Comparison

#47

Post by circlespainter »

vamega wrote: post #45
circlespainter wrote: post #12

Earlier quoted context omitted.

I don't agree but can you expand? Which parts are one-sided in your opinion and which other posts?

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 A…

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

Re: Quasar and Akka – a Comparison

#48

Post by justthistime_ »

vosper wrote: post #14
vamega wrote: post #5

Seems like a very one sided comparison. Most other posts from paralleluniverse have also come off this way.

An early giveaway is the 5 paragraphs (325 words in total) introducing Quasar, versus the single paragraph (69 words) about Akka.

Plus, the ParallelUniverse guy keeps trying to spread FUD about Scala in pretty much every Java/Scala/whatever thread.

Re: Quasar and Akka – a Comparison

#49

Post by felixgallo »

Jweb_Guru wrote: post #46
felixgallo wrote: post #38

Earlier quoted context omitted.

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?

The problem, I suspect, is that there isn't really one formal "actor" model that everyone agrees on. People have used it to describe formal models like CSP and linear logic, practical systems like the Erlang VM and Go's green threading implementation, and capability-based systems like the (provably secure) SEL4; these are not the same thing. And, not to pick on you specifically, this is exacerbated by confusingly ref…

could you point to a place where anyone's said that Go, or any other CSP system, are Actor systems? That would be interesting to see.

Promises and futures are not actually identical; and they're paradigms, because they are concepts shared across a large number of different languages. 'Async' is the P in CSP, as in C# (called 'async'), and as in ES7 (https://github.com/lukehoban/ecmascript-asyncawait). Hope this helps you.

Post reply on HN