Hacker News new | past | comments | ask | show | jobs | submit login

One thing people overlook with interpreted languages is the environmental impact in terms of extra electricity used.



You're gonna flip when you hear about the environmental impact of a developer.


just imagine using python of cryptocurrency mining.


Or javascript in the browser via malicious js files from hacked ad sites!


Gosh yes. These slow languages offload thinking to burning fossil fuels. INEFFICIENT.


Tell that to accounting that is paying for AWS instance usage.

Facebook has an interesting talk about how much electricity 1% performance improvement saves.


You're not Facebook. The carbon footprint of a single developer is comparatively gigantic for the vast majority of projects most people work on.


If it is running on its own computer, for shell scripting.

If it is trying to process ML data, or running in some cloud provider, or deployed in some IoT device supposed to run for years without maintenance, then maybe yes.


Right, but when you're at that point in performance considerations you already have a team of specialists working on multiple angles in performance.

And precisely, for ML code all python libraries run extremely optimized natively compiled code. The language overhead is a minimal consideration. And for business domain code language performance is rarely the limiting factor.


In some companies that team size is a very tiny number of 1.


If your team size is 1 then you're not doing yourself any favor thinking about performance beyond basic usability when dev productivity is a far higher priority.


> Tell that to accounting

Are you suggesting that accounting only cares about the AWS bill but not at all about the salary of developers?


A developer using an AOT compiled language can still earn the same salary.


Not all languages are equally productive though.


Plenty of languages are as productive as Python while compiling to native code out of the box, without extra tooling.

Includig a couple that are as dynamic as Python.


Examples, please.


What is that impact, quantitatively?



Thanks, that definitely looks like useful data as a starting point.

1. What is the impact of a continuous long-running process? That is, if instead of trying to calculate a result and then shut down, I'm running a web server 24/7, what's the impact of an interpreted language over a compiled language? (Assume requests are few and I'm happy with performance with either.) This not models web servers but things like data science workloads where one wants to conduct as much research as possible, so a faster language will just encourage a researcher to submit more jobs.

2. According to https://www.epa.gov/energy/greenhouse-gases-equivalencies-ca... , 1 megawatt-hour of fossil fuels is 1559 pounds of carbon dioxide. The site you link calculates an excess of 2245 joules for running their test programs, which is approximately .001 pounds of carbon dioxide, or roughly what a human exhales in half a minute. (Put another way, if using the interpreted language saved even one minute of developer time, it was a net win for the carbon emissions of the program.)


> What is the impact of a continuous long-running process?

OK so you're asking about steady-state electricity consumption of a process that's idling? I would bet that it's still lower for a more energy-efficient language, but let's say purely for the sake of argument that they're both at parity, let's say (e.g.) 0. Now what happens when they both do one unit of work, e.g. one data science job? Suppose you're comparing C and Python. C is indexed at 1 by Table 4, and Python at 75.88. So even ignoring runtime, the Python version is 75 times more power-hungry than the baseline C. And this is for any given job.

> a faster language will just encourage a researcher to submit more jobs.

Sure, that's a behavioural issue. It's not a technical issue so I can't give you a technical solution to that one. Wider roads will lead to more traffic over time. What people will need to realize is that if they're doing science, shooting jobs at the server and 'seeing what sticks' is not a great way to do it. Ideally they should put in place processes that require an experimental design–hypothesis, test criteria, acceptance/rejection level, etc.–to be able to run these kinds of jobs.

> if using the interpreted language saved even one minute of developer time, it was a net win for the carbon emissions of the program

I don't understand, what does a developer's time/carbon emission have to do with the runtime energy efficiency of a program? They are two different things.


> What people will need to realize is that if they're doing science, shooting jobs at the server and 'seeing what sticks' is not a great way to do it. Ideally they should put in place processes that require an experimental design–hypothesis, test criteria, acceptance/rejection level, etc.–to be able to run these kinds of jobs.

Sure, but they don't, and perhaps that's a much bigger issue than interpreted vs. compiled languages - either for research workloads or for commercial workloads. People start startups all the time that end up failing, traveling to attract investors, flying people out to interview them, keeping the lights on all night, heading to an air-conditioned home and getting some sleep as the sun is rising, etc. instead of working quietly at a 40-hour-a-week job. What's the emissions cost of that?

> I don't understand, what does a developer's time/carbon emission have to do with the runtime energy efficiency of a program? They are two different things.

This matters most obviously for research workloads. If the goal of your project is "Figure out whether this protein works in this way" or "Find the correlation between these two stocks" or "See which demographic responded to our ads most often," then the cost of that project (in any sense - time, money, energy emissions) is both the cost of developing the program you're going to run and actually running it. This is probably most obvious with time: it is absolutely not worth switching from an O(n^2) algorithm to an O(n) one if that shaves two hours off the execution time and it takes you three hours to write the better algorithm (assuming the code doesn't get reused, of course, but in many real-world scenarios, the better algorithm takes days or weeks and it shaves seconds or minutes off the execution time). Development time and runtime are two different things - for instance, you can't measure development time in big-O notation in a sensible way - but they're definitely both time.


> Put another way, if using the interpreted language saved even one minute of developer time, it was a net win for the carbon emissions of the program

Developers continue breathing even when they aren't programming.


Correct, and computers continue running. I'm referring to the carbon emissions of the development project itself. The faster the development is done, the sooner you can get on with developing other things.


I do not believe that was ever in question.


It's a valid objection to the statement they replied to. Saving developer time does not equate to lower emissions, so it is incorrect to call it a "net win".


Sure and trains burn fuel even when you aren’t using them. But if we look at you carbon footprint it doesn’t seem wise to factor in every single train on the planet in your specific account har because they don’t all air still when you aren’t using them.

When talking about the footprint of a company or a project, then you need to restrict the calculations to the resources they actually use. So if a project uses tools to get a product out quicker that means they’ve spend less human-hours, which have a co2 cost associated with them. Then you can weigh the cost of that tool versus the Human Resources both in a financial sense but also with respect to emissions.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: