Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency.

https://www.sciencedirect.com/science/article/pii/S016764232...

Was big before the AMD athlon. First commodity GHz processor was also the first to make obscene power demands.

I think there's a very different perspective on this between people old enough to have written assembly for 8 bit cpus like 6502 or Z80 often with well under 64kb of total system memory - compared to people who grew up in the age where the "starting coding" choices were something like "Angular or React?" and each browser tab could consume a GB or two of memory.

I'm not trying to say "greybeards are better" or "younger developers don't understand fundamentals" - it's more that the learned/ingrained abstractions those two types of developers start from are very very different. People who were familiar with concepts like the 6502's zero page where you get faster performance because you can use 8 bit addressing to access the first 256 _bytes_ of memory, end up with different mental tools and thinking than, say, people who started out their development learning about asynchronous callbacks and promises. One isn't better or worse than the other - but they are very very different.

(Even today's "tiny" CPUs are commonly 32 bit multi core SOCs. ESP32 kinda took over what used to be done with 8bit atmel Arduino class CPUs)

Arguably cache concerns are distributed computing concepts moving closer to the core. Same with concurrency semantics. These were far more exotic concepts when the fallacies were first written.

Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years