I don't know what this table is supposed to measure but it doesn't check out.

(C, C++) and (JS, TS) are almost source-compatible, chances are you can rename test.c to test.cpp and test.js to test.ts and you're done. Yet they're showing massive differences?

Also most of the compiled languages with no runtime should get results that are very close to each other: good compilers should produce similar object-code for this type of microbenchmark.

Not to mention this is really measuring the implementation, you can't measure a language. Mike Pall wouldn't be down there, and JS/TS wouldn't be up there without V8 and friends.

I imagine you would want to test "idiomatic" code for these comparisons. It doesn't make much sense to compile with C++ and write everything in C.

That doesn't explain why Typescript is insanely less efficient.

Any comparison with Lua that doesn't include LuaJit also shouldn't include any JavaScript (or rather, should test it with some super inefficient ancient runtime instead of V8)

Why didn't they include assembly? IMO this should be the benchmark, not C

Assembly has no idiomatic way to do things. Creating an optimized assembly comparison is another paper in itself.

This paper is not really relevant, it's based on the "Computer Language Benchmark Game", so what it measures is a mix of the efficiency/speed of the language and the attention that practitioners of that language gave to the Computer Language Benchmark Games.

What is measured in that table is neither naive code nor the absolute limit you can reach with each language, which means you can't really then compare languages between themselves the way the paper implies.

I think picking professionals at random that practice those languages and ask them to write Computer Language Benchmark Games code would be maybe a bit more representative, but even there you face huge biases.

> neither naive code nor the absolute limit you can reach with each language

Maybe a nit pick. But this isn't a basis to say you can't compare the code. The 'average' code is going to be somewhere between your two extremes. Assuming on average, the code was written by the average programmer, you can get an insight in to what the average programmer of a programming language should expect.

Now it may be that populations of programmers favour different things (speed, memory usage, ease of implementation) but that still forms a valid comparison.

We are talking about the benchmark game here. The code for different languages was written by different programmers. For some languages, there were multiple implementations and many iterations. In this case, the researchers used the fastest one.

Some of the implementations are extremely optimized and took a lot of effort. Some implementations are not. So you might be comparing highly optimized JavaScript code with naive, below-average TypeScript code. You cannot compare those.

It would be much better if they used the same level of optimization for each language, but they didn't. Furthermore it is called a "Game" (it used to be called a "Shoot-out") because you shouldn't take it seriously. So it shouldn't be the basis of serious research.

I'm confused because there is no Typescript on the benchmark games that I can see. So what are they even using for Typescript here?

I have to say I am surprised that Java is better than Go in terms of energy/time.

How can that be possible, in my experience

Equivalant service in Java idles around 400mb of ram when Go service might use 70mb.

Because it allocates RAM up front by default. You can reduce that yourself with a single flag. You'd be surprised how far you can tune down modern Java and still run faster than Go. I did this on the benchmark games and some of those programs that used so much RAM didn't need any of it.

There's little about Go's design that is more "Ram efficient." That's not what it was made for. It's for low latency, and if you want that in Java, there are other GC's that can do that (with similar tradeoffs to Go).

The methodology used in this paper was extremely bad. There is no reason there should be any disparity between a TypeScript and JavaScript benchmark.

Unfortunately it has continued to make the rounds for about a decade now and gets re-posted every year or so.

Isn't that like saying X compiles to assembly as so should be as efficient as assembly?

I'm not an expert on the internals of typescript. But your comment doesn't indicate you are an expert either.

You don't have to be an expert in TypeScript to know that the TypeScript compiler just strips the types from the code and leaves the rest as-is (if you are targeting a somewhat modern JS engine). The runtime performance of a TypeScript program is the same as that of the equivalent JavaScript program.

But of course, a TypeScript program could be much slower than a different JavaScript program, as is probably happening in this case.

I agree with others that the difference in results between JavaScript and TypeScript makes the quality of this paper highly suspect.

Well you need to know enough to know whether it's doing run time checks also.

And also whether it's generating less efficient code to satisfy the type safety requirement.

It isn't. Typescript is basically javascript with type annotations. There is a shorthand for class member initialisation and for defining enums, but that's basically it. There are no extra safety checks inserted. You get compile-time typechecking and nothing else.

It's more like comparing assembly against the same program but with comments.