C Is the Greenest Programming Language

And you then need to consider to what extent any performance saving will be efficiently captured as reduced power use.

But, yes, fully agree.

One system I worked on recently involved about 20 developer years of effort, and about 40 core years of computation... I'm pretty sure the developers machines combined spent far more energy than the production systems, for a Ruby deployment, before factoring in any other energy use relating to difference in effort.

Also, whether C is actually more or less "productive" than other languages for specific tasks isn't all that clear either. For the things I pick C for (for instance cross-platform libraries sitting between OS APIs and user code, and home computer emulators), it is also the most productive option (in the sense that higher level programming languages wouldn't make me more productive, because all that's needed for this type of stuff is functions, structs, loops, conditionals and a handful of math operators - and all those things are in C). High level features like automatic memory management don't make much sense when there's hardly any heap memory to be managed, and a rich stdlib also isn't needed when all you do is number crunching and bit twiddling.

By all means, assess the costs and benefits - I've done projects where I've optimized heavily for performance because it means we could shave tiny amounts of power use off embedded systems we hoped to deploy in large quantities; I'd certainly not deploy Ruby there.

But people seem to have a tendency to overestimate the scale they will need, often dramatically, and often because they have no idea the size of their total addressable market or the amount of data available in a given space (e.g. I've seen developers worry about scaling things to large clusters in niches where actually talking it through with a business analyst would've made them realize that a total saturation of the product to 100% of the maximally possible worldwide market for their service would see it all fit on their laptop)

Unless you actually sit down and work out what your realistic scaling scenarios look like, you don't know whether a tradeoff of time vs. performance will ever pay off.

Even when you do need a scale where putting significant effort into performance matters, there are many scenarios where starting "inefficient" is still more efficient, because it lets you focus more effort on the parts of the system that are proven in real-world settings to actually carry a cost that matters, and the most cost-effective solutions might well be different than what you expect.

E.g. one other aspect of the system that included the Ruby component I mentioned actually hit scaling challenges. Instead of investing time in rewriting it, we cut the computational cost to fractions of a percent by just caching the main pages for a few seconds (I want to say 10, but not sure the exact number). The total energy use for generating those pages once that cache was in place (reconfiguring the reverse proxy that was already in place) was so low that rewriting that part in a more efficient language would equally have saved at most fractions of a core.

Instead of spending extra dev time on that, we got to spend the extra dev resources where it did matter, such as e.g. the backend search engine indexing and query engine, where processing costs certainly would have killed us if it'd been written in a slow language.

Basically, know your costs.

Your fully loaded, real costs, including the actual dev costs by service and by feature. Developers in particular tend to have absolutely no clue about the fully loaded costs of the choices they make, and it often shows in the choices they make.

EDIT: I'd like to add that this is often not the fault of developers. It took years, and very specific circumstances (co-founding startups, that exposed me much more to the money side) before I started seriously thinking about the costs of what I built, and sitting down and actually calculating "worst case" scale and likely scale, and estimating costs of going from one to the other if we engineered for the smaller scale. It's not a habit most developers have, because it's not something most developers get asked, even though they ought to at the very least be involved (a lot of the time I've seen costing done by architects, or even worse directors or VPs with no exposure to the hands on work, it bears little resemblance to reality).

In a highly dynamic language like Javascript you have not much control on when which parts of the code might be 'de-optimized' and re-jitted (e.g. when the 'shape' of objects changes), it definitely doesn't only happen at startup or when a function is first called.

Other comments you've made on this topic seem wrong on basic facts?

https://news.ycombinator.com/item?id=39145414

Also if you are single threaded you do not have to race to sleep on all the other cores. They are already sleeping.

Bleeding edge science rarely works at break-neck competition. When you're competing you can iterate programs while your research is ongoing, so these two seconds doesn't lose its value either.

Even if you start to churn late, you finish early, because it's like an ion drive. Small, yet constant acceleration brings you great speed on the long run. These projects generally run for years, too.

On another side note, as I noted earlier, science doesn't work like this for most of the time, unless we're going something like COVID-19. Even in these cases, you already have a good enough software base to begin with. So you iterate upon the better one while you bang the living life out of your existing solutions.

"Because Rust" and safety, of course. I wonder if programming on Windows just sucks in general, and all these are Windows trading shops. Do you even have all the tools you need to write large programs on Windows? Valgrind, libfuzzer, etc. etc.

I think ~5W is a good approximation for mean power draw of smartphones. I don't know the duty cycle approximation, so I'll assume that number is 2.5W with 50% duty cycle.

This boils down to 500 million smartphones, approximately.

Of you think in terms of gaming PCs and consoles, 400W is a good approximation of the fleet. Again, if we think 50% duty cycle (at 200W), we have 1.562.500 PCs.

So I think, the data centers spend the same amount of power as the rest of the infrastructure, at best. Again, a bigger sample will again tilt the power towards data centers, I assume.