8 ms·

> * No more JVM! You're just trading one VM for another, though. How does having a Beam VM environment differ from a JVM environment?

alexgaribay 10y ago
True. That bullet was more of my opinion of disliking the memory usage the JVM uses as well as my personal preference of VM. BEAM has many great advantages such as fault tolerance and multi-node distribution built in. This allows concurrency to be a first-class citizen for applications running on the BEAM. I'm not saying that concurrency can't be done on the JVM, but that I've found it to be much simpler using BEAM. On the other hand, the JVM excels at computational work compared to the BEAM. Both VMs have their place and can be better at different types of problems comparatively.
- andy_ppp 10y ago
  You can also compile Elixir and Erlang to native code if you want it to run computational stuff faster...
  - ngrilly 10y ago
    > You can also compile Elixir and Erlang to native code How? Can you provide a link about this?
    - andy_ppp 10y ago
      Add this at the top of your module (in Elixir): @compile [:native, {:hipe, [:verbose, :o3]}] :-o
      - ngrilly 10y ago
        Hi forgot about HiPE :-) But it doesn't produce a native binary, does it?
        andy_ppp 10y ago
        Where did I claim it did?
        ngrilly 10y ago
        Nowhere :-) I read too fast and mistakenly assumed native code = native executable binary. Is using HiPE a standard practice in the Erlang/Elixir community? What is the quantitative performance gain?
        lucidstack 10y ago
        This comment from Reddit sums it up pretty well: https://www.reddit.com/r/elixir/comments/3gd1n3/what_are_the_downsides_to_compiling_elixir_code/ctx45xh https://www.reddit.com/r/elixir/comments/3gd1n3/what_are_the... I just discovered about HiPE as well, and I just gave it a try with a simple fibonacci module. Running fibonacci(40) went from 3.9s BEAM to 0.7s HiPE. I know it's a silly test, but it's pretty sweet to witness such a massive difference out of the box. :)
        ngrilly 10y ago
        Thanks for the link. I won't say testing HiPE with fibonacci is silly because this is exactly the kind of numerical computation where we expect HiPE to be useful: it looks like it is :-)
- i336_ 10y ago
  > [T]he JVM excels at computational work compared to the BEAM. What sorts of scales are you talking about when you refer to "computational work"? Also, was/were the comparison(s) you're referring to being done using native code?
