←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.204s | 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. munificent ◴[22 Oct 24 16:18 UTC] No.41915860[source]▶
> If you're doing complex transforms over hundreds of GBs of data-

It's not always about giant datasets. Latency matters too for software that is run frequently by users.

I maintain a code formatter. In a typical invocation, it's processing only a few hundred kilobytes of input data. But it is invoked every time a user hits control-S, thousands of times a day. If I make it a few hundred milliseconds slower, it materially impacts their flow and productivity.

> Faster languages cannot fix polynomial or above complexity issues.

This is true. But once you have fixed all of your algorithmic issues, if your language is slow, you're completely stuck at that point. You have hit a performance ceiling.

Personally, I would rather work in a language where that ceiling is higher than it is in JavaScript.