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

Show HN: Lightweight Threads, Channels and Actors for the JVM

blog.paralleluniverse.co

Post reply on HN
Print view View original

1–10 of 56 posts

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#7

Post by Scramblejams »

pron wrote: post #4
Scramblejams wrote: post #3

I didn't see anything in there about ensuring that the messages passed between actors are immutable. Did I miss it?

It's not enforced by Quasar, and Java, obviously can't ensure that, but in Clojure everything is immutable.

Ah, thanks for the clarification, I missed that Quasar was aimed at Java, which threw me off. (Apparently I can't be expected to read the first sentence carefully.)

After enjoying the benefits of immutability and lightweight message passing, I'd hate to give up the former -- but if you're stuck with Java, I suppose all this is gravy.

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#8

Post by pron »

oinksoft wrote: post #6

How does this compare with http://code.google.com/p/jetlang/ ? How does this work with garbage collection? Is the GC per-process ("fiber"), like in Erlang?

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.

The JVM's GC isn't per actor (I know actors are called processes in Erlang, but let's keep the nomenclature consistent), but its GC is extremely advanced, and some implementations work on a per-thread basis. The ramifications are that we can't offer the same level of isolation as Erlang, at least not on HotSpot. An actor could theoretically produce a particular kind of garbage that will cause a GC pause to the entire system. But other than isolation, the JVM is very performant (much more than Beam), and handles concurrency extremely well.

I don't understand your last question (on load distribution).

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#9

Post by pron »

Scramblejams wrote: post #7
pron wrote: post #4

Earlier quoted context omitted.

It's not enforced by Quasar, and Java, obviously can't ensure that, but in Clojure everything is immutable.

Ah, thanks for the clarification, I missed that Quasar was aimed at Java, which threw me off. (Apparently I can't be expected to read the first sentence carefully.) After enjoying the benefits of immutability and lightweight message passing, I'd hate to give up the former -- but if you're stuck with Java, I suppose all this is gravy.

You're not "stuck with Java". Sometimes it's the best tool around. In any case, Quasar is the foundation. Pulsar wraps it with a nifty Clojure API. Perhaps we or someone else will come up with APIs in other JVM languages (I have my eyes on Kotlin).

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#10

Post by oinksoft »

pron wrote: post #8
oinksoft wrote: post #6

How does this compare with http://code.google.com/p/jetlang/ ? How does this work with garbage collection? Is the GC per-process ("fiber"), like in Erlang?

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. The JVM's GC isn't per actor (I know actors are called processes in Erlang, but let's keep the nomenclature consistent), but its GC is extremely advanced, and some implementations work on a per-thread basis. The ramifications are that we can't offer the same…

Re: distribution, I just deleted this question from my comment. I had not payed attention to the item in "next steps" in your post which mentions Galaxy.

I'm excited to see how you guys go about trapping errors and such, as you mention in the "next steps."

Thanks for answering my small questions.

Post reply on HN