Hacker News new | ask | show | jobs
by nickpsecurity 3972 days ago
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...
1 comments
pron 3972 days ago
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.

link
nickpsecurity 3971 days ago
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.

link