That isn't the point of the article though.

More like: If you tune your code Rust (and any native language) is faster, with naive code however there is a good chance that JavaScript can be faster.

'After spending some weeks playing with Rust,'... he is new to Rust and keeps using String, accepting `&String` as args etc this is not tuning. This would be caught by linters like clippy telling you to double check it. I can show you naive Rust vs Naive Node.js and like his follow up article x10 performance over Node.js is not abnormal.

Yep. 8x is the right ballpark I usually see comparing decent C/Rust to javascript.

I saw a 10x slowdown porting the Chipmunk2d physics engine to javascript. (Which dropped to 5x or something after a few weeks of JS optimizations). Porting operational transform heuristics from JS to C got me a ~40x speedup. The code in question used heterogeneous data types which V8 hates (causing both heap thrashing and code deopt). In C I handed it with a tagged union and the code needed 0 allocations in the hot path.

Generally the rule is, if your code has complex data types, heterogeneous data types or a lot objects being created and destroyed it be much slower in javascript compared to C/Rust. A lot of that benefit goes away if the native code does sloppy allocations everywhere.

And on the other hand, if your code is Math heavy, operating on simple data types, V8 will do great work.

There area lot of JS developers who are considering moving code to Rust for performance, but will start out as naive.

Or like: if you spend several hours optimising your Rust code, and not optimising the JS one, then Rust will be faster.

Sure but there’s an upper bound on how fast you can make javascript code run. The same amount of optimization work (if you know what you’re doing) will make a far greater difference to the performance of rust code than it will to the performance of javascript.

Carefully written javascript is still pretty slow because you can’t choose to put objects on the stack in JS, or allocate nested objects together in contiguous memory. And that makes a massive difference because you end up thrashing main memory when you could be spending those cycles getting work done.

I find it unsettling how one-sided the article is, if it's a "showdown" I expect the same effort to be put in JS side of things to maintain some pretense of fairness.

> that makes a massive difference because you end up thrashing main memory when you could be spending those cycles getting work done.

That is true, however there is a huge domain of problems where that isn't much of a concern, while development time spent on it is a concern.

Then sacrificing a bit of performance over development speed can be quite worthwhile.

Of course not a high frequency trading platform and not an AAA+ Game, but a small Webservice just taking data from a ("slow") database, doing little transformation, and sending over network .... less of a problem