Racket executables are not to be compared with those of a compiled language that aims for speed. The primary goal is not speed here and the documentation explicitly says so. You should see them as interpreted code that is bundled with its interpreter for easier distribution and execution, without anything else to install for end users.
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.
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.
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.
I didn't read the original paper[0] but it is based on the Debian Benchmark Game[1] as it was in 2017 and the game relies on user submitted code for each language separately, so most likely when the researchers checked the results, the TypeScript tests didn't have as optimized tests as the JavaScript tests - which makes sense as the latter is way more popular than the former, so there are less people to bother with it (and in fact the benchmarks nowadays do not include TypeScript at all).
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.
And-yet your program was accepted and included, and then with a later TypeScript update it stopped working.
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'?
Something like that is probably what stopped the authors of "Energy Efficiency across Programming Languages".
Yeah Typescript doesn't guarantee perfect backwards compatibility. You normally have the compiler as part of your dependencies and pin it. I guess they just didn't know.
I don't know what you mean with your last sentence. That's the same paper...
I appreciate the thoughtful reply. Every time I see this list trotted out I can't get past the obvious red flag. Nice to have some more background on it.
So when the JavaScript doesn't type check, the authors measured a different program that does type check.
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.
Check the pages i linked at, or even better the one that compares the two[0] around 2017. While there is a single case with wildly different results, there is more than one with results that also have a large difference in JavaScript's favor.
Please read the original paper and base your comments on the repo that the authors provided.
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
:even though they were based on different programs and included an outlier. (Similar story with C/C++.)
> 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.
One explanation is that the typical JS output by the TS compiler is more verbose (so more code to load, parse, and run). On the other hand, one can imagine that the TS compiler’s catching classes of errors at compile time means fewer runtime exceptions.
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.
I don't know what the usual speed difference of TypeScript programs vs JavaScript
programs.
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.
I don't know the numbers but I can probably agree that "modern day" can be replaced by "batteries included" and it would be a better description, from the (valid) point of view that you take.
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 :).
Generally, don't take puffery literally. And whenever the author of this random blog seems to contradict the documentation, you can safely assume the Racket documentation is more authoritative.
"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."
Yeah, reading all those parentheses on startup is not fast.
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.
Also how big will the exe be. Last time I looked the whole interpreter is packed together with the source.
Also I‘m not sure if you can obguscate the code, if you do not want to publish it.
