If someone makes the Java GC 3x faster, that will most likely positively impact all Java and Clojure programmers. Similarly, if someone wants to invest on Clojure performance, they most likely need to do so by investing on the JVM and core libraries, which will benefit the overall ecosystem. Plus one main reasons people use to pick JVM languages is the access to the whole Java ecosystem and related packages.
Therefore, if you are considering the performance of the platform, improvements to the runtime and virtual machine, package ecosystem, etc, lumping them together makes total sense. On the other hand, Clojure and Java are quite different languages, with complete different paradigms, so there is probably a ticker layer specifically dedicated to Clojure.
Erlang and Elixir are much closer to each other than Clojure and Java or even Scala and Java. The data structures are the same, the language constructs are mostly the same (different syntax but the same semantics), etc. You can call each other with no performance cost whatsoever. All of the companies investing on Erlang will directly impact Elixir and, if you want to make the Elixir compiler or runtime faster, odds are that this efforts goes to Erlang - it is one of the reasons I have ~100 PRs merged upstream, mostly focused on the compiler and/or performance.
So, once again, if your goal is to assess the healthy of the ecosystem or how many companies are investing on the platform, then they must be considered together. The contributions done by Ericsson, Whatsapp, Klarna, Erlang Solutions, etc. benefit all languages running on the Erlang VM. In fact, if someone asks me how they can financially contribute to Elixir, I will 100% direct them to the Erlang Ecosystem Foundation (https://erlef.org/), which focuses on domain areas around the ecosystem, rather than languages.
Since you seem to use Ruby as a reference, I don't expect the dynamics to be much different. Most companies and contributors are likely working directly on the Ruby VM and the runtime, rather than the language itself. However, because Ruby is the only (main?) language running on it, we don't tend to separate them. But in practice the language is only a small surface into the complexity that is its underlying platform and working on said platforms requires a completely different set of skills and technologies.
EDIT: this applies to the ecosystem too. For example, every Phoenix application is running a web server written in... Erlang. :) All Ecto database adapters are using the tcp modules provided by Erlang. The package manager that powers all languages running on the Erlang VM is written in Elixir. And so on. You don't need to know Erlang in order to write Elixir but, if for some reason you need to pick up, it is straightforward because of all of the above.
Ruby runs on C, I guess if C gains in performance then Ruby (and Python, and JS(?) and PHP) all become faster as well. I know it's not a perfect analogy to Erlang/Elixir but there is a strong connection between C performance/memory management and Ruby. For instance the whole malloc/jemalloc memory issue which affects Ruby/Python/Node(?) apps. It could be that these dynamic languages misuse C or something and it's really not C's "fault", I'm not sure, it's above my pay grade :)
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!
Therefore, if you are considering the performance of the platform, improvements to the runtime and virtual machine, package ecosystem, etc, lumping them together makes total sense. On the other hand, Clojure and Java are quite different languages, with complete different paradigms, so there is probably a ticker layer specifically dedicated to Clojure.
Erlang and Elixir are much closer to each other than Clojure and Java or even Scala and Java. The data structures are the same, the language constructs are mostly the same (different syntax but the same semantics), etc. You can call each other with no performance cost whatsoever. All of the companies investing on Erlang will directly impact Elixir and, if you want to make the Elixir compiler or runtime faster, odds are that this efforts goes to Erlang - it is one of the reasons I have ~100 PRs merged upstream, mostly focused on the compiler and/or performance.
So, once again, if your goal is to assess the healthy of the ecosystem or how many companies are investing on the platform, then they must be considered together. The contributions done by Ericsson, Whatsapp, Klarna, Erlang Solutions, etc. benefit all languages running on the Erlang VM. In fact, if someone asks me how they can financially contribute to Elixir, I will 100% direct them to the Erlang Ecosystem Foundation (https://erlef.org/), which focuses on domain areas around the ecosystem, rather than languages.
Since you seem to use Ruby as a reference, I don't expect the dynamics to be much different. Most companies and contributors are likely working directly on the Ruby VM and the runtime, rather than the language itself. However, because Ruby is the only (main?) language running on it, we don't tend to separate them. But in practice the language is only a small surface into the complexity that is its underlying platform and working on said platforms requires a completely different set of skills and technologies.
EDIT: this applies to the ecosystem too. For example, every Phoenix application is running a web server written in... Erlang. :) All Ecto database adapters are using the tcp modules provided by Erlang. The package manager that powers all languages running on the Erlang VM is written in Elixir. And so on. You don't need to know Erlang in order to write Elixir but, if for some reason you need to pick up, it is straightforward because of all of the above.