[bigiain]

I think there's a fair argument to be made that when you're chasing Big O algorithmic improvements, then the effective constant terms incurred by "faster or slower language execution" are premature optimisation. The difference between Rust or hardcoded assembler compared to Javascript or VisualBasic are pretty irrelevant if you're still trying to get your exponent or polynomial terms under control.

[windward]

The argument falls apart when the premise that you're chasing big O does.

Poor cache/memory/disk accesses can result in constant regressions so vast that a 'worse' algorithm actually fares better. Also, we tend to falsely settle on referring to 'O' rather than omega, theta, and average, even when we don't care about worse-case or contrived workloads. See quicksort and mergesort.

For a similar concept in another domain, see also the external memory model:

https://en.algorithmica.org/hpc/external-memory/model/

[HdS84]

Yep. Also, js is easy to iterate on - it's more lenient than rust or say c#. Especially if you are exploring thinks, that's a huge boon. Obviously, for the same algorithm, compiled languages will be slower. Does it matter? Maybe. But time to find this algorithm is also critical - and if js helps here, it's a good choice.

[kalaksi]

But what about afterwards? You move to a more performant language or just accept that you're now invested in JS?

[andrewaylett]

One or the other, probably — Facebook were sufficiently invested in PHP that they released a whole new VM for the language. In Python, one would relatively commonly extract the performance-critical sections into C (or, nowadays, Rust) and you could do the same with Node too. Or the JIT might be fast enough that it's not worthwhile.