[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

[pron]

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

[circlespainter]

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