[ricardobeat]

These comparisons are always highly biased by the kind of work being done. V8 is so good at optimizing code, it's usually possible to reach similar performance in JS.

See https://surma.dev/things/js-to-asc/

Not that relevant, but it looks pretty terrible on a hi-dpi screen, it's probably not accounting for the pixel density when creating the canvas. Looks much better on a normal screen.

[nicoburns]

> V8 is so good at optimizing code, it's usually possible to reach similar performance in JS.

It often is, but unless your code is purely numerical (in which case V8 is fast by default) you have write very awkward code to make JavaScript fast. On the other hand you can often transliterate JS code 1:1 into Rust and it'll be 10x faster.

[masklinn]

That is well demonstrated by the sourcemap events from 2018: Mozilla replaced part of the source-map JS library by a straightforward Rust rewrite compiled to WASM, yielding a 5.9x speed improvement (with much less variance to boot) (Oxidising Source Maps with Rust and WebAssembly).

mraleph then went through a pretty epic bout of algorithmic improvement and engine-specific optimisations, reaching not quite parity with the rust/wasm version but close (Maybe you don’t need Rust and WASM to speed up JS).

Nick Fitzgerald was then able to relatively easily add the algorithmic improvements to the WASM version for an other 3x gain (~10x total from the original) (Speed Without Wizardry).

[cesarb]

To save some searching, the three referenced articles seem to be:

- Oxidising Source Maps with Rust and WebAssembly: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...

- Maybe you don’t need Rust and WASM to speed up JS: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...

- Speed Without Wizardry: https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry...

[jackmott42]

There can be value in "things will be fast by default" vs "things can be fast if you use a careful subset of the language". As well it is nice not to have to depend on v8 being the runtime to get good performance.

One thing I appreciate about say, Rust, vs C# is that in both using iterators to do operations on collections is the standard idiomatic thing to do. However in C# there is always some overhead, and at big scale you have to question whether that overhead is ok here. Usually is fine but sometimes you have to drop back to for loops.

With Rust the iterators pretty reliably get compiled down to very efficient code. So you just do the usual easy thing and get the good performance, no need to worry about it.

[jhgb]

> There can be value in "things will be fast by default" vs "things can be fast if you use a careful subset of the language".

One could equally say that there's value in "things will be general by default" vs "things can be general if you use obscure features of a language and thirty libraries to generalize the things that aren't general yet".

Yet most programs seem to be following the 80/20 rule, so the majority of code that has been ever written seems to prefer generality over raw speed. Of course one possible solution is to write the general parts and the fast parts of your program in different languages, but interoperation may be tedious.