This is true, but it's a point worth making every so often too. I created a system with Erlang and Perl that punched well above its weight (in terms of resources allocated to it) because I was able to cleanly separate the "concurrency" into the Erlang and the "reusing tons of existing code and working in a language the devs are familiar with" into the Perl. It's a powerful pattern, and if you are, like I was, stuck in a language with poor speed and in the case of perl no significant concurrency story [1], it's important to hear that there are options other than "throw it all out and start over again in a Cooler Language (TM)".
[1]: Perl has plenty of event loop choices, but in terms of trying to maintain thousands of live SSL connections at scale it's a terrible, terrible choice for that connection manager. But it was just fine as a service provider.
While this is true, the strategies for each are different. For example, the ways you include Rust or C into a Ruby program can be much more varied than the others in your list. This article, for example, chooses a 'shell out' option. While you can still do that with C or Rust, you can also compile them as an extension directly to your Ruby. There's upsides and downsides to both approaches.
