The Akka team's blog on the Akka actor toolkit for the JVM, covering releases, performance benchmarks, and the actor model.
HN commenters cite it for Akka performance data, such as a post showing actors scaling better than a traditional thread pool, and for release and course announcements.
Well written, good description and nice demo.
Would love to see more on how this is different to (or better than) Akka.
The programming model is actually close to Akka (with actor systems, supervision, receive method, message passing, etc).
The article states that Akka has no true lightweight threads. The guys behind Akka have put it running with 50M messages/second[1] and perfomance vs erlang seems to be good as well [2][3].
Perhaps a benchmark would be great.
Thanks for sharing.
[1] http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single-machine
[2] http://uberblo.gs/2011/12/scala-akka-and-erlang-actor-benchmarks
[3] http://musings-of-an-erlang-priest.blogspot.pt/2012/07/i-only-trust-benchmarks-i-have-rigged.html (discussing millions of messages is a good signal IMHO).
- Yes, HotSpot is “the real” thing and includes the best Oracle has. There is a JVM implementation from Azul too, which people consider to be excellent.
- The case between Oracle and Google is not related to the code released by Sun/Oracle.
- You can write heavily optimized code in Java that is as fast or faster than C, without using escape hatches.
- There is no overhead for things you don't use (synchronization).
- The JVM has probably the fastest general-purpose implementation for concurrency primitives for high-level languages. See for example: http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single-machine
- The lack of tail calls is very annoying. The rest just works.
-
Even more along these lines, Scala (another JVM-based language) has demonstrated 50 million message sends/per second with their Akka library.
http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single-machine
I too like Node for small little tasks, tiny dev web servers, etc.
But the JVM is a far more mature platform for writing scalable, multi-core application servers, especially with modern languages like Scala and Clojure.
>One could adopt some kind of event-based system in scala or clojure, but Erlang and Go are alike in being the lone runtimes where running millions and millions of very small messaging processes is AOK no problem for the runtime
Is that really the case? Scala's Akka actor library seems like it would qualify just fine: http://letitcrash.com/post/20397701710/50-million-messages-per-second-on-a-single-machine
I think that you will have to keep that sbt line there because akka-actor comes with the distribution but is a separate jar. So you will have to pull that dependency yourself in sbt.
"For Akka users this change does not have visible effects (you will continue to depend on the same artifacts)"
http://letitcrash.com/post/37716546018/2-1-spotlight-akka-actors-enter-scala-distribution
Indeed, the Akka team published an blog post [1] a while back that demonstrates superior performance versus a traditional thread pool. The actor model seems to be a very favorable use case for F/J though.
[1] http://letitcrash.com/post/17607272336/scalability-of-fork-join-pool