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

11–20 of 49 posts

Re: Quasar and Akka – a Comparison

#11

Post by circlespainter »

kodablah wrote: post #4
saryant wrote: post #3

Earlier quoted context omitted.

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

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.

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

Re: Quasar and Akka – a Comparison

#13

Post by pron »

nosideeffects wrote: post #6
vamega wrote: post #5

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

In this case, as in many others, "not needed" means that one abstraction that is present makes other abstractions unnecessary. For example, if blocking is free, a non-blocking API is not needed, or if actor receives are selective, then message stashing is not needed. Saying "no" would imply that the functionality is missing, when in fact it is present only doesn't require a separate abstraction.

Re: Quasar and Akka – a Comparison

#14

Post by vosper »

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.

Re: Quasar and Akka – a Comparison

#16

Post by Blackthorn »

circlespainter wrote: post #7
kodablah wrote: post #2

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…

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

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.

Re: Quasar and Akka – a Comparison

#17

Post by avodonosov »

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 Scheme deserves to be mentioned, winch can spawn millions of lightweight (green) threads. Also there was Stackless Python.

BTW, no need to describe the implementation in terms of continuations. It's just enough (I think) to allocate function activation records on heap instead of statically allocated stack. (AFAIK continuations are also implemented similarly, although what I've read about Go, their call stack management is something more complex)

Also, I think the "actor model" is not the final solution for scalable distributed programming, it's just some initial, and IMHO pretty clumsy step. We will have better approaches soon.

Re: Quasar and Akka – a Comparison

#18

Post by kodablah »

circlespainter wrote: post #11
kodablah wrote: post #4

Earlier quoted context omitted.

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.

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

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

Re: Quasar and Akka – a Comparison

#19

Post by pron »

Blackthorn wrote: post #16
circlespainter wrote: post #7

Earlier quoted context omitted.

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

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.

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

Re: Quasar and Akka – a Comparison

#20

Post by outworlder »

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…

Chicken Scheme also has lightweight threads (doesn't have native threads though).

It does not make any performance claims about them, as far as I know.

Post reply on HN