> If you're using runtime languages on the backed (node, python) then you're already failing the environment.

Not necessarily. If you make a living running a typical CRUD software-as-a-service offering, your code may really just be glue mapping HTTP requests to database requests. There, your choice of language doesn't count for much; your code isn't doing heavy lifting, the DBMS is.

It's quite possible your hardware requirements could be lower by writing in Python and tuning your database, rather than spending the same time writing non-performance-critical code in C++.

Frameworks like Tornado, for Python, are able to quite efficiently handle highly concurrent workloads, despite using a single-threaded, interpreted, language.

For computationally intensive code, then sure, a language like Python will need far more hardware horsepower to get the job done than C++ would.

>If you're using runtime languages on the backed (node, python) then you're already failing the environment. An efficient compiled language can perform the same functions much more efficiently.

This post is about an optimized environment for C++ services though - not node or python services.

Less code, smaller attack surface.

A better question is Why Not? Is it really so inconceivable to try to apply energy conservation to computing as well?

As the scale of data infrastructure rapidly grows, the carbon footprint of that infrastructure grows as well. It is already non-trivial. Consequently, the widespread use of excessively wasteful software implementations that require several-fold the hardware infrastructure of a more efficient design are becoming material contributors to total carbon emissions, more so than many things we focus on for the sake of climate change.

Unlike some other methods for reducing carbon emissions, which require subsidies to be competitive, massively reducing server infrastructure footprint often improves the absolute economics through radical reductions in OpEx/CapEx for data intensive businesses.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

I think people confuse two important things. 1- Energy consumption of the lower stack versus total of a single implementation (could possibly be very low) 2- Energy consumption of the lower stack multiplied by everywhere it is deployed

1- Yes, optimizing for lowering this consumption by an app-developer can definitely be an ill-advised endeavor economically (you're saving 0.1-10% of your cost.. by adding a huge investment of time, possibly larger than the application development itself) 2- Optimizing across all deployments, can definitely move the needle, in a very significant way, against the effort required, since you're automatically deployed on 1000-1M places.

It's the same reason library developers (especially system/langugage/heavily-used-libraries) have a very good reason economically (and therefore ecologically as well) to optimize. Competition here is a huge benefit to everyone, including the environment.

I was still trying to figure out was the co2 spelling meant, when I read this light grey text.

If you want to see what real computing energy looks like, look at Bitcoin.