tragic 10y ago
To me, there's an interesting point here. Elixir has the advantage of targeting a VM built for a language semantically similar to Elixir; things that have frustrating limitations in JVM functional languages like Scala and Clojure (eg, tail calls) just work on BEAM. Interop, naturally, is also much smoother. Want to call out to some Erlang code? Fine - that'll be ':module_name' instead of 'ModuleName'. On the other hand, the Java/JVM ecosystem is much larger, so there's a serious trade-off there.
perishabledave 10y ago
Having BEAM specifically designed for Erlang concurrency gives it a number of specific benefits. Specifically in how it schedules and handles the VM processes to do efficient concurrency. For example, since the processes are in the VM, it can count the number of function calls to preempt a process that is taking too long. You can learn more about BEAM here: https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf http://www.erlang-factory.com/upload/presentations/708/Hitch...
asonge 10y ago
There are a bunch of different performance differences, but a couple basic differences: 1) gc is per-process, not global/stop-the-world 2) the VM is responsible for scheduling processes using threads, and can pre-empt...blocking the scheduler is considered a VM bug.
phamilton 10y ago
I find failure to be more fatal on the JVM. That's neither a bug nor a feature, it's just what it is. For example, BEAM puts the process call stack on the heap, so you don't need to tune them separately. You won't hit a stack overflow, you'll just run out of memory. Many, many characteristics like that exist. I prefer a working slow system over a broken system, but I fully understand the preference for loud failures.
rdtsc 10y ago
I'll take BEAM over JVM any day.
- hellofunk 10y ago
  Without any reasons for your statement, it's just an empty contribution. Care to explain why?
  - rdtsc 10y ago
    Agree, sorry. Sure, here are some randomly ordered reasons: * Immutable data. This ties into "functional" section below but it is worth mentioning separately. The benefit here is it is a better fit for concurrency and correctness. * Lightweight processes. Can have millions of them. But they don't share the heap so act like OS processes in that respect. That means 2 things: 1) It changes the way you think and solve concurrent problems. It reduces impedance between real life problems and how they are solved. Spawning a new process for each long lived connection is obvious and easy. 2) Fault tolerance. Having one request not crash the whole server is a really a massive improvement. In C++ or Java you don't know if something got messed up because of a crash. Maybe some shared data structure or lock got left in an inconsistent state. There is just no guarantee. * Hot code loading. This is not just a gimmick but it works. Most places don't use it to update regularly and I don't either. But used it a few times in production to add extra logging, fix a customer specific issue without shutting down the cluster before the fix was released. All the while there were 100k/sec requests pounding it. That is plain old money in the pocket. No downtime, no headaches. * Tracing. BEAM has very good tracing support. When debugging I am quite fond of just logging into a node and using tracing instead of print or log statements. * Functional. This is more about Erlang the language, and it kind of goes with immutable data. But because of that it means state is more visible and explicit. Looking at a piece of code on a page, I get more context of what is happening because State is passed, updated and returned. As opposed to being some "this" reference which at that point in the code, I don't have any idea how it was modified or what it has in it. * Garbage collection. BEAM has excellent garbage collection. It is pause-less, in the sense that GC of one process won't block the world. Java has lots of tweaks for that but it is not a default state of affairs. Welp, this is just a quick list off the top of my head. At the end of the day, one can probably go through the above list and say I can do all that in Assembly or C. Which is true. BEAM is written in C in large part. To get fault tolerance, can just spawn OS processes in any language. To get immutability, can just go to Github and find an immutable collections library for Python or Java. Java can also do some code loading. But the difference is, it all comes in a single package ready to use. That is huge and I see it as a great benefit.

alexgaribay 10y ago

True. That bullet was more of my opinion of disliking the memory usage the JVM uses as well as my personal preference of VM. BEAM has many great advantages such as fault tolerance and multi-node distribution built in. This allows concurrency to be a first-class citizen for applications running on the BEAM. I'm not saying that concurrency can't be done on the JVM, but that I've found it to be much simpler using BEAM. On the other hand, the JVM excels at computational work compared to the BEAM. Both VMs have their place and can be better at different types of problems comparatively.

andy_ppp 10y ago
You can also compile Elixir and Erlang to native code if you want it to run computational stuff faster...
- ngrilly 10y ago
  > You can also compile Elixir and Erlang to native code How? Can you provide a link about this?
  - andy_ppp 10y ago
    Add this at the top of your module (in Elixir): @compile [:native, {:hipe, [:verbose, :o3]}] :-o
    - ngrilly 10y ago
      Hi forgot about HiPE :-) But it doesn't produce a native binary, does it?
      - andy_ppp 10y ago
        Where did I claim it did?
        ngrilly 10y ago
        Nowhere :-) I read too fast and mistakenly assumed native code = native executable binary. Is using HiPE a standard practice in the Erlang/Elixir community? What is the quantitative performance gain?
        lucidstack 10y ago
        This comment from Reddit sums it up pretty well: https://www.reddit.com/r/elixir/comments/3gd1n3/what_are_the_downsides_to_compiling_elixir_code/ctx45xh https://www.reddit.com/r/elixir/comments/3gd1n3/what_are_the... I just discovered about HiPE as well, and I just gave it a try with a simple fibonacci module. Running fibonacci(40) went from 3.9s BEAM to 0.7s HiPE. I know it's a silly test, but it's pretty sweet to witness such a massive difference out of the box. :)
        ngrilly 10y ago
        Thanks for the link. I won't say testing HiPE with fibonacci is silly because this is exactly the kind of numerical computation where we expect HiPE to be useful: it looks like it is :-)
