11–20 of 56 posts
Also, i wish they would have some Java code on the page? As i understand it's available for Java as well? I love the actor model, but i have no intention to learn clojure.
Am i the only one who had to smile at the sentence "At Parallel Universe we develop complex data structures and distributed data grids, which require a lot of low-level programming, so I do most of my work in Java."? :) Also, i wish they would have some Java code on the page? As i understand it's available for Java as well? I love the actor model, but i have no intention to learn clojure.
All the code examples in the post are in Clojure because I wanted to demonstrate how the Erlang model is fully implemented, and the Clojure API easily mimics Erlang's. The Java API doesn't have pattern matching, and so would make it harder to see the resemblance to Erlang.
But as good as Java is for low-level, high-performance code, and even though I don't find its verbosity to be problematic in the least, Clojure is a beautiful, elegant language worth learning even if only for its concurrency and state-management philosophy.
Michael Peterson has also done some good work implementing go-style concurrency in clojure
There have been several attempts of porting actors to the
JVM. Quasar and Pulsar’s main contribution — from which
many of their advantages stem — is true lightweight
threads[1]. Lightweight threads provide many of the same
benefits “regular”, OS threads do, namely a single, simple
control flow and the ability to block and wait for some
resource to become available while in the meantime
allowing other threads to run on the CPU. Unlike regular
threads, lightweight threads are not scheduled by the
operating system so their context-switch is often faster,
and they require far less system resources. As a result, a
single machine can handle millions of them.
Excellent area to contribute to. In 2006-2008 there was Kilim, which uses some code-rewriting to accomplish similar greenthreading on the JVM to support an actor system with extremely lightweight lock-ree message massing.
Kilim comfortably scales to handle hundreds of thousands of actors
and messages on modest hardware. It is fast as well – task-switching
is 1000x faster than Java threads and 60x faster than other lightweight
tasking frameworks, and message-passing is 3x faster than Erlang (cur-
rently the gold standard for concurrency-oriented programming).
Could you enumerate your specific perceived shortcomings of akka that you allude to in blog post?
Jetlang doesn't offer lightweight-threads. It uses an
event-driven processing of messages (like Akka), so fibers
can't block and you can't do selective receives.
Akka relies on operating system threads- when you block in Akka, you block in real life.
There have been several attempts of porting actors to the JVM. Quasar and Pulsar’s main contribution — from which many of their advantages stem — is true lightweight threads[1]. Lightweight threads provide many of the same benefits “regular”, OS threads do, namely a single, simple control flow and the ability to block and wait for some resource to become available while in the meantime allowing other threads to run o…
I didn't see anything in there about ensuring that the messages passed between actors are immutable. Did I miss it?
The “Actor” model, espoused by Erlang, Singularity and the
Unix process+pipe model, offers an alternative:
independent communicating sequential entities that share
nothing and communicate by passing messages. Address-space
isolation engenders several desirable properties: component-
oriented testing, elimination of data races, unification of
local and distributed programming models and better optimisation
opportunities for compilers and garbage collectors. Finally,
data-independence promotes failure-independence an exception in
one actor cannot fatally affect another.
I personally am not a fan of prohibiting people from doing things (blame Larry Wall, "first postmodern computer language"), and prefer making good tools available for those who do naturally seek immutability or purity or transferable ownership messages (Transferables in web messaging) or other optional ways of restricting themselves, but the actor model is pretty serious about isolation and Kilim is true to that perspective.
There have been several attempts of porting actors to the JVM. Quasar and Pulsar’s main contribution — from which many of their advantages stem — is true lightweight threads[1]. Lightweight threads provide many of the same benefits “regular”, OS threads do, namely a single, simple control flow and the ability to block and wait for some resource to become available while in the meantime allowing other threads to run o…
fwiw, he did in fact mention Kilim in the footnotes. Sriram also chimes in on the comments.
(i) ultra-lightweight,There's a stackoverflow thread on continuation libraries for the JVM. There's some coverage of the unnamed coroutine library in in Quasar-
http://stackoverflow.com/a/4687050/72070
Thanks for the note swannodette, I'd missed the reference.
Could you enumerate your specific perceived shortcomings of akka that you allude to in blog post?
Elsewhere in this discussion- Jetlang doesn't offer lightweight-threads. It uses an event-driven processing of messages (like Akka), so fibers can't block and you can't do selective receives. https://news.ycombinator.com/item?id=5646097 Akka relies on operating system threads- when you block in Akka, you block in real life.
"Akka supports dispatchers for both event-driven lightweight threads, allowing creation of millions of threads on a single workstation, and thread-based Actors, where each dispatcher is bound to a dedicated OS thread."
I also, would like to see the perceived shortcomings of Akka, since lightweight threads can't be the problem.