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.

Almost anything with "Go" in the title gets upvotes on HN.

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.

People, please don't upvote any post that has fancy word 'Go' in the title!

If the title used any of those other languages, you likely would not have made that comment.

But it says Go, because the author used Go, but apparently some people are tired of hearing about Go.