[jsheard]

That's kind of an underrated aspect of these comparisons - while you absolutely can work around Javascript's weird performance cliffs and avoid putting pressure on the garbage collector, you have to fight the language at every turn because so many idiomatic JS patterns are inherently slow or flood the GC. You may find idiomatic JS easier to work with than something like Rust, but Rust is much easier to work with than the narrow and loosely defined subset of JS that you have to stick to for optimal performance. Taken to its limit you end up more or less writing asmjs by hand.

[hajile]

The rust code is 3x as long and a lot more complex too.

In theory, static typing would correct the biggest performance issues in JS (use monomorphic functions, don't mutate objects, and limit arrays of just one primitive/object type).

In practice, TypeScript allows and encourages you to create types that are horrendous for performance.

I'd love to see a comparison using AssemblyScript (basically stricter TS for WASM). I'd bet it's nearly the same speed as Rust while still being a third of the size.

[pornel]

The Rust version is longer mostly due to boilerplate for WASM<>JS interface, and awful vertically-exploded formatting (probably caused by rustfmt's dumb heuristics).

but the core loop in Rust is pretty straightforward. It could have been shortened and optimized further.

Also keep in mind that the larger the project, the harder it gets to keep JS in the performance sweet spot without tipping over any JIT heuristic, using GC, or accidentally causing a perf cliff, while the Rust has pretty stable and deterministic optimizations and keeps its memory management control at any scale.

[UnpossibleJim]

https://blog.suborbital.dev/assemblyscript-vs-rust-for-your-...

This is a pretty good rundown of expected comparisons, but I doubt there will be any surprises here.

[tjelen]

That's a really good point and I think that in this sense the comparison is really made between Rust and JS rather than between WASM and JS (as others have complained).

[jollybean]

That's an interesting point.

It was my understanding that the V8 GC frankly was rarely used, and that they generally just let memory pile up quite a lot before it's used, in the hopes that it may never have to be run during application lifetime.

[jsheard]

It depends on the application, a short-lived script may complete all of its work before the GC interrupts it, but something that runs continuously can't afford to generate much if any garbage in its main loop because it will inevitably pile up and eventually cause a huge stall when the GC decides that enough is enough. It's especially critical for animated or interactive applications like games, because with those the stall will manifest as the application freezing completely until the GC is finished.