I agree with the sentiment of the article, but I'd advocate a balanced approach. Sometimes inefficiency is perfectly fine. > Would you buy a car if it eats 100

I agree with the sentiment of the article, but I'd advocate a balanced approach. Sometimes inefficiency is perfectly fine. > Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time. A more apt analogy would be, "would I buy a car that gets 100,000 km/liter over a nicer car that gets 1,000 km/liter?". Seeing as a I drive about 12k km/yr, the difference in cost in absolute terms is negligible for me (it would be about a $25 Euro difference), even if it's a huge improvement percentagewise. Sure, there's no cars that get this kind of performance, but for computers, the cost of running my laptop for an entire year is less than what an hour of my work-time is worth. If energy were 10 times the price, it would still be negligible. Just look at the quoted example: > I have a Python program I run every day, it takes 1.5 seconds. I spent six hours re-writing it in rust, now it takes 0.06 seconds. That efficiency improvement means I'll make my time back in 41 years, 24 days :-) So this person took six hours to write code that saves 1.44 seconds/day. So it will take 15,000 days to make back that time (I know, I know... they probably did it for some intellectual satisfaction rather than to actually save time). But as I said, I still agree with the sentiment of the article. There are so many cases where making code more performant wouldn't even mean a significant amount more work... it would just mean watching out for very heavy libraries, doing some negligible performance tweeks, etc.