It seems Haskell doesn’t score too well when it comes to energy efficiency, at least when compared to e.g. rust: https://thenewstack.io/which-programming-languages-use-the-least-electricity/
2 Likes
I would say that the energy cost of execution only really matters for software that’s running on thousands of servers.
This paper does not make any statements about Haskell’s energy efficiency. It links to a further paper, but that just talks about Haskell structures and energy behavior without making comparative statements wrt other languages.
1 Like
I would say that the energy cost of execution only really matters for software that’s running on thousands of servers.
Well, Haskell programs do run on thousands of servers today.
1 Like
The paper your article is based on is citation [10] in the paper I linked. That seems to be one of the main papers which are referenced in the abstract:
Previous highly visible studies have established associations between certain programming languages and energy consumption. A causal misinterpretation of this work has led academics and industry leaders to use or support certain languages based on their claimed impact on energy consumption.
This paper adds nuance to the discussion: you have to be more careful to make claims about energy efficiency of a language (e.g., Haskell), you can’t just by measure a particular implementation (GHC) and particular programs (submissions to the benchmarks game). They show that those factors are generally more important than the choice of language.
Programmers aiming to reduce energy consumption can do so by focusing on performance optimizations. This strategy is possible even in “inefficient” programming languages like Python [Haskell] by using faster language implementations, employing faster and more parallel algorithms, and using native libraries.
4 Likes
Well yes, you can use C ffi in Haskell or write hyper optimized code if you understand GHC internals very well. But I don’t think Haskell comes anywhere close to rust/C, especially if we’re talking about “average code” (which is the majority of code in production).
What I meant by that is a single program running on thousands of servers. With a single program running on only few servers, the energy consumption of the developer (and their dev environment) likely far exceed the energy consumption of the program.
Although, to be fair, haskell-language-server does heat up my laptop a bit more than some other language servers 
You should for imperative number-crunching, like the algorithms used in the paper. Not only is it more efficient, you’re also getting extra type safety for anything involving pointers.
If by optimized you mean writing code that looks like this, then please don’t.
The other kind of optimized, that is recognizing the strengths of GHC’s garbage collector and evaluating intermediate data promptly, is not something you can benchmark competitively. You don’t get to choose whether you want to reason about lifetimes of variables in most languages, in Haskell it’s not even a concern most of the time.
Software developers writing average production code don’t care whether it executes in 3ms or 30ms, they care—or, at least, they should care—about correctness and conciseness so they won’t have to waste extra time in the future figuring out why a particular error occurred.
This is why I insist that Haskell’s big problem is not performance, it’s that the ecosystem doesn’t do anything worthwhile with the language, even though GHC is more than good enough as a foundation.
2 Likes
Haha, that’s on me
3 Likes
I don’t really understand what this has to do with the topic.
Someone said Haskell is great for renewable energy sector. I found that a bit amusing given that Haskell programs apparently consume more energy… let’s say on average when written by average programmers.
But it’s not very hard data. And yet I still find it rather believable.
I don’t need to be convinced of Haskell’s others strengths. I just don’t think this is one of them.
Oh, please write more vectorized code. Maybe one day we may find a way to make that ergonomic too.
2 Likes
Most of that post is musings about type safety from the perspective of someone whose first programming experiences were in dynamically typed no-test hell, it just so happened that their industry segment is renewable energy.
Even if the topic of discussion were energy, you’re not asking how we should determine the sweet spot between energy spent executing the program versus energy spent writing/debugging it. You’re pointing to a very specific study of very non-average programs to make a peculiar statement that people reading this topic can’t use for much (except perhaps as reason to switch to Rust?).
Of course, the payoff of better typed, documented, and/or reliable code is that other things like energy flow or movement of resources in the physical world can be massively reduced. Apart from anything else, increased energy consumption doesn’t matter too much if you also increase the amount renewables are providing.
Agreed that Haskell doesn’t have to be good at everything. But “inefficient” shouldn’t bar it from being used in a certain sector, except maybe as the code that runs on microcontrollers in very very specific environments.
2 Likes
That is not a contradiction: we burn the electricity on site of production.
Also, isn’t it more energy efficient to garbage-collect an unused thunk instead of evaluating it?
It would be, but 90% of the time the garbage collector spends more energy shipping your unused thunks off to a large heap on a computer with a non-sandboxed environment and evaluates them there.
(Sad environmentalist jokes! 
)
2 Likes