An Erlang fanboy here. There is very prevalent opinion that Erlang is about multicore and scalability and such. The truth is that it's completely wrong. Erlang wasn't even multithreaded until early 2000s (if I recall correctly); all it's "green threads" and "message passing" and such are designed to handle and isolate errors (there is a even a joke that Erlang means ERror handLing lANGuage), not to provide multicore scalability. It just happens that the combination of actor model and share-nothing memory model allows to run a lot of "schedulers" (actual processes that execute "green threads") in parallel. There are *a lot* of drawbacks in this approach; for example, it's really hard to build something like reducers/fold in Erlang due to strict isolation of threads and quite expensive (when we are talking about number crunching at least) message passing. Moreover, Erlang VM (or BEAM as it's named) is comparably slower than JVM in terms of computational throughput (number of factorials counter, or numbers added, or strings concatenated per second). There are a lot of clever tricks there to mitigate isolation problems, and it was actually shown that current BEAM scales almost linearly for up to 64 cores at typical Erlang code (and it will scale even better in near future thanks to EU-funded RELEASE project), but please keep in mind that despite all this scalability it's not about raw performance. It's about huge companies like Ericsson running Erlang software due to it's superb error handling abilities and simplicity and almost-real-time response time distribution and legacy at massive scale and being able to reduce hardware costs to run it. When it comes to things like multiplying matrices or cleverly mutating shared state or parsing huge CSV files Erlang will be beaten by Clojure in no time despite "scalability".
On Sunday, April 28, 2013 6:51:04 AM UTC+4, Cedric Greevey wrote: > > https://en.wikipedia.org/wiki/Intel_MIC > > 50+ cores?! Clojure will leave every other language in the dust on > something like that, thanks to its inherently scaleable concurrency > constructs. Try writing a 50-threaded Java application without getting > deadlocks all over the place, or cheating and using very coarse-grained > locks (have fun with the task manager showing 2% CPU utilization when your > app is running full-bore!). > > If big, 32-bit addressing spaces were what made automatic memory > management really begin to come into its own (and with it, Java), then it's > doubtless 50-core machines that will make automatic concurrency management > really begin to come into its own. > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
