> It’s actually dominated by the time complexity of the code running on it.

No. Please read the paper I posted. It’s the language.

I’ve read it; it’s a garbage paper. I don’t fault the authors for doing the study but applying the results to anything in reality is almost tantamount to malpractice. It just means AWS people go up on stage and make fools of themselves pushing Rust for environmental impact or people like you try to explain how iOS apps kill your battery to one of the few people who actually has worked to optimize this. The first thing we always investigated was doing less work and fixing bad algorithms, followed by very localized language replacement on hot paths, then as a last resort wholesale rewrites. The ratio of these options was close to 90:9:1.

You sound angry.

You also sound like you are talking to a bunch of morons who don't understand the difference between time complexity and the computational/implementation realities of different languages.

On a personal note, I started my hardware/software development career in the early '80's, writing non-trivial applications in assembly language for a dozen different processors and, of course, designing entire computers from scratch. On from there through languages such as C, C++, Forth, APL, LISP, various Basics and, eventually pretty much all of the "modern" languages. During that time I designed and manufactured custom bit-sliced micro-coded processors with discrete chips in the early days and, PLD/PAL's and, later-on, FPGA's. Sure, I use Python a lot today, yet, I know what I am walking into when I do. I also use lots of C/C++ and, these days, ARM assembler.

Slow code that is both time and energy inefficient is a modern reality. Virtually nobody coming out of a typical university CS curriculum today is exposed to coding without objects. Bloated, slow and, yes, high energy-consuming code is almost normal these days. Look at almost any open source codebase for evidence of this. And, frankly, as machines become faster, nobody cares, because inefficient code works just fine.

Sometimes I compare it to sailing. When there's lots of wind everyone is a sailor. When wind is minimal, you better know what you are doing. Today people benefit from processors running multiple cores at multi-GHz clock rates with tens of gigabytes of memory and terabytes of storage. Of course that leads to bloat and inefficiency at every level! Why wouldn't it?

Yes, that paper does make me angry :) I understand and agree with you that most code that exists today is inefficient and slow, but there is room for "let's after the lowest hanging fruit" in the discussion. Almost all projects these days are object-oriented in some form because complexity demands it. Performance and maintainability for modern software can be at odds along some axes and we pick the latter because our hardware gets better, and we might as well use it for that. That doesn't mean that there aren't places where you can see easy wins or that there isn't horribly inefficient software that ought to be optimized regardless but when you look at the broader picture "let's rewrite everything because it's in an inefficient language" is generally not actually an optimal strategy.

All things being equal, no. It's the language.

All things are never equal, so this isn’t particularly relevant or useful.

That philosophy isn't particularly relevant or useful. How else can you truthfully compare 2 things? Do you always pre-emptively give up and say "well things are always kind of different anyway so it doesn't matter how they compare"?

PS, big O isn't everything. The constant factors that big O hides are in fact meaningful and can make or break an algorithm. Some languages make some constants worse by having extra overhead in some places or better when they have special facilities.

See also: sorting algorithms deferring to insertion sort O(n²) for small runs, galactic algorithms.

See also: languages where everything is a pointer to dynamic memory, vs languages that have actual values. The language default "dictionary" implementation and its time and space complexities. I could go on. For energy efficiency, or memory efficiency, or speed, choice of language does matter, and depending on the size and nature of the data, can overshadow algorithmic choices.

I'm not saying those things don't matter, or that it's not possible that you can overcome some algorithmic complexity just by brute forcing it with a smaller constant. I'm saying that it is exceptionally rare that you are ever in a situation where you can go "oh I have these two identical pieces of software, let's just pick the one that uses the efficient language". Really, it comes down to this question: "this code is slow, what should I do to improve it?". The answer is usually "fix the time complexity somewhere or do less work" and it becomes good enough. Maybe in some isolated cases I might rewrite a bit of it in a different language if appropriate. When I say "time complexity dominates footprint" I mean that most of the code changes I make along the lines of changing something to take "100 ms → 2 ms" where the other language would be "25 ms → 0.5 ms" but you can see why I would not say that the language dominates here.