[digitalzombie]

> brilliantly to run in parallel.

I just want to clarify it's for concurrent not parallel.

Erlang doesn't promise parallel. You can get parallel from concurrent but not the other way around and once again Erlang only enable concurrency and you may get parallel beacuse of concurrency.

[chrisseaton]

I can keep quoting from the same book:

> Here’s the good news: your Erlang program might run n times faster on an n-core processor—without any changes to the program.

Sounds hopeful - and they've qualified it with might which is good.

> But you have to follow a simple set of rules. If you want your application to run faster on a multicore CPU, you’ll have to make sure that it has lots of processes, that the processes don’t interfere with each other, and that you have no sequential bottlenecks in your program.

Oh right, so as long as I have no dataflow dependencies it'll scale easily - but that's true for any language. The problems we have are when there are dependencies - and Erlang doesn't have a good solution for that in my opinion.

> Even if your program started as a gigantic sequential program, several simple changes to the program will parallelize it.

Several simple changes can parallelize an arbitrary sequential program? That's amazingly strong and obviously incorrect.

Also "you can get parallel from concurrent but not the other way around" that's not true! Vector instruction sets allow parallelism but not concurrency.

[nickpsecurity]

That's not true for any language. It depends heavily on how that language is interpreted or compiled to machine code. A number of languages support threads but have eg GIL's. We have to judge each on a case-by-case basis. Both the Erlang language and BEAM designed specifically to support this. Here's some details for you in a JVM comparison:

http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.p...

[pron]

Unfortunately, that comparison lacks a lot of pertinent information on the JVM like new GCs, new schedulers, new, better JITs and various lightweight-thread implementations (it does mention Quasar, but doesn't understand that it works just like BEAM. BEAM also instruments your code, and in BEAM you can also accidentally block an entire kernel thread by calling a library not written in Erlang: just as you would if you were running Erlang on the JVM.

Like I said in another comment, BEAM's Erlang specificity does not mean that it's the best VM for Erlang; all data points to HotSpot (today) being a much better Erlang VM. It just means that a reasonable VM for Erlang could be developed with relatively little effort.

[nickpsecurity]

I think you're a little too excited about JVM's to see the point of the comment. The parent comment included a statement that code in any language can scale without dataflow dependencies. I said it actually depends on the implementation of that language as some don't realize that potential or even defeat it entirely. Gave an example with GIL followed up by examples in BEAM and JVM where implementation mattered.

Far as JVM vs BEAM, it's actually orthogonal to my comment as it would only support that implementation decisions matter for scalability on top of language's inherent traits. You've been arguing that yourself except on other side.

[pests]

Per your last comment - that is what he was saying. Vector instruction sets allow parallel, which does not imply concurrency.

[chrisseaton]

Ah yes you're right sorry. I was thinking without reading carefully that he was saying you can't have parallelism without concurrency.