i336_ 10y ago
> [T]he JVM excels at computational work compared to the BEAM. What sorts of scales are you talking about when you refer to "computational work"? Also, was/were the comparison(s) you're referring to being done using native code?

tragic 10y ago

To me, there's an interesting point here. Elixir has the advantage of targeting a VM built for a language semantically similar to Elixir; things that have frustrating limitations in JVM functional languages like Scala and Clojure (eg, tail calls) just work on BEAM. Interop, naturally, is also much smoother. Want to call out to some Erlang code? Fine - that'll be ':module_name' instead of 'ModuleName'. On the other hand, the Java/JVM ecosystem is much larger, so there's a serious trade-off there.

perishabledave 10y ago

Having BEAM specifically designed for Erlang concurrency gives it a number of specific benefits. Specifically in how it schedules and handles the VM processes to do efficient concurrency. For example, since the processes are in the VM, it can count the number of function calls to preempt a process that is taking too long. You can learn more about BEAM here: https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be https://www.youtube.com/watch?v=_Pwlvy3zz9M&feature=youtu.be http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf http://www.erlang-factory.com/upload/presentations/708/Hitch...

asonge 10y ago

There are a bunch of different performance differences, but a couple basic differences: 1) gc is per-process, not global/stop-the-world 2) the VM is responsible for scheduling processes using threads, and can pre-empt...blocking the scheduler is considered a VM bug.

phamilton 10y ago

I find failure to be more fatal on the JVM. That's neither a bug nor a feature, it's just what it is. For example, BEAM puts the process call stack on the heap, so you don't need to tune them separately. You won't hit a stack overflow, you'll just run out of memory. Many, many characteristics like that exist. I prefer a working slow system over a broken system, but I fully understand the preference for loud failures.

rdtsc 10y ago

I'll take BEAM over JVM any day.

hellofunk 10y ago
Without any reasons for your statement, it's just an empty contribution. Care to explain why?
- rdtsc 10y ago
  Agree, sorry. Sure, here are some randomly ordered reasons: * Immutable data. This ties into "functional" section below but it is worth mentioning separately. The benefit here is it is a better fit for concurrency and correctness. * Lightweight processes. Can have millions of them. But they don't share the heap so act like OS processes in that respect. That means 2 things: 1) It changes the way you think and solve concurrent problems. It reduces impedance between real life problems and how they are solved. Spawning a new process for each long lived connection is obvious and easy. 2) Fault tolerance. Having one request not crash the whole server is a really a massive improvement. In C++ or Java you don't know if something got messed up because of a crash. Maybe some shared data structure or lock got left in an inconsistent state. There is just no guarantee. * Hot code loading. This is not just a gimmick but it works. Most places don't use it to update regularly and I don't either. But used it a few times in production to add extra logging, fix a customer specific issue without shutting down the cluster before the fix was released. All the while there were 100k/sec requests pounding it. That is plain old money in the pocket. No downtime, no headaches. * Tracing. BEAM has very good tracing support. When debugging I am quite fond of just logging into a node and using tracing instead of print or log statements. * Functional. This is more about Erlang the language, and it kind of goes with immutable data. But because of that it means state is more visible and explicit. Looking at a piece of code on a page, I get more context of what is happening because State is passed, updated and returned. As opposed to being some "this" reference which at that point in the code, I don't have any idea how it was modified or what it has in it. * Garbage collection. BEAM has excellent garbage collection. It is pause-less, in the sense that GC of one process won't block the world. Java has lots of tweaks for that but it is not a default state of affairs. Welp, this is just a quick list off the top of my head. At the end of the day, one can probably go through the above list and say I can do all that in Assembly or C. Which is true. BEAM is written in C in large part. To get fault tolerance, can just spawn OS processes in any language. To get immutability, can just go to Github and find an immutable collections library for Python or Java. Java can also do some code loading. But the difference is, it all comes in a single package ready to use. That is huge and I see it as a great benefit.