"It can generate an executable" ; but how slow will this executable be ? Compared to something compiled with SBCL or a non-LISP ?
You can write a Racket application even with a GUI and whatever lib you need and then cross build it as a native executable (that is, an executable that embeds the interpreter, the necessary libs, and your application's code) for yours and other platform for easy distributions.
See https://docs.racket-lang.org/raco-cross/index.html and https://docs.racket-lang.org/raco/exe.html for more information.
But the authors states that Racket is "the finest example of a modern day lisp bar none". In the modern day energy efficiency and climate change are major issues, the German government, for example, has set up the Blue Angel Ecolabel program: <https://www.blauer-engel.de/en>. Using modern day to mean VSCode and Discord is a worthless use of the phrase.
However, Racket is also a modern language in that it has many new and fancy programming language research-grade features since it is also a programming language theory research platform. From that point of view, "modern day" is a valid description :).
Racket ranks far ahead of languages like TypeScript, Python, and Erlang in terms of energy usage, but trails languages like C, Rust, Ada, Java and Common Lisp.
I think, however, there are probably other factors in your computing solution that has a bigger energy impact, like what processors you run on, the architecture of your program, etc.
The list places JavaScript at a score of 4.45 and TypeScript worse at 21.5. For reference, C, the most energy efficient it 1.0
The point is that TypeScript is JavaScript with typing syntax added on top. There is a transpile step into JS. That's how TypeScript works. The runtimes are exactly the same. Unless we're also measuring the build step? Which seems silly.
The difference should be near zero. And it's not. They clearly do not understand exactly what they are measuring.
I think the takeaway, however is the theme of a spectrum of energy efficiency, with compiled languages being more efficient than those that are not.
But I still maintain that the overall efficiency of a system is more a function of other factors.
But the argument that TypeScript generates a JavaScript, so it must have similar speed doesn't hold in general.
If the compiler in question is a whole-program compiler, it can make optimizations that a normal person couldn't do.
As an anecdote in [1] a raytracing program were implemented in both Scheme and C. The Stalin compiler (a whole-program Scheme compiler) produced an executable 45% faster than the one produced by g++. The Stalin compiler produced the excecuable by compiling Scheme to C, and then used a C compiler to produce the final executable.
The price of a whole-program compiler? Well, the compile time are huge.
[1] Scroll to Siskind's comment. https://groups.google.com/g/comp.lang.scheme/c/NJxRsdMNKz4
For those curious about the actual programs and results: https://web.archive.org/web/20071011073406/http://www.ffcons...
Programs that didn't type check were excluded.
https://github.com/greensoftwarelab/Energy-Languages/issues/...
Using the Geometric Mean or the Median with the time measurements from that table would have highlighted the middle value, like this:
JS 7.25
TS 7.80
You can confirm it via archive.org too: the TypeScript[2] page shows both less implementations and the implementations that are shown are often slower than those in the JavaScript[3] page.
As for if that makes sense, well, IMO using the benchmark game for judging how good a language is at optimizations is flawed in the first place as not only there is a bias towards the more popular languages but also a lot of the top entries use approaches that in practice you wouldn't find in real projects.
[0] https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] http://web.archive.org/web/20170425064751/https://benchmarks...
[3] http://web.archive.org/web/20170425114504/https://benchmarks...
Didn't submit it though because they make it difficult.
https://news.ycombinator.com/item?id=24826453
(the whole thread is worth a read)
spectralnorm.typescript-6.ts(115,29): error TS2794: Expected 1 arguments, but got 0. Did you forget to include 'void' in your type argument to 'Promise'?
I don't know what you mean with your last sentence. That's the same paper...
--alwaysStrict
Even so, that only messes up the results because the mean is used rather than the median, and the data tables published with that 2017 paper, show a 15x difference between the measured times for a single outlier the selected JS and TS fannkuch-redux programs.
That single outlier is enough to distort TS and JS "mean" Time difference.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[0] http://web.archive.org/web/20170715120019/http://benchmarksg...
Like you, most readers haven't seen the paper.
Like you, most readers have only seen "Table 4. Normalized global results for Energy, Time, and Memory" taken out-of-context (often without any way to find the original source).
Most readers notice the too-large differences C/C++ and JS/TS and start speculating about how those differences were caused (because that's fun).
I went back to the time measurements the authors provided and calculated the Mean, Geometric Mean and Median. Simply using a more appropriate summary statistic would have presented average values which readers would have found acceptable:
JS 7.25 times slower than C
TS 7.8 times slower than C
Simple: start with the same data, make the same calculations, see the same results.
When we make assumptions about how measurements were made and analyzed, our assumptions may be wrong.
https://docs.racket-lang.org/reference/implementations.html
"The CS implementation is the default implementation as of Racket version 8.0. This variant is called “CS” because it uses Chez Scheme as its core compiler and runtime system.
The CS implementation typically provides the best performance for Racket programs. Compiled Racket CS code in a ".zo" file normally contains machine code that is specific to an operating system and architecture."
As an anecdote, I used to host a computationally expensive web app written in Racket (even before Chez version) serving large amount of requests at peak times on a single $10 DigitalOcean droplet. It was pretty fast and didn't crash. No need for awkward modern web scale thingies.
λ most of the way down.