Hacker News Reader

Comment by capableweb | Hacker News Reader

This language compiles to JavaScript, so it's 0x slower than JavaScript. Comparing similarly named functions between Clio and vanilla JS obviously wouldn't be fair as the feature-set between the two are not equal.

View on HN

The benchmark should be based on idiomatic code in both languages for a same (or similar) input -> output.

You could do that but then your comparison is obviously biased and not very useful.

Picking a language is very subjective, so that's exactly the kind of biased comparison that I want to judge something like this.

Arguing that two programming languages must be considered to have the same performance just because they compile down to the same technology, is flawed.

Otherwise you couldn't make performance comparisons between C, Rust, Go, Haskell, Julia, because they all compile to assembly

I'm not saying you can't, I'm saying that since the code that eventually gets executed the same way just one layer down, it's not useful to JUST consider the performance.

You're not using TypeScript to get faster JS execution. You're using TypeScript to get types in JS. Compare development speed and avoiding bugs together with performance in that case. Same for Clio.

Ok, but I still want to know how much of a performance tax I am paying to know whether it’s the right tool for the job. If it’s a thousand times slower, maybe that overwhelms the benefits of extra features.

And what if every statement I write in the upper language compiles down to one loop that runs a hundred times? The target language is a lower bound, not an upper bound.

Every language compiles to assembly so it must be as fast as assembly?

Reply on news.ycombinator.com