I am sorry but that's a very inaccurate analogy on this topic. The Ruby VM, in particular MRI, is implemented in C. The Erlang VM is also implemented in C. A better C compiler can likely benefit them.
But what runs your Ruby code is the Ruby VM (or even the JVM). What runs Java and Clojure code is the JVM. And what runs Elixir code is the Erlang VM.
The relationship between Elixir and Erlang is much closer to, say, Rails and Ruby (i.e. Rails is built on Ruby's abstractions and semantics) than Ruby and C. It is not a good example but it makes much more sense than the analogy above.
OK, gotcha thanks for explaining. Just for my general knowledge is Erlang/Elixir apps also affected with memory bloat (I mean memory that grows and grows and never properly garbage collection) which seems to be improved for certain apps with jemalloc 3? I mean if it's built with C I would imagine the same problem may occur for Erlang/Elixir.
I am not familiar with the issues affecting the referenced languages to make an efficient comparison, sorry. But I can add some context if you are interested in looking further.
First of all, let's talk about the memory model. The Erlang VM manages memory per process (where a process is a lightweight thread of execution inside the VM that runs concurrently and you can literally have millions of them). So for example, when you have a web request, you spawn a separate process for this web request and once the process terminates, all the memory allocated to it is reclaimed by the VM. This means you can serve a web request without triggering a garbage collector even once. And if you need to garbage collect, it is local per process, so no system wide pauses.
However, what happens if you want to share a large blob of memory between processes? If you copied it between each process it would be expensive, so in this case the VM employs reference counting.
One curious point is that the Erlang VM did not give allocated memory back to the OS until Erlang/OTP 22 (roughly two years ago). This was not much of a problem in the Erlang VM because you typically run only one instance of the VM per node, regardless if you have 4 or 32 cores. Given the issues you mentioned in Python/Ruby/Node, could it partially be because you would rather start 4 or 32 instances per node, so if one of them accumulates too much memory and doesn't give back, it starves the other ones? Or perhaps you would have background workers fighting each other? If you have links to said issues, please share them!
But what runs your Ruby code is the Ruby VM (or even the JVM). What runs Java and Clojure code is the JVM. And what runs Elixir code is the Erlang VM.
The relationship between Elixir and Erlang is much closer to, say, Rails and Ruby (i.e. Rails is built on Ruby's abstractions and semantics) than Ruby and C. It is not a good example but it makes much more sense than the analogy above.