I understand your point but come on, basic stuff has been implemented in a thousand libraries. There you go, a macro implementation

Also the difference between TS and JS doesn't make sense at first glance. 🤷‍♂️ I guess I need to read the research.

I guess we can take the overhead of rust considering all the advantages. Go however... can't even.

For Lua I think it's just for the interpreted version, I've heard that LuaJIT is amazingly fast (comparable to C++ code), and that's what for example Löve (game engine) uses, and probably many other projects as well.

WASM would be interesting as well, because lots of stuff can be compiled to it to run on the web

I would be interested in how things like MATLAB and octave compare to R and python. But I guess it doesn't matter as much because the relative time of those being run in a data analysis or research context is probably relatively low compared to production code.

Looking at the Energy/Time ratios (lower is better) on page 15 is also interesting, it gives an idea of how "power hungry per CPU cycle" each language might be. Python's very high

Every time I get surprised by the efficiency of Lisp! I guess they mean Common Lisp there, not Clojure or any modern dialect.

For Haskell to land that low on the list tells me they either couldn't find a good Haskell programmer and/or weren't using GHC.

Wonder what they used for the JS state since it's dependent on the runtime.

I have a hard time believing Java is that high up. I'd place it around c#.

They compile each benchmark solution as needed, following the CLBG guidelines, but they do not measure or report the energy consumed during the compilation step.

Time to write our own paper with regex and compiler flags.

It's a good question, but I think the amount of time spent compiling a language is going to be pretty tiny compared to the amount of time the application is running.

Still - "energy efficiency" may be the worst metric to use when choosing a language.

I also didn't read it. There's lots of good comparisons already

Private or obscure ones I guess.

Real-world (macro) benchmarks are at least harder to game, e.g. how long does it take to launch chrome and open Gmail? That's actually a useful task so if you speed it up, great!

Also these benchmarks are particularly easy to game because it's the actual benchmark itself that gets gamed (i.e. the code for each language); not the thing you are trying to measure with the benchmark (the compilers). Usually the benchmark is fixed and it's the targets that contort themselves to it, which is at least a little harder.

For example some of the benchmarks for language X literally just call into C libraries to do the work.

Their measurements include invocation of the interpreter. And parsing TS involves bigger overhead than parsing JS.

But TS is compiled to JS so it's the same interpreter in both cases. If they're including the time for tsc in their benchmark then that's an even bigger WTF.