←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.001s | source
Show context
jpalawaga ◴[20 Oct 24 21:53 UTC] No.41898791[source]▶
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.

replies(12): >>41898816 #>>41898879 #>>41898890 #>>41898952 #>>41899000 #>>41899028 #>>41899401 #>>41901158 #>>41901185 #>>41901525 #>>41902030 #>>41904514 #
noname120 ◴[20 Oct 24 22:07 UTC] No.41898879[source]▶
It's not just a matter of “picking the correct algorithm”. Algorithmic-interview exercises are algorithmic-interview exercices. They are barely related to real-world software engineering.
replies(3): >>41898892 #>>41898946 #>>41898965 #
tightbookkeeper ◴[20 Oct 24 22:20 UTC] No.41898965[source]▶
Exactly. What do you do when you have the right algorithm and it’s too slow (very typical for linear problems that require visiting each item).
replies(1): >>41899023 #
1. anyfoo ◴[20 Oct 24 22:29 UTC] No.41899023{3}[source]▶
You optimize the constant factors, e.g. the runtime of the inner loops. But this requires you to choose a sane algorithm in the first place.

Some problems are much more complicated, where you have to take, for example, locality (cache hierarchy etc.) and concurrency considerations like lock contention into account. This may affect your choice of algorithm, but by the time you reach that, you've almost certainly thought about the algorithm a lock already.