Comment by zachruss92 | Hacker News Reader

Comment by zachruss92 | Hacker News Reader

Something I've been thinking a lot about lately is environmental friendliness in software, given that data centers contribute 3% of global greenhouse emissions (same amount as the entire airline indistry).

I'm thinking along the lines of using interpreted languages less server side because of efficiency, but also relying on JS less client side and using WASM where it makes sense.

This has stemmed from me leaning Go last year and being moved by actually how much faster it is than Node for my use cases (API development and data processing).

Where I am curious to see the total impact is how we can take advantage of economies of scale to save money and increase efficiency. I'm thinking along the lines of scale to zero, event driven architectures.

Google Cloud, for example, claims they operate their data centers with industry leading efficiency while also being powered by renewable energy. At scale, do services like Cloud Run or Cloud Functions actually make a difference?

Your introductory point about share of lobal emissions is something I think we as an industry don't really realize yet. So, to give some more precise numbers about that…

> data centers contribute 3% of global greenhouse emissions

Not true according to my research [0] — more like _Tech in general_ contributes ~4% of global GHG emissions. Within that, datacenters only represent ~20%. (The rest is 15% for networks, 20% for consumer devices consumption, and the remaining 45% for manufacturing of equipment.)

And also:

> (same amount as the entire airline indistry).

Air traffic accounts for ~2% of global GHG emissions [1], so Tech is actually twice as bad as air traffic there. Other ways to put it is: as much as all trucks on the planet, and 4x emissions of a country like France.

[0]: https://theshiftproject.org/wp-content/uploads/2018/11/Rappo... (FR) (p18, p20)

[1]: https://www.atag.org/facts-figures.html

When I look at other industries I see efforts to reduce energy consumption. A lot of programmers, in contrast, couldn't care less. The most popular languages are the least energy efficient and most resource intensive. But they make life easier for developers, or as programmers love to say 'more productive'.

When performance is an issue in running programs, a common response is: hardware is cheap, just add another energy-guzzling server or use a more powerful computer.

This attitude is embarrassing when you consider that in every other industry there is a push for reduced resource usage and lower energy consumption. The programming field is the exception.

On the other hand, when it's programmers who are on the receiving end of slow, resource intensive apps, they'll complain loudly. This industry is rife with hypocrisy.

IT-centric orgs definitely care. In my second (post-college, full-time) job I got to see the effect of this directly as truck loads of old server equipment were replaced with about 1/10th the hardware. In their case, predominantly by making good use of virtualization so that applications could share hardware. They cut their power consumption by more than 90% by upgrading to newer machines as well (which were more efficient, while still being faster than the old ones).

This broad brush view that the IT industry doesn't care is absurd, they have to pay bills too and efficiency reduces those. They may not be motivated by environmental concerns, but the costs are very much obvious to them and they do address it with improved efficiencies where possible.

There is absolutely an objective to reduce the use of compute resources. Especially in the current era of AWS/google cloud where you pay $50 per core per month.

Companies care very much about resource usage past some amount of machines. They don't think in terms of power consumption or environmental footprint though, but in real dollars (the costs of hardware/cloud) that is highly correlated.

Kubernetes is the latest trend in spite of being an overcomplicated mess, precisely because it's an overcomplicated mess that can deploy and pack services more efficiently onto (less) resources.

Application code appears to be a small fraction compared to storage, databases, and various operational overhead: https://m.signalvnoise.com/only-15-of-the-basecamp-operation...

I’d be interested to know at what point the energy required for me to write in C (with a significantly longer development cycle, and thus more commutes, more time powering the office, more time running test harnesses, etc) would be outweighed by the gain in its energy efficiency over <insert other language>.

A lot of "I'm not productive in $LANGUAGE" is often "I don't know $LANGUAGE" very well, not "$LANGUAGE is inherently worse". However, if you subscript to the idea of blub programming and such take a look at C++ or Rust.

"It takes me longer in $LANGUAGE" != "I'm not productive in $LANGUAGE"

Some things are just faster to develop in some languages because they have different baseline capabilities. Try parsing and processing a lot of text input in C versus the same task in Perl. Assuming similar competency in both languages (hell, you don't even have to be fully competent in Perl for this, just not a total novice) and the Perl solution will come out faster unless you've already spent a lot of time doing specifically text parsing and processing in C (which is not its primary use-case for many, if not most, day-to-day C programmers).

> with a significantly longer development cycle,

is that the case though. I used to work in a company where we developped some apps in C++/Qt/QML and some others in Electron and for similar apps the development efforts were pretty much the same

> The most popular languages are the least energy efficient and most resource intensive.

This is mostly incorrect. Of the top 10 programming languages on GitHub [1] only Python, Ruby and PHP are commonly used with an interpreter. The rest are all AOT or JIT compiled. I also suspect a large fraction of the Python projects are also data science / ML projects that heavily use packages like NumPy and TensorFlow that offload most of the work to highly optimized math libraries.

I also suspect if you were to look into the programming languages used by the companies with the most servers, they would skew more towards languages like Java and C++, or custom things like Facebook's Hack / HHVM.

[1] https://madnight.github.io/githut/#/pull_requests/2020/2

There seems to be a trend toward using MORE computing power, if it saves on programmers. Continuous integration, fuzzing, other high volume automated testing techniques, all the various applications of machine learning.

If a programmer costs $200K/year, that salary could support about 300KW continuous power use at average US industrial electricity rates (about $0.07/KWh). So if you could spend (say) 20 KW to increase programmer productivity by (say) 10% you'd be coming out ahead.

> A lot of programmers, in contrast, couldn't care less.

You really think the problem is the programmers?

Here's a homework assignment for you: approach the product managers in any given software company and pitch a new development practice, which will improve UX through superior performance, reduce AWS bills, and save the planet, all for the small cost of doubling all product release timelines. Then come back here and report their response.

Just try not to take it personally when they laugh you out of the room.

Kubernetes is popular in data centres but just take a look at how much CPU a fresh install of microk8s uses with nothing running on it (I often see ~4%). The various monitoring systems & addons can only make it worse. It puzzles me why optimising such things isn't more of a priority given that in the cloud resources cost money, not to mention the environmental unfriendliness..

People still religiously believe that development time is always more costlier than computer time in every situation, often misquoting Knuth.

Often, the layers add a lot of overhead, and these days not many would have understanding of underlying layers.

The k3s folks have wondered aloud how high a couple of their components would scale.

Reply on news.ycombinator.com