←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 1 comments | 20 Oct 24 21:25 UTC | HN request time: 0.221s | source
Show context
munificent ◴[21 Oct 24 14:35 UTC] No.41904629[source]▶
> I don’t think that JavaScript is inherently slow

It is.

Brilliant engineers have spent decades making it faster than you might expect, subject to many caveats, and after the JIT has had plenty of time to warm up, and if you're careful to write your code in such a way that it doesn't fall off the JITs optimization paths, etc.

Meanwhile, any typical statically typed language with a rudimentary ahead of time compiler will generally be faster than a JS VM will ever approach. And you don't have to wait for the JIT to warm up.

There are a lot of good things about dynamically typed languages, but if you're writing a large program that must startup quickly and where performance is critical, I think the right answer is a sound typed language.

replies(3): >>41905009 #>>41905395 #>>41905655 #
causal ◴[21 Oct 24 15:07 UTC] No.41905009[source]▶
It mostly depends on the application. If you're doing complex transforms over hundreds of GBs of data- yeah, use a workhorse for that.

But the vast majority of slow JS I've encountered was slow because of an insane dependency tree or wildly inefficient call stacks. Faster languages cannot fix polynomial or above complexity issues.

replies(2): >>41905359 #>>41915860 #
1. chubot ◴[21 Oct 24 15:43 UTC] No.41905359[source]▶
Yeah but the application we're talking about here is JavaScript tools, or more generally "language processors" / AST-based workloads

These are very different than your average JavaScript program

And that's exactly where it starts to be the case that JavaScript semantics are the issue

Take it from Lars Bak and Emery Berger (based on their actions, not just opinions): https://lobste.rs/s/ytjc8x/why_i_m_skeptical_rewriting_javas... :)