Skeptical of rewriting JavaScript tools in "faster" languages

Anyone who has done a programming contest, advent of code, etc knows that the language doesn’t matter so much as your algorithm.

Yes, the language can bring a nice speed up, or might give you better control of allocations which can save a lot of time. But in many cases, simply picking the correct algorithm will deliver you most of the performance.

As someone who doesn’t JavaScript a lot, I’d definitely prefer a tool written in go and available on brew over something I need to invoke node and its environment for.

> knows that the language doesn’t matter so much as your algorithm.

I know what you’re referring to but these problems have also taught me a lot about language performance. python and JS array access is just 100x slower than C. Some difficult problems become much harder due to this limitation.

JS array access is a lot faster than Python array access. JS is easily within magnitude of C and can be even about as fast with typed arrays or well JITable code.

> JS is easily within magnitude of C

Typed arrays help a lot, but I’m still doubtful. Maybe it all the processing is restrict to idioms in the asm.js subset? And even then you’re getting bounds checking.

In benchmarks JS is usually well within magnitude (i.e. under 10x slower).

E.g. C++ vs Node.js here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Couldn't find C vs JS easily with the new benchmarksgame UI.