Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"What Erlang does, you simply can't do with ... anything involving ... the JVM."

As a matter of fact, Clojure runs atop the JVM and has a concurrency model that parallelizes even better than Erlang's, although Erlang's model of concurrency is presumably more fault tolerant.



http://blog.getprismatic.com/blog/2012/4/5/software-engineer...

"While we make heavy use of the core of Clojure, we don't use its concurrency primitives (atoms, refs, STM, etc.) because a function like pmap doesn't have enough fine grained control for our needs."


Not sure what you mean by "parallelizes better". However Erjang and Kilim on the JVM have managed to outperform the Erlang VM (thanks to a shared heap they provide zero-copy messaging unlike the Erlang VM) and with InvokeDynamic Erjang should be getting a nice performance boost as soon as they integrate it.


How so?


By conceptually separating synchronization from mutual exclusion and abstracting concurrency into separate models (atoms, agents, refs) that correspond to separate use cases (synchronous and independent mutable access across threads, asynchronous and independent access, and synchronous and coordinated access). It's higher level than using message passing for all types of concurrency and, therefore, more expressive.

When the goal of concurrency is parallelization, I'd want the most abstract and powerful tool for the job, which for me means Clojure over Erlang. When the goal of concurrency is reliability, I imagine I'd want separate lightweight processes for fault tolerance, which is where Erlang seems to excel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: