[pron]

> Erlang makes it much easier to do well and much harder to screw up.

That's a feature of the language, not the VM (compare with Clojure, that does a similar thing on the JVM). You could still do all that on a higher-quality VM (simply because the effort put into it is orders-of-magnitude more than into BEAN; not because OpenJDK's people are smarter or anything).

[seiji]

That's a feature of the language, not the VM

Lies.

One way to look at the Erlang SMP VM is basically as a load balancer. Erlang automatically migrates processes between cores for maximum concurrent efficiency. It's basically coordinating N "tiny" Erlang VMs across all your cores and knows how to, ideally, optimally place your workload. You can even constrain the behavior to a per-core and per-scheduler level with VM options—not language options. See the +S and +SP and +SDcpu and +SDPcpu and +SDio and +sct options at http://www.erlang.org/doc/man/erl.html

There are tradeoffs between being the best language for a task and being the fastest language for a task. The more work you can move into the VM, the less you have to do as an application programmer, but potentially the slower your program may go since the VM has to discover or introspect your actions instead being told explicitly.

Our bottlenecks these days are programmer time and programmer thought correctness. Generating more work for programmers by making them write lower level code isn't the way forward even if the more work is slightly faster.

All that being said, everything has a price. Obviously never do numeric computing work in regular Python. Grab you some numpy or GPU frameworks. In the same vein, never do massively concurrent programming without Erlang or without a highly optimized event loop (but with an event loop you're limited back to one core, and on modern 48+ core systems, that's kinda pathetic).

[pron]

> Erlang automatically migrates processes between cores for maximum concurrent efficiency. It's basically coordinating N "tiny" Erlang VMs across all your cores and knows how to, ideally, optimally place your workload. You can even constrain the behavior to a per-core and per-scheduler level with VM options—not language options. See the +S and +SP and +SDcpu and +SDPcpu and +SDio and +sct options at http://www.erlang.org/doc/man/erl.html

That's amazing, except that that's the work of Erlang's wrok-stealing scheduler, and as it happens, the JDK currently has the best work-stealing scheduler around.

> Our bottlenecks these days are programmer time and programmer thought correctness. Generating more work for programmers by making them write lower level code isn't the way forward even if the more work is slightly faster.

Why more work? I am for Erlang. Keep using Erlang. Just run it on the JVM. It's the same work with better results.

[corysama]

If I could get the JVM's JIT & serial GC performance combined with the BEAM's trivial-cost threads & thread-segregated GC, it would be sweet indeed.

[pron]

> serial GC performance

HotSpot hardly ever uses a serial GC anymore. It's now parallel or parallel and concurrent.

> thread-segregated GC

You don't really want that if a shared-heap GC can buy you better performance because it's more mature and saves you all the copying.

> BEAM's trivial-cost threads

You can have that on the JVM.

[nickpsecurity]

That would be a nice combination.