This is a repost of a low quality paper from 2017 [1]. It's low quality because they haven't done anything truly novel - they simply took the results of the benchmarks game [2] and flipped it. The ones that ran faster are considered greener.

But there are so many other factors to consider. For example, if a language uses all available cores on the machine it's running on, that's a more efficient use of resources than ones that run single threaded by default. Unless of course, your deployment configuration has multiple processes scheduled so no cores are wasted (but assuming they're not bottlenecked by memory). But once we start discussing specifics like how individual deployments happen we can no longer make blanket statements about an entire language.

All that assuming the benchmarks game tells you something reasonable about how real world programs look. They're hyperoptimized by hand with inline assembly, barely readable. That's not normal.

The other issue is that real world programs are large, with dependencies that we pull in. Benchmarks game programs are relatively small and in a single file, no dependencies. Is that what the average Python, Javascript or Rust program looks like in production? What are we even comparing at this point?

They chose to use benchmarks game because it already existed and required minimal effort from them. I'm reminded of the alcoholic using a lamppost - more for support than illumination.

[1] - https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...

[2] - https://benchmarksgame-team.pages.debian.net/benchmarksgame/...