This week's book giveaways are in the Cloud and AI/ML forums. We're giving away four copies each of Cloud Native Patterns and Natural Language Processing and have the authors on-line! See this thread and this one for details.
Ruby and Python performance metrics are similar because they're dynamic and interpreted at runtime. Even if Ruby 2.6 and 2.7 have made performance improvements (you're correct in saying they have), the difference in runtime speed is still negligible between the two languages. Ruby 3 has the audacious goal of being three times faster than Ruby 2. If/when that happens, Ruby may be faster than Python, but probably not so much faster that you should use it as the sole deciding factor of which language to use.
Regardless of whether Ruby 3 achieves its goal, Java is and will remain faster at runtime. Java is a statically-typed, compiled language, which gives it distinct speed advantages at runtime. JRuby's speed metrics are similar because it also runs on the JVM, though anecdotal evidence suggests it is still a bit slower at certain tasks than Java.
You might like the keynote Matz gave at Bath Ruby last year - in the second half (from 25 mins or so in) he spends some time talking about the future of Ruby and Ruby 3, and he's clear that they don't want a big jump between 2 and 3, so they are trying to introduce new stuff (like the 2.6/2.7 improvements) gradually to avoid a Python 2 vs 3 situation.
Joe Leo wrote:
Java is and will remain faster at runtime.
If it's faster then why do some people use node or python for a web server?
Je sais ce que je sais
posted 2 months ago
Well, because Node, Python, and Ruby are typically "fast enough" for the needs of a web server. Despite being faster at runtime, it will typically take longer to build, deploy, and maintain a Java application. A Java developer will write more code and wait longer (for the code to compile hundreds or thousands of times) to build and maintain her application. The dynamic nature of Ruby allows her to build an application and iterate on it faster, which speeds time to market, time to get feedback from users, and lowers the burn rate of cash used to pay the developer for her time. So asking "is this language fast enough for the task at hand?" is typically a better question than "what is the language with the fastest runtime